[Shannon Hicks]

We’ve encountered a few SDI12 sensors that are more picky about the data line voltage being actually 5v instead of 3.3v, and when sensor excitation line needs 9v or 12v, then we definitely need something between the Mayfly and the sensor.  I’ve hand-built a bunch of little adapter boards (see attached photo) for those sensors, using a BSS138, some resistors, and a really cheap 9v or 12v step-up module from Pololu.  This seems to work for every sensor we’ve tried it on, but it’s not ideal.   I’m working on an even better SDI12 level shifting module using a different technique, but I’ll write more about that in the next week or two.

 

Attachments:

1. 

   20210415_144825-scaled.jpg
   

[Shannon Hicks]

Are you following the instructions from the top of this page to add the Mayfly board to your IDE:  https://www.envirodiy.org/mayfly/software/

You should be able to copy-and-past the URL of the json file into the appropriate place in the IDE Preference window and then the IDE will fetch the file and load it properly.  We haven’t made any changes to the board definition files in several years, so there shouldn’t be any problems.  What version of the Arduino IDE are you using?

[Shannon Hicks]

That panel wouldn’t be a problem.  Any panel that produces 6v will be safe for the Mayfly, but some cheap 6v panels actually produce higher than 6v in direct sun, so you should measure it (under load) in full sun to make sure it won’t output higher than the max input voltage of the MCP73831 (7 volts).  The solar charger on the Mayfly boards v0.5b and earlier will limit the charging current to 500ma output to the battery no matter what the solar panel power output is, so you won’t damage the battery.

[Shannon Hicks]

Are you using Windows or Mac for connecting to the Mayfly board?  Have you tried more than one USB cable?  Are these two unresponsive Mayfly boards brand new or are they running previously-programmed sketches?  Are there any LEDs that light up when you power the Mayfly board, either from a USB cable or a LiPo battery pack?  Is the small slide switch near the FTDI connector set to the “USB/Lipo” setting and not the “Ext” setting?

[Shannon Hicks]

Those sensors use Modbus RS485 protocol to communicate with a host device, which the Mayfly logger can’t do natively do with its current hardware, so you’ll need to add either an aftermarket RS485-to-TTL interface board, or build one like Anthony (@aufdenkampe) has done.  He, and a few other people on the forum, have deployed some Yosemitech sensors for quite awhile and should be able to provide some feedback about their performance.

[Shannon Hicks]

There’s not a direct replacement for that sensor, meaning one with the same operating specs and output.  There are some alternatives, but most are significantly more expensive, or require different interface hardware (like the Yosemitech sensors), or Turner Cyclops sensors (but require user calibration).  Unless you need a turbidity sensor immediately, I’d recommend waiting just a little bit longer and there will be some good sensor options unveiled soon.

[Shannon Hicks]

Campbell Scientific discontinued the OBB3+ sensor about a year ago.  They have new turbidity sensor models in development, but I’ll let them make the announcement about when it will be ready.

[Shannon Hicks]

No, the Meter Group sensor will not work with Modular Sensors if its address is set to ‘0’.  When it’s set to ‘0’, the data string is not in proper SDI12 delimeted format and Modular Sensors won’t be able to see anything.  Plus, the only way to get it to take multiple readings would be to turn the sensor power off and back on each time you want to take a reading, and use a Serial parsing code to capture the data instead of Modular Sensors SDI12 libraries.

So in order to use Modular Sensors code using SDI12 commands with a Meter Group sensor, you MUST change the channel to something other than ‘0’.

[Shannon Hicks]

Meter Group sensors that use SDI12 protocol (like the Hydros 21) come from the factory with a default SDI12 address of ‘0’.  Their sensors are programmed to output a serial data string containing the current measurement upon powerup if the address is set to ‘0’.  Meter Group’s dataloggers all talk to their sensors like this.  You can see it in action if you use a sketch using SoftwareSerial to monitor the sensor data pin and capture the serial data string immediately after you apply power to the sensor.  That would work fine if you were only using one sensor on the bus, and only wanted one reading.  Since we typically take 6 to 10 readings and average them, plus we usually have several other SDI12 sensors all connected to the same data wire, then having individual addressed for each sensor is imperative.  If you connect 2 or more Meter Group sensors to the same data pin and they’re both set to channel ‘0’, they’ll both attempt to send the serial string at the same time, and you won’t be able to capture it properly with the Mayfly logger.

In order for the Meter Group sensors to properly respond to SDI12 commands, they need to be programmed to any other channel EXCEPT ‘0’.

Most other sensors don’t have this specification, and we sometimes leave them as ‘0’ if we’re just testing it.  But for deployments, we’ve been using our own “in-house” channel allocations, just to keep things simple.  For example, our turbidity sensors are usually channel ‘2’ or ‘3’, oxygen sensors are ‘5’, etc.  That makes it a little easier to keep track of when juggling the sketches for hundreds of stations, each with different combinations of sensors.

[Shannon Hicks]

I saw this happen with someone recently who was having the same issue with data not showing up online and getting the 504 response code.  Turns out it was a missing UUID in the list of sensor variables in the Arduino sketch.  When there’s a mismatch between the string you send Monitor My Watershed and what it’s expecting, you get the 504 response.  I can’t see the original string that was posted before Sara edited to remove the UUIDs, but it appears that there’s a UUID missing from the string right before the last parameter (which I’m guessing is cell signal percent?)

So make sure there are the same number of parameters in the sketch as what the website is expecting, and that the sketch code in the two sections that deal with the UUIDs and parameters are matched up properly.

[Author]

Posts