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

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).

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.

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?

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.

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

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.

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.

@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?

Hi,

As it seems the Enviro lib still have the same problem with the CS215, I think I actually found a fix, so i wanted to share it with you guys.

I’ve updated the Arduino thread linked in the first post. But I’ll put the same explanation here:

The Enviro lib does not fully respect the SDI-12 protocol. There is one important timing aspect which is completely missing from the lib. In the spec we can find the following statement:

“A sensor must wake up from a low-power standby mode and be capable of detecting a start bit from a valid command within 100 milliseconds after detecting a break”

In the Enviro library a SDI-12 command is directly sent after a wake up frame which is consisted of a 12ms spacing + 8.3ms marking (see sendCommand functions). I believe in most cases cases, sensors are implemented in such a way that they actually do wake up “just” after the detection of 12ms spacing (or not sleeping at all). The 8.3ms marking being more than enough time for them to wake up. The CS212 doesn’t seem to belong in that category. It takes A LOT of time for it to wake up (at least 60ms to consistently answer from what i have found out).

Adding (in my case) a 100ms delay, between a wake up frame and a SDI-12 command , as per requested in the spec, fixed the problem, for me.

Hope this can be helpful. If it is, I guess someone should update the lib =)

Have a good day, stay safe.

Looking at this posts as a discussion on general SDI-12, I have the Mayfly interface working for a Insitu LT500 Water Level monitor in a prototype capacity.

The LT500 requires an 8-36V Excitation, so I put in a series booster,  +12V   https://www.pololu.com/product/2117, and connected the other end to Grove 4pin JST-PH cable (std one cut in half)

I did use the standard SDI12 lib, and just created a header file for the InsituTrollSdi12.h for the interface. So very easy.

Thanks for everyone contributing to SDI-12 to make it so easy.

I’d be happy to post back the InsituTrollSdi12.h if anybody wants.

It does take a little setup on the LT500 mapping the sensor value on polling to where the SDI12Sensors.cpp expects it – though my notes are a bit hazy on what I did.

Since the SDI-12 spec defines clamping excess voltages to ground (lightening/ESD),  today I’m in the process of creating a true SDI-12 physical interface with the level shifter BSS138 ~ one side pluggable into a Grove 4pin/5V, and the other side taking the SDI-12 3wires.

Be happy to share the PCB/cct/BOM with anybody interested.

The target is to deliver the results over a Verizon signal ~ thanks to @mbarney for suggesting the Digkey SIM and data plan https://dataplans.digikey.com . It does require setting the apn to VZWINTERNET. Its not as easy as hologram to setup.

I left it at the “marking” level. Here is your typical CS215 SDI-12 frame with said modification to the lib. I think this is an ADDR request (I decoded it but can’t find my notes anymore).

You can see part of the wake up frame at the beginning then the “long” 100ms wait period.

Did you try adding the wait to the break before the marking?  Does that work?

I modified the SDI-12 library to allow an optional extra warm-up delay, but I but the wait while the line was in break/spacing rather than in marking.  I didn’t want to add the time to the marking because while sensors must be able to respond to a command within 100ms of detecting the break, they must also go back to sleep if the line is held in marking for more than that 100ms.

That is true, I missed this in the spec. I did not try to add it while at at “break level”.

I’m guessing most (if not all) SDI-12 sensors wake up on a rising edge then start their timers from there. I think it will work all the same while respecting the SDI-12 spec.

I’ve actually got a few sensors now. As soon as I’ve got the hardware to drive them, I’ll try changing the “waiting level” to a break, see if that changes anything.

I can confirm Sara’s idea to wait before the marking and not during seems to be more reliable, I had an issue where (rarely) the sensors did not answer to a measurement request, this seems to fixed this.

It is hard to be 100% sure about this since it doesn’t happen often but it seems to be better this way, and since it is also SDI-12 spec compliant this is certainly the way to go.