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

SDI-12 & LT500

Home › Forums › Mayfly Data Logger › SDI-12 & LT500

Viewing 2 reply threads
  • Author
    Posts
    • 2021-04-06 at 2:59 PM #15350
      neilh20
      Participant

        Hello @srgdamiano

        I really appreciate there is a lot of work that has gone into the layers of SDI-12 protocol. I’m using it to communicate with the  Insitu LT500. I only have one as they are expensive and its part of a project that can spare it at the moment. With the  Arduino-SDI-12 v2.1.3 release the LT500 response has stopped being decoded, but it works on a previous untagged v2.1.2 that I have.

        In initially interfacing the LT500 to ModularSensors\src\sensors\SDI12Sensors and Arduino-SDI-12  last year, it  just worked. Thankyou Thankyou.

        However with recent releases it has stopped working, and I’m digging into it, and seeing how many layers there are to make it work with a simulated 1200baud UART, pretty amazing layers of code. Thankyou thankyou again for all the different people who have made it work.

        Whenever I turn on debug for SDI12Sensors\SDI-12(v2.1.2) the LT500 stops decoding the protocol – Mayfly tx timing goes out I’m guessing. I’ve been using  a Salae logic analyzer to detect what is happening on the line. And of course with the latest SDI12(v2.1.3) the Mayfly rx timing decode seems to become a problem,

        So I’m just wondering, if its easy to say, what works for you with debugging SDI12Sensors.cpp/SDI-12.cpp , and what is the reference sensor(s) that you test against.    Many thanks.

      • 2021-04-07 at 11:27 AM #15352
        Sara Damiano
        Moderator

          I added 10 extra ms of wake time in v2.1.3.  You can revert everything back to the original by adding a second argument of 0 to your send command functions.

          Attachments:

          1. Screenshot-2021-04-07-112739.png

        • 2021-04-07 at 12:20 PM #15355
          neilh20
          Participant

            Thanks for the input, ~ Yup that is what did it for interfacing with the LT500.  I brought in each change from Dec 1st till I found it

            Doesn’t make a lot of sense to me why that impacts the protocol, but in dealing with a bug, the first stage is Detection, 2nd stage is Isolation, 3rd stage is Fixing it.

            The Isolation in this case took a couple of days.

            The software process is modify and test, and then integration test. In this case what is lacking (for me)  is having a defined reference for the SDI-12 sensor.  It also seems that working with the LT500, there are retry’s that finally work. So its a general problem with this kind of dispersed protocol testing. USB protocol testing is a lot worse, and they solve it by having plug-fests. But then there is a lot of money in selling USB devices.

            I have been keeping my eyes open for a low cost reference sensor, ideally that would be open source as well, but I haven’t found one yet.

            I’m thinking that for me, since SDI-12 is so fragile, and its not clear how to verify changes except by running them against reference sensors I should manage any changes happening more closely – fork the libs concerned. Just thinking out a loud.

             

        • Author
          Posts
        Viewing 2 reply threads
        • You must be logged in to reply to this topic.