Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of WikiWatershed, an initiative of Stroud Water Research Center designed to help people advance knowledge and stewardship of fresh water.
New to EnviroDIY? Start here

Please Help! Meter CTD Gen2 being blocked by Yosemitech 511-a

Home Forums Environmental Sensors Please Help! Meter CTD Gen2 being blocked by Yosemitech 511-a

Viewing 8 reply threads
  • Author
    • #17563

        Hi everyone,

        This problem has been causing me trouble for nearly a year, but it has become unworkable with installation of Gen2 Meter CTD sensors.

        My problem: Meter CTD (SDI12) and Yosemitech 511-a Turbidity (MODBUS) sensors seem to interfere with each other causing the CTD to sporadically drop out return -9999 values. This only occurred at some sites (around 4 out of 10) and all coding and sensors was identical.

        This was workable with the Gen1 sensor as the dropouts were less frequent.  However, the Gen2 sensor has interference with every single reading making it impossible to run these two sensors off the same Mayfly board.  If I remove the MODBUS wing, the CTD reads perfectly.  If I replace the MODBUS wing, the CTD reads -9999 values while the 511-a returns perfect turbidity and temperature measurements.

        What I think is Going On:  I think the return of information from the CTD is being over-ridden by Turbidity information.  The Gen1 CTD  seemed to have a faster response time (https://www.envirodiy.org/topic/hydros-21-decagon-ctd-reading-error/#post-17066) which meant that the modularsensors package was amended from a wait time of 500 milliseconds to 1000 milliseconds to accommodate the Gen 2.  I wonder if this longer wait time may leave the line open a bit longer which allows information from the Turbidity sensor to creep in.  Perhaps my previous problems with Gen 1 sensors were due to variance in the response times of each sensor?

        In very non-technical terms, I envision it like this:

        The Mayfly says ‘time for a sample, information please’.  The Gen 1 CTD would typically reply first ‘here’s some numbers’, followed by the same answer from the turbidity sensor.  Sometimes these messages would overlap (only at some sites – perhaps due to imperfections in the sensors?) making the message garbled and only the turbidity numbers clear.

        Now, with the update of modularsensors to 0.33.3, I think the Gen 2 CTD and the Yosemitech 511-a respond at the same time (i.e., the CTD responds slightly later) making every message garbled.  The turbidity sensor obviously has a louder voice so only those numbers come back.

        <b>Towards a Solution: </b>I am pulling my hair out trying to solve this, but I think I need help from our experts @shicks and @srgdamiano.

        Is there a way to get modular sensors to ask the CTD for data and wait until the CTD responds before asking the 511-a for data?  I’m wondering if splitting these calls up may solve my issue.

        I’m open to anyone else’s opinion as well.

        Thanks in advance for your help.



        Previous posts about this problem can be read here:




      • #17564
        Sara Damiano

          The ModularSensors library is running the SDI-12 sensors in “concurrent” mode and the modbus communication only happens when initiated by the logger.  So the two sensors really should not be trying to talk to the logger at the same time.  ModularSensors first asks each sensor to start taking a reading, then goes back and asks each one for its results in the order that they’re expected to be ready.  You can try using the build flag -D MS_SDI12_NON_CONCURRENT in your PlatformIO.ini.  That will tell it to start a reading and then wait the full time for a reading to finish before the starting the next sensor. Note that the flag only affects SDI-12 sensors.

          If the same code is working in some places but not in others, I would suspect the problem is electrical, not code.  That is, some combination of instantaneous voltage instabilities when both sensors are working is garbling the communication.  The SDI-12 library is “bit-banged” so it’s very weak to interference.  Shannon or Neil may have better ideas on ways you could try to electrically isolate the sensors from each other.

        • #17566
          Shannon Hicks

            We’ve been using Y-511a sensors together with Gen 2 Hydros21 CTD sensors and have had no problems with communication, however we’re using our own modbus adapter (based on a MAX13412 chip) instead of the Neil’s modbus wing.  As Sara said, the sensors shouldn’t be talking the the Mayfly at the same time since the Y-511 has a 40-second warmup time, followed by a 8-second sampling time, so the Mayfly doesn’t hear anything from the Y-511a for almost a minute after it is powered up.  I’m not sure if the modbus wing you’re using has a level-shifter on the SDI-12 data line, but we found that most level-shifting circuits cause inconsistent communication with the Meter Group sensors, probably because the logic high level of their sensors is only 3.6v, which in our experience is safe enough to connect directly to the Mayfly’s digital input.

          • #17569

              Thank you both for your reply.  Okay, so it seems that I may be barking up the wrong tree with that one.  I will try Sara’s build flag to see if that works, but I’m not holding my breath.

              I have my SDI12 jumper pins for the CTS set on 5v.  Could this be the problem?  For some reason I couldn’t get the Gen1 CTD’s to work at 3.3v, but they worked at 5v so I set them all as that.

              FYI, I am using the modbus wing-shield here:


              Thanks again for your help.





            • #17573

                @shicks, would you mind publishing your Y-511a +  Gen 2 Hydros21 CTD code so I can ensure I haven’t done anything wrong on that front?

                Thanks in advance.



              • #17574
                Shannon Hicks

                  Here’s my code that has been successfully working on a Mayfly v1.1 RevB board, with a Hydros21 connected to the D4-7 Grove jack (with jumper set to the switched 3v setting) and a Y-511a and our custom RS485 adapter connected to the D5-6 jack and an external (non-Mayfly) 12v source supplying power for the Y-511a.


                • #17581

                    Hi @shicks and  @srgdamiano.  You’re not going to believe it but the addition of the build flag below has fixed my problem, at least for the Gen2 sensors.

                    I am certain it is this build flag and not the voltage pin (previously set to 5v) because I uploaded my script prior to switching the voltage pin over and it suddenly sprang into life.  I have subsequently changed the pin over to 3.3v for good measure.

                    I will keep you updated.


                  • #18239

                      (I am placing this comment here rather than start a new topic because of similarities)

                      We have two stations that developed the same problem in August of 2023. One station is here:  https://monitormywatershed.org/sites/GVWA%20107/

                      Both were V1.0 Mayfly with the LTE Bee, Hydros21 CTD and Yosemitech 511-a Turbidity sensors with the Modbus-Mafly-Wingshield .  The Hydros21 is using the new 500 and 1000 ms timings and the voltage jumper is set to 3.3 volts.  The wingshield is getting 5 volts switched from the header (pin 11) and using the U3V12F9 boost regulator.

                      First symptoms in August were the CTD returning -9999 and -9991, which are bad measurement and low voltage error codes.

                      We replaced the V1.0 boards with V1.1 rev B boards this week but the problems persists.   However, disconnecting one or the other of the sensors results in normal operation for the connected sensor.  Is it likely that there is insufficient power getting to the sensors during sensor operation? If so, could I try:

                      • getting 12 volt for the 511-a from pin 9 on the header (now that the 12 volt boost has been upgraded) and removing the U3V12F9?
                      • the above, but also altering SJ25 to get 9 volts?
                      • change SJ27 and monitor for voltage sag?

                      It is always possible to run a jumper from the LIPO header to a second board as a workaround.

                      Thanks for any insights,



                      • #18243
                        Shannon Hicks

                          The Yosemitech Y-511A needs 12v to operate, so it won’t be happy if you modify the Mayfly jumper to set the 12v output to 9v.  I’m not familiar with the operation of the modbus wing you’re using so I can’t comment on its operation, but we have a new modbus adapter board with it’s own beefy 12v-boost Grove adapter board that will be available in the shop in a few weeks, so I think that might be something for you to try.  I can send you an email about it, and we’ll be posting examples here once they’re ready for release.

                      • #18253

                          Thank you for the quick response, we are looking forward to the new modbus adater.  Meanwhile, we made some quick changes to  existing wingboards to power the Y-511A from the 12v available on the V1.1 rev B, with good results.   One station is back to normal and the other should be as soon as the updated wingboard is installed.  Thanks!

                          Edit 12/22/23:  The change to the wingboards did not resolve the issue, but did change the data the Y511-a was sending from -9999 to 0.0

                          Edit 2/9/24:  Turns out the wiper on the Y-511A was rotating outside of its normal operation and got stuck on an adjacent PVC fixture.  If the wiper rotates 360 degrees instead of just wiping back and forth, the rubber wiper will overhang the stainless steel body of the Y-511A, and collide with other things.   The stuck wiper was pulling a lot of current, and possibly causing voltage sag on the Mayfly.  Unstuck now, and appears to be operating normally.

                      Viewing 8 reply threads
                      • You must be logged in to reply to this topic.