Reply To: Hydros 21 Gen 2 -9992 values

As long as you’re using the latest Hydros21 library file that has the longer sample time (500ms warmup and 1000ms sample time, as shown here:  https://github.com/EnviroDIY/ModularSensors/blob/m

As long as you’re using the latest Hydros21 library file that has the longer sample time (500ms warmup and 1000ms sample time, as shown here:  https://github.com/EnviroDIY/ModularSensors/blob/master/src/sensors/MeterHydros21.h) then it sounds like maybe a faulty sensor.  Or it could be that the Mayfly isn’t waiting long enough to either warm up or wait for the measurement and you need to add additional time.  Do you have one of the Meter ZSC bluetooth interfaces for setting and checking Meter Group sensors? They’re really handy testing and troubleshooting things like their CTD sensors, and for changing the SDI12 address.

It would be important to know whether it’s the sensor that is reporting -9992 or if it’s what the Mayfly is saying.  Sara wrote lots of code in the ModularSensors library to use -9999 as an indicator that there’s missing information (usually from a sensor or accessory).  In most non-EnviroDIY libraries, an Arduino board might report 0 (zero) when it doesn’t get any data from a sensor or peripheral device, like when a device is unplugged or missing.  But if you’ve got a sensor that can legitimately report ‘0’, for a parameter (like a conductivity sensor that’s out of the water, or a cellular board with no signal strength), then it’s important to be able to differentiate between a real zero reading and a missing sensor.

But as far as I know, the Mayfly isn’t programmed to report -9992 for anything.  Do you only get that value when the sensor is plugged in to the Mayfly?  Does the Mayfly report -9999 for all 3 parameters when no sensor is connected?  Are you running a logging sketch or a simple test sketch?  If you use one of the simple example sketches from the EnviroDIY/SDI-12 library (like d_simple_logger) it will tell you exactly what the sensor is reporting, rather than what the Mayfly interprets.

You could also try putting the SDI-12 address back to ‘0’ and then power the sensor and watch the serial DDI string it prints out, thus bypassing the SDI-12 libraries all together, which again can help determine if it’s a sensor issue or a Mayfly library issue.

You should also disconnect all other external sensors from the Mayfly when troubleshooting communication issues because we’ve seen several instances of a CTD sensor losing partial or total communication with a Mayfly while a malfunctioning OBS-3 turbidity sensor was also connected to the Mayfly on another port.  Once the bad turbidity sensor is unplugged, the CTD starts working normally again.

Less...