[Shannon Hicks]

Thanks for the screenshot, that shows the Mayfly board is being seen by the computer, so it’s not a cable or Mayfly issue.  But Windows doesn’t know how to use the Mayfly correctly as a USB device because Windows didn’t automatically install the necessary drivers.  I’m assuming this is the first time you’ve connected a Mayfly v1.x board to this particular computer?  On most Windows computers the driver installation is automatic, but in cases where it doesn’t happen automatically, you just have to manually do it.  There’s a link to the SiliconLabs website on this forum thread from about a year ago: https://www.envirodiy.org/topic/usb-to-uart-mayfly-serial-ports-not-connecting/

[Shannon Hicks]

We use Android devices for any portable interfaces in the field, along with an FTDI cable attached to the 6-pin FTDI header of the Mayfly.  The Mayfly v1.1 has it’s own CP2102 USB chip on board that works through the USB-C jack on the Mayfly, but Android devices can’t natively use it because they don’t recognize the CP2102.  Plus with the inconvenient angle of the Mayfly’s USB jack anyway, it’s just more convenient to use a standard FTDI cable on the Mayfly’s FTDI header.  Just have to be sure to get the pin orientation correct!  Previous Mayfly versions (v0.5b and earlier) had an FT232 chip onboard, so it was possible to connect an Android device directly to the Mayfly through the micro-USB jack (using an OTG adapter on the cable too), but again the mounting of the USB jack isn’t convenient for access when a logger is installed in our usual enclosures.

Since I’m not familiar with iOS devices, all I know is that the last time I researched the issue, iOS doesn’t officially allow direct connection of serial (or TTL) accessories to Apple devices through the lightning port, plus there are no official apps in the App store even if you could buy a cable.  There are some unofficial interface cables that some companies have made that may or may not work with a device like the Mayfly, and you supposedly would then have to use software to create your own app to actually handle the data.  So in the end, everyone who has asked me about this issue with a Mayfly ended up just using an Android device and an FTDI cable.  (just be sure the FTDI cable or board is based on the FT232 chip and not a CP2102, for the reason mentioned above).

Since reading live data in the field directly on the Mayfly board can be very helpful sometimes, I developed this small OLED display a couple years ago: https://www.envirodiy.org/product/envirodiy-oled-half-shield-pack-of-5/   It works great with basic sketches, and can be switched on and off in the code to save power (like having the Mayfly’s onboard light sensor automatically sense the light levels and only activate the display when the enclosure lid is open, or when someone presses a button). We’re still working to incorporate it into the existing ModularSensors logging sketches that are usually used in our full deployments, but it could eliminate the need for phone interfaces for some users.

[Shannon Hicks]

If you disconnect your Mayfly board from the computer, does COM3 still show up as an active device on your computer?  I’m guessing that COM3 is actually another com port on your machine, like a bluetooth or other USB device on the motherboard.  If your Windows computer correctly identifies the Mayfly board, it will shows up as “Silicon Labs CP210x USB to UART Bridge”.  If you’re not seeing it being added to the list of USB devices in Device Manager when you plug it in and then disappear when you unplug it, then Windows isn’t seeing the Mayfly as a valid USB device.  This is usually cause by a bad connection or wire in the USB jack or cable.  So try using another USB-C cable (preferably a nice heavy-duty one and not just a generic charger cable.  A Mayfly board can still be powered on and function normally with just the power wires in a USB cable.  It needs 2 data lines in the cable to actually achieve the communication part between the Mayfly and the computer, and those wires can be easily broken.

If your computer still doesn’t see if after swapping cables, then check to see if it’s being seen as an unknown device (or Other Device).  Windows should detect the Mayfly v1.x as a CP210x device and automatically install the correct drivers, if you’ve got your Windows Update setting configured to either automatically install drivers for new devices, or to prompt you for permission to install the drivers.  But sometimes Windows is locked down so that no drivers are installed and no prompts pop up, so you have to manually download the driver from the SiliconLabs website, or point Windows driver update tool to the correct location.  I can give you more instructions on how to do that, but the majority of the time swapping to a new cable fixes the issue if it’s not driver-related.

[Shannon Hicks]

I spent the entire weekend trying to recreate the SDI-12 communication issue with the ClariVue sensors by placing a bunch of Mayfly loggers and turbidity sensors in my freezer and refrigerator in various combinations.  I was able to isolate the problem to the Mayfly v1.1 boards not being able to produce sufficient instantaneous current at 12 volts when the ClariVue is first powered up when Mayfly board temperatures are below approximately 5 degrees C.  The exact temperature depended slightly on the individual Mayfly board, but more important was the version of the ClariVue sensor.  We have some that were made last year and some the were made about a month ago, and I found that the power requirements and timing of the SDI-12 commands were slightly different between the two.

Even at room temperature, I found that some of the measurement commands to the sensor weren’t always successful with the warmup and measurement times as originally defined in the CampbellClariVUE10.h file (5.5 seconds and 9.5 seconds, respectively).  Changing them to 8 seconds and 11 seconds resulted in 100% success rate at room temperatures (and all the way down to -20C with the sensor powered by an external source).  I just updated the .h file on Github, but you can simply edit your existing file with a basic text editor (not Word) to change the warmup time in line 88 from 5500 to 8000 (remember that Arduino code uses milliseconds to denote time intervals), and change the measurement time in line 99 from 9500 to 11000.

But to address the sensor power issue, we will be revising the 5-volt and 12-volt circuitry on future Mayfly board versions to switch back to the original design that worked in prototype testing a few years ago but couldn’t be implemented into full production because of semiconductor shortage problems at that time.  We’ve still got a bunch of those prototypes deployed and powering high-current 12-volt sensors with no problems, it was just unfortunate that we weren’t able to use those parts in the board production because they were impossible to buy for the past 2 years.

In the meantime, you can easily modify your Mayfly v1.1 boards to generate 9 volts instead of 12 volts, and I tested all of our ClariVue sensors and various Mayfly v1.1 boards using this 9-volt setting and had no trouble powering and communicating with the sensor from -20C to +30C.  On the back of the Mayfly board, there’s a solder jumper labeled SJ25 that says “12v/9v”.  It’s default position as shipped from us is open, meaning you’ll see two little separate gold pads.  You just have to bridge those two pads together with a tiny blob of solder to configure the board’s circuitry to generate 9V instead of 12V.  So on the front of the Mayfly board, with the pin jumper next to a SDI-12 Grove jack set to the 12V, you’ll actually get 9V there, and your ClariVue sensor should still work fine and continue to communicate with the Mayfly even if the Mayfly air temp goes way below freezing.  I’ve included a photo showing what the back of the Mayfly board should look like once you’ve put a solder blob on the SJ25 pads to enable the 9-volt setting.

 

Attachments:

1. 

   sj25.png
   

[Shannon Hicks]

We’ve never had any hardware failures of our sim7080 module in the field when using the sketch mentioned above.  With hundreds of them deployed in the past 18 months, the only problem we occasionally see (one or two stations a month) is where they stop responding to the Mayfly board and kind of “lock up” and need to be reset.  This is usually accomplished by just cycling the power switch on the Mayfly board and everything returns to normal, thanks to all the module initialization code Sara put in the libraries and the sketch that run at startup.  But sometimes just a power cycle isn’t sufficient and the LTEbee has to be unplugged from the Mayfly’s bee socket for just a second, and then plugged back in.

[Shannon Hicks]

Most I2C devices don’t like having the power to the device cut and the reapplied, which is why the Vcc pin of the Mayfly’s I2C Grove jack is constantly powered.  All the other Grove jacks switch the power on or off, but the I2C jack always has 3.3v, even with the Mayfly is asleep.  So if you’re powering your Atlas board from any of the switched sources, try putting it on the constant 3.3v pin.  If you’ve already tried that, then it’s probably something in the code that’s causing the issue.  I don’t use any of the Atlas products, but a few members here have successfully used them, so perhaps they could share what code and hardware configuration was used? @w3asa @adamgold @fionasouthwell

[Shannon Hicks]

I think @srgdamiano should be able to help, since she has the best understanding of the libraries and commands used with the sim7080.

[Shannon Hicks]

How are you connecting the sensor to the Mayfly (what pins for data and power and what jack), and are you putting the Mayfly to sleep between readings?  Is the sensor being powered constantly or are you switching off the power to the sensor between readings?

[Shannon Hicks]

What Mayfly board version are you using?  The ClariVue10 seems to only work reliably with the Mayfly v1.1 RevB since it produces the most stable 12 volt output.  Also, we’ve found that at room temperature the ClariVue needs about 8 seconds after the switched power is applied before it will respond to any commands, and then needs another 9 seconds to complete the actual measurement.  It could be that the temperature of either the sensor or the logger is causing that interval to be longer than the code expects, causing a mis-communication between the logger and the sensor.  We currently have a ClariVue10 sensor installed in a river with a Mayfly v1.1RevB, the water temperature right now is 4C and the air temp is 6C, and all data is normal.

[Shannon Hicks]

Without knowing more about what board you’re using for the logger, or the software that runs on it, it’s hard to guess what the problem is with your system.  But I know that when we first used Arduino Uno boards for loggers about 10 years ago, we found that they became unreliable and inaccurate at high temperatures, both in terms of timing and analog voltage measurements.  And if your logger or various components are specified to run at 5 volts, but you’re powering things with a 12v battery, then whatever voltage regulators are on the boards are having dissipate a lot of heat in order to drop the supply to 7 volts.  That heat, along with hot ambient temperature, could be causing issues too.

[Author]

Posts