[Shannon Hicks]

This looks like a common database issue that usually gets resolved by a server restart, so maybe @aufdenkampe can comment on it?

[Shannon Hicks]

I assume you mean the manual is pointing you to Github where you attempted to download the libraries?  If you go to https://github.com/EnviroDIY/Libraries and follow the instructions on that page in the section called “Installing Libraries in Arduino IDE”, you’ll save the libraries.zip file by right-clicking on the link in the text that says ” –>->link<-<–“ and then save the file to your computer that way.  You’ll end up with a zip file that then needs to be extracted to the folder location on your computer as explained in the instructions.  If you don’t download the libraries zip file correctly or don’t put the extracted files in the correct location, and then restart your IDE, you can get errors.

[Shannon Hicks]

You should try adding it as an issue (if it’s not already reported) on the ODM2DataSharingPortal Github issues page so the development team that’s working on TSV will see it.

[Shannon Hicks]

There’s a few things in your post to clarify to make sure we’re talking about the same equipment.  The various instructional videos and manuals we’ve released in the past few years cover several different configurations of sensors and cables and equipment.  The majority of the stations we deployed before 2020 had a Meter Group CTD sensor and a Campbell Scientific OBS3+ turbidity sensor on them.  We also used to sell Monitoring Station Kits that contained Pelican 1120 cases that were pre-drilled and tapped for 3 cable glands:  one for solar panel cable, one for CTD sensor, and one for OBS3+ turbidity sensor.  The CTD and old turbidity sensors had cables that required the same diameter cable glands, so we used the 69915K53 size (0.24″-0.47″ cables and 1/2″ NPT threads).

Campbell Scientific discontinued the OBS3+ turbidity sensor a few years ago and since there was not a ready replacement, we stopped including the cable gland and pre-drilling the holes in the Pelican cases that we sold, since most people were just building CTD-only stations.

A few months ago, Campbell Scientific released the ClariVUE10 turbidity sensor, and it has a cable with a smaller diameter.  Therefore we recommend using a 69915K54 cable gland (0.2″-0.35″ range, 1/2″ NPT) for the ClariVUE10 turbidity sensor cable.

The Meter Group Hydros21 sensor can be purchased with either bare wire leads on the end of the cable, or a 3.5mm stereo headphone plug.  We usually tell users to choose the stereo plug because it’s the easiest to use, and we developed a Grove-to-3.5mm-jack adapter board many years ago for connecting the stereo plug to the Grove jack of the EnviroDIY Mayfly.  The ClariVUE turbidity sensor cable has bare wires on the end, there is no connecter on the cable. We developed the multipurpose 6-pin screw terminal board for using bare wire sensors like the ClariVUE with the Mayfly.  You could also use that same screw terminal board for connecting a Hydros21 CTD sensor to the Mayfly if you bought the sensor with bare wires instead of the headphone jack.  It’s worth noting however that we may need to develop a new screw terminal board with some additional circuitry on it to properly communicate with some SDI-12 sensors like the ClariVUE10, so we’re still working on this, which is why we haven’t published official instructions on how to connect a ClariVUE10 to the Mayfly yet.

The term “Molex connectors” refers to a wide variety of sizes and types of connectors so I’m not sure to which ones you’re referring, but  there aren’t any Molex connectors anywhere on the EnviroDIY Mayfly, and we don’t use them in any of our recommended instructions.  Are you referring to the Grove cables and Grove jacks (the six or seven white, 4-pin polarized sockets on the Mayfly)?  All you should need to connect a ClariVUE10 to the Mayfly is the screw terminal board mentioned above, and a short double-ended Grove cable, like the ones we include in the Starter Kit or the Monitoring Station Kit, or that can be found from various sellers on Amazon.

Another thing to note, the ClariVUE10 sensors require 9.6v to 18v DC to operate.  The previous EnviroDIY Mayfly boards we sold prior to the fall of 2021 were not capable of powering these sensors.  The Mayfly v1.0 we released in October and the new v1.1 board releasing next week are able to generate a 12v power source capable of powering the sensor, but you have to move the small jumper next to the Grove jack to change the voltage level sent to that jack to match whatever sensor you’re connecting (your options are 3.3v, 5v, and 12v).  So instruction for all these steps are being finalized now, along with writing and testing new code examples for all the major configurations we recommend, which will include the ClariVUE10.

As for the anti-fouling tape, it’s probably not necessary.  The ClariVUE10 is manufactured with a copper end-plate, so algal growth right around the sensor window should probably be reduced, however the sapphire windows themselves will need to be cleaned regularly, plus we find that the majority of fouling issued to our turbidity sensors is cause by large debris like leaves, sticks, mud, rocks, etc, which is why still suggest frequent service visits to the station, especially for stations that don’t transmit their data to an online portal like Monitor My Watershed.

[Shannon Hicks]

The only difference between versions is stated in the first paragraph of the blog post:  the only major change being the circuit that provides the switchable 12 volt boost output was redesigned to provide a higher power output. And 2 minor changes: one set of pin labels were slightly change and one solder jumper was added to the back of the board for an optional battery-measuring feature. (see more at Details and Specs)

[Shannon Hicks]

If there’s a CR1220 watch battery installed in the battery slot on the Mayfly (with sufficient voltage) then the RS3231 RTC will still be alive and continuing to think it’s whatever time it thinks it is. However if the board has been sitting in storage for awhile and not attached to a main Lipo battery, it’s likely that the CR1220 is dead and therefore the RTC doesn’t retain any time information, and it will reset itself to 1/1/2000 every time the Mayfly starts up until you add a new CR1220 and set the clock.  If there’s a cellular modem on the Mayfly board, then it will attempt the contact the time server to set the RTC upon bootup (assuming you’re running one of our recommended sketches built on the ModularSensors examples we share on Github).

If the clock is still running but is just wrong because the clock was set wrong sometime in the past, you could see what time is currently being reported, then do the math (easiest in Excel) to get the offset between the correct NOW time and the incorrect NOW time, and then apply that offset to all of the stored data on the logger’s memory card.   If your Mayfly is running one of those recommended logger sketches, then it will print a variety of helpful information to the Serial Monitor upon startup, including the date/time of the RTC, and other configuration settings of the deployment.  If you reprogram the Mayfly with another sketch before you see any of that, then it’ll be lost, so I’d recommend only trying to read the data from the Mayfly serial port until you get things going smoothly with the computer and not trying to upload any new sketches until you’re able to connect reliably and correctly to the Mayfly with the USB port on your computer.   The previous sketch is probably transmitting at either 115200 or 5600 baud.  That speed only refers to comunications through the Serial Monitor and doesn’t affect the upload speed used when burning a new sketch to the board.

[Shannon Hicks]

I’m not familiar with the code regarding the complex loop since it’s not something I’ve ever used, and I’ve also not used one of those modbus wings, so I think Anthony or Neil will need to be the ones to help with this issue.

[Shannon Hicks]

If your Mac isn’t seeing the Mayfly as a USB device in your computer OS list of current devices, then you need to install the FTDI drivers from the device website at https://ftdichip.com/drivers/vcp-drivers/

Mac and Windows 10 should automatically install those drivers whenever a Mayfly is connected to a computer for the first time, but sometimes company or school security software or configurations will limit the computers from automatically installing those drivers, requiring you to do it manually.

Once you’ve installed the VCP driver, your computer should see the Mayfly as a USB device and will assign it a COM port (or on a Mac it’ll give it a somewhat cryptic port designation as Beth showed above with the screenshot).  You shouldn’t attempt to troubleshoot communications issues with the Arduino IDE until you’ve confirmed that the computer can see the Mayfly.  And as Beth mentioned, many USB cable don’t actually contain all the proper data lines because they’re only a basic charging cable, or those pins in the connector or wires in the cable can get damaged or broken, causing there to be no communication.  I’d recommend trying a couple different cables (from different manufacturers) and different USB ports on your computer.  If none of those work, then try a different computer, if it’s still not being seen, then you might have damaged the USB cable on the Mayfly, in which case the only way to communicate with it is to buy a “CP2104 Friend” from Adafruit, solder 6-pin right angle header pins (male) to the end of it and connect it to the 6-pin FTDI socket on the Mayfly.  This bypasses the FT232RL FTDI interface chip on the Mayfly and allows you to program the board directly.

You don’t have to add the Mayfly to the Board Manager of the Arduino IDE if you simply want to view the serial output using the Serial Monitor of the IDE.  You only have to add the Mayfly support files to Board Manager if you want to program your Mayfly.  If your Mayfly is already programmed with any of our recommended sketches, it should be printing something to the USB port on startup, and usually during whatever loop it is running.  However, if you inherited this board from someone else, there’s no way to know what sketch is on it unless the Mayfly prints that information to the Serial Monitor.  Do you know what it was previously used for?

[Shannon Hicks]

We’ve seen that very rarely, usually it happens when the connection between the Mayfly and the sensor is bad, and the fault is either mechanical damage to the sensor cable (rodents chewing, flood damage, etc) or corrosion on the contacts inside the Grove stereo jack due to moisture inside the logger enclosure, or bad connection of the Grove cable between the stereo board and the Mayfly.  So whenever we see this sort of pattern in a CTD sensor, we replace the Grove cable and stereo jack, and 95% of the time, that solves the problem.  In the rest of the cases, it’s either damage to the sensor cable or the electronics inside the sensor itself are failing (usually due to impact to the sensor body from large debris during a storm).

But if you’ve already replaced the Grove jack (and the cables?) and you’re seeing this on more than one station, then it’s likely a code or voltage issue.  What version of the Mayfly board are you using (v0.5b or v1.0)? I don’t know how you’re powering the RS-485 sensors, but if they are being powered using a boost circuit that’s powered from the same voltage regulator on the Mayfly that powers everything else on the board (including the CTD sensor), then it’s possible that a voltage drop during the sampling period is causing the CTD sensor to now be fully powered, thus causing a communication issue between the Mayfly and CTD, resulting in the Mayfly reporting -9999 as the CTD sensor parameters.  Have you tried just unplugging the turbidity sensor from your setup (but don’t change the logger code) and see if you’re able to get reliable communication with the CTD sensor again?  If so, that would indicate the problem is related to the turbidity sensor being added.  Or it could just be a software issue due to timing or other problems with the sketch.  You can email me your sketch if you’d like me to take a look at it, once you’ve ruled out all the other obvious physical failures.

Other troubleshooting ideas:  If you’ve got one of the ZSC bluetooth sensor interfaces from Meter Group, you could test that the sensor is operating fine independently of the Mayfly, or you could program a spare Mayfly and connect it to only the CTD sensor (first with and then without a cellular board) and have it take frequent readings (like 1 minute) and let it run for a few hours to see if it drops any readings.

[Shannon Hicks]

The LTEbee adapter board you linked above was a special product we developed in 2019 for interfacing the Digi-brand LTE cellular boards with the Mayfly Logger.   The Digi board have been nearly impossible to buy since late 2020 because of production/shortage issues with the manufacturer and aren’t expected to be back in stock anywhere until later this year supposedly.  So we designed our own LTE cellular board which we called the EnviroDIY LTE Bee (https://www.envirodiy.org/product/envirodiy-lte-bee-pack-of-5/) and that new cell board was specifically designed to work with the Mayfly v1.0 board with no adapter needed between them.

The assembly manual we published a few years ago describes the process of using a Mayfly v0.5b board and the older Digi boards with the adapter, so your confusion is understandable.  We’re currently rewriting the manual to include photos and instructions for all the new hardware that was released a few months ago, including the new Mayfly and new LTE cell board.  I’m not sure of the exact release date of the updated manual, but it should be really soon.

[Author]

Posts