Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of WikiWatershed, a web toolkit designed to help citizens, conservation practitioners, municipal decision-makers, researchers, educators, and students advance knowledge and stewardship of fresh water. New to EnviroDIY? Start here

Campbell Scientific CS-215 SDI-12 communication issues w/ Mayfly

Home Forums Mayfly Data Logger Campbell Scientific CS-215 SDI-12 communication issues w/ Mayfly

This topic contains 18 replies, has 4 voices, and was last updated by  Sara Damiano 5 months, 3 weeks ago.

  • Author
    Posts
  • #12273

    Dave
    Participant

    Hi everyone,

    We have made some good strides getting a Mayfly logger network started here in New Hampshire thanks to all the information here on Enviro-DIYs forums. We can now collect measurements from multiple SDI-12 devices, store to an SD card, connected to a battery and RTC for sleep when not collecting.

    We’ve been thinking about adding a Campbell Scientific CS-215 (link) using a power relay and an external battery to provide it with 12V. There seems to be an issue connecting the Mayfly to the CS-215 though. We are able to provide it with an address using the address_change.ino script in the Envirodiy/SDI-12 examples. However, when we attempt to scan for addresses, the sensor is not found.

    The interesting thing is that when we use a Campbell Scientific Logger to communicate with the sensor, everything seems fine. That is leading us to think that there is an issue with the delay or timing in the script for the arduino-based logger. I’ve seen some others with this kind of issue (example) but have not been able to find a solution.

    I wonder if anyone here may have a thought about what could be the issue?

    Dave

  • #12275

    Sara Damiano
    Moderator

    Hm. I’ve done some pretty extensive rewriting of the sdi-12 library in the last month or so. Do you know which version of the library you are using? Can you try updating to the most recent version (1.3.1) if you’re not already using it? Can you post the full serial output your getting from both the address change example (b) and the data logging example (d).

  • #12287

    Dave
    Participant

    Hi Sara,

    Thank you for getting back to me. I’ll check the version of the library we have and will capture the serial output. We won’t be having a lab meeting until Tuesday so I will send it right after that. I noticed that there were updates last month so perhaps that will sort things out. In the meantime, thank you for helping!

    Dave

    • #12288

      Dave
      Participant

      Hi Sara,

      We spent several hours today trying to work with the CS-215. We did update and use the most recent library (1.3.1) but were still having issues with the two examples. For the address change example, all of the addresses were vacant, even though we had defined the sensor having an address previously using a CR1000 (Campbell) logger. The simple logger did not result in anything going to the serial – it said no sensors found and to check the physical connection.

      One interesting twist – for a while we were adjusting the delays in the address change script with the original (1.0.1) library. Every time the code ran, the sensor appeared at an address and we were able to change the address. However, when the script continued and rescanned all the addresses, the sensor was identified in a different address than what we told it to be at. This makes me think that there is some particular mismatch between the timing and delays that the sensor requires when passing data back/forth using the SDI-12 protocol, and what is in the library that works with other sensors that are not 12 volts.

      The only thing we can think of is that somewhere in the CS code for how a CS logger interacts with a CS-215 that gets the delays exactly right because Campbell knows the timing needed by that particular sensor. I’m not sure if it is possible to access that script and/or look in the manual to see if it is an issue with the specific sensor, but that is my guess. You may know where to look since you were involved in working with that library?

      Here is the manual

      Thanks for any advice or guidance you could provide,

      Dave

  • #12289

    Sara Damiano
    Moderator

    Hm. I doubt the mid-character times are the problem, but it is possible that the break or marking times are causing problems. You can try tweaking them a bit on the very top of the SDI12.cpp file.

    Instead of timing, it’s possible there’s a voltage problem. Do you have the sdi-12 data pin going directly to the Mayfly? Then the power and ground to another battery? The sdi-12 specification actually requires that the voltage of the “spacing” be over 3.5V. The Mayfly is only powered at 3.3V, so it’s not actually ever getting the voltage high enough to meet sdi-12 specs. The decagon and zebra tech sensors I’ve worked with have seemed to be fine with that but the Campbell might not be. Can you try putting a level shifter on the data pin to boost the voltage? I think a standard Uno runs at 5V so you could also try the basic communication on an Uno if you have one handy to see if it works.

    • #12328

      Dave
      Participant

      Sara,

      Just to loop back – we were in touch with Campbell and their suggestion was also along the lines of the 3.5V voltage requirement. In the meantime, we picked up a Meter Group (formerly Decagon) ATMOS-14 sensor which collects temp/RH/VP and it worked perfectly. Since we only had to install one, we just went with that.

      We’ll try to figure this out this fall/winter and once we do, I’ll make sure to update this thread for others!

      Dave

  • #12290

    Sara Damiano
    Moderator

    I’m sorry, I just looked back at your link from the first page and they mentioned they were using a Mega, which should be 5V. I don’t know. I don’t have any other guesses. Do you have an oscilloscope you can put on the line to watch the communication between the sensor and CR1000? If so, can you share the results of sending a single command to the sensor via the CR1000 and the same command between the Mayfly and sensor?

  • #12569

    Dave
    Participant

    Hi everyone,

    Just an update here. Due to the issues with the CS-215, we ultimately decided to go with the Meter Group’s ATMOS-41. It worked seamlessly with the Mayfly and our script and we had no issues with addresses or voltages. Seeing that it was relatively similar in cost, it was an easy decision. This evades the answer to the question, so this won’t be of help to those looking for how to use a CS-215 they may have lying about, unfortunately.

    Dave

  • #12787

    Greg Cutrell
    Participant

    Dave,

    Just curious if you ever revisited this issue over the winter? I am having the exact same issue with a Viasala WXT530 and YSI EXO. I did find a post where I guy successfully got his WXT530 to work back in 2017 (https://hankpai.weebly.com/sandbox/arduino-data-logger-vaisala-some-code). We are powering the devices with 9V and able to change the SDI-12 address of the WXT, but can’t get the SDI12_b_address_change program to find the device or get any response from the sensors. I also tried using a sparkfun logic level converter (https://www.sparkfun.com/products/12009), thinking the WXT530 signal is too high since it is powered by 9V, but I couldn’t even change the SDI address with the converter. I am using the 19.3 modular sensors library for my test.

  • #12801

    Dave
    Participant

    Greg,

    We never revisited the issue and instead just gave the address to the CS-215 via a CS logger. I know that our team installed an ATMOS-14 at the site, and got around power issues by just powering the sensors separately from the Mayfly board by using DIN rails. It really seems that the different power requirements between the board and the sensors don’t allow for easy address updating and connections.

    That said, I am also working on a project where we are going to be using some hydrological sensors and making sure that the Mayfly will work with a YSI sonde is pretty important. I wonder if Sara may have more insights?

    Dave

    • #12802

      Shannon Hicks
      Keymaster

      We’ve used a Mayfly successfully with a variety of SDI-12 sensors from different manufacturers, including ones that require 9v or 12v excitation. I usually use a custom simple logic level converter with most of them, similar to the Sparkfun item Greg mentioned above. However the only ones that gave us problems were the YSI 6-series sondes, so I don’t have any tips for working with those.

  • #12809

    Greg Cutrell
    Participant

    Thanks Shannon. Could you share the logic converter you have had success with? I like to give another logic converter a shot.

  • #12811

    Shannon Hicks
    Keymaster

    I had one project recently that required more than 30 Mayfly boards where each would interface with one SDI-12 soil moisture sensor array that requires 9v excitation. So I drew up this little custom PCB (not in Eagle), had it printed, and assembled the boards myself. It’s essentially one channel of the Sparkfun level converter board mentioned above, using a BSS138 MOSFET and two resistors. I also added a spot for a 9v boost converter board (https://www.pololu.com/product/2116) which also comes in 5v and 12v versions. It requires cutting the boards apart on a band saw, and then the hardest part is hand-assembling the 3 SMD parts, but if you’ve got a steady hand and a hot-air rework station or oven, it’s easy. I used a 3-position spring-latch terminal block, but you could use screw terminals or Molex pins as shown in the other photos.

    • #12827

      Greg Cutrell
      Participant

      Thanks Shannon! This is a clean way to implement a logic board to power converter! I have finally successfully retrieved and saved 18 values from our YSI EXO2, which itself requires a signal output adapter to transmit SDI-12, using the modular sensors library. This was done without using a logic converter and powering the EXO externally with 12V.

      My initial error was not taking into account the pin interrupts for the mayfly (I first used the basic arduino sdi12 code) so I was able to send the message but that is why I was not receiving a message. For reference Arduino-SDI-12#variants-and-branches.

      I have a working local header file for the YSI EXO and hope to commit the code and pull request in the next few weeks. I also found some limitations in the sdi12sensors library that need to changed to get more than 3 or 4 measurements from a sdi12 sensor. Once the sdi12sensors code is updated I would think any advanced instrument that produces many measurements via sdi-12 will be able to be used in a similar fashion as the YSI EXO header.

      • #12829

        Sara Damiano
        Moderator

        The “base” (master) branch of the SDI12 library should claim all possible on change interrupts so you don’t need to mess with calling them yourself. You only need to define the interrupts if you work off the ExtInts branch or if you compile with a build flag to set SDI12_EXTERNAL_PCINT. I think the latter is only possible in PlatformIO. If you’re using an example PlatformIO configuration file from the ModularSensors library, you should see the build flag set there.

        What changes needed to be made inside the sdi-12 library? Bigger buffer? Anything else?

  • #12832

    Greg Cutrell
    Participant

    Unless you can make a large enough buffer to accommodate 20-30 values the full proof other option is to have a way a to check if the number of received values equal the number of expected from concurrent result command. If it doesn’t then increase the dataOption value from D0! to D1! and so on. I piggy-backed off your code SDI12Sensors code and simply said if we are beyond the third value and a -9999 is returned, then try increasing the dataOption and send command. This worked for me but isn’t the best method. Ideally the loop would center around the variables the SDI-12 device has, which you called ‘numVariables’ and not the number of variables the user sets ‘_numReturnedVars’. We could follow my logic for checking for more data after finding missing data (-9999) OR parse and count the results from the initial .read(), check if it is equal to ‘numVariables’, if not then ask for more data and append to previous results, and check again and so forth till read variables count equal the ‘numVariables’.

    I also had to increase your sdiResponse.substring(4,5) to (4,6) to account for two digit variable counts.

  • #12833

    Sara Damiano
    Moderator

    @gregcutrell – The _numReturnedVars isn’t a “user set” variable in the typical way you might be thinking of it. It is *not* intended to be set by a user in a program. It’s intended to be set in the header file for a specific sensor. When creating it, the writer of the header file should know exactly how many values the sensor can and will return. Those lines are commented out because they really are only for debugging to confirm the sensor code works as it should.

    But your code looks like it should be good. Can you put in a pull request?

    • #12834

      Greg Cutrell
      Participant

      @saradamiano – I was going to bring up the _numReturnedVars issue when also doing a pull request for the YSI EXO. There are sensors out there, like the YSI sondes, where users typically set their own sdi-12 output so you can’t really create a header that has variables and variable counts set in there. It really needs to be done in the ino file. I’ve got the header working because I did the variable defines myself but it really needs to done in the ino file and carry over to the header file. I just wasn’t sure how to code it. I’ll tag you in github once I get the code in there for thoughts. Thanks

      • #12835

        Sara Damiano
        Moderator

        I haven’t encountered those sensors yet. Hmmm..

You must be logged in to reply to this topic.