Our full technical support staff does not monitor this forum. If you need assistance from a member of our staff, please submit your question from the Ask a Question page.


Log in or register to post/reply in the forum.

SDI12Recorder


CJ May 4, 2010 02:39 AM

As I understand sending a "M!" command with "SDI12Recorder" will send a "D0!" after the sensor response time expires.

Is it possible instead to send a "M!" command and "D0!" command in seperate instructions so that the program does not pause while waiting for the sensor?

I need to do this as our SDI12 level sensor works with "M!" but not with "C!" (Note CR800 OS6 worked fine with "C!" but newer versions do not, it is the same with the CR1000).

I have checked the sensors reponses using Terminal Emulator and both "M!" & "C!" commands buffer the same value but using the CRBasic "SDI12Recorder" command it produces "NAN"


Grant May 4, 2010 04:29 AM

CJ

I had this exact same problem last week, all my woes began with updating the OS to OS10 (CR800).

How I got past the problem was to use a slowsequence command to execute the SDI12recorder command at a slower interval than the main program is running. (Thanks Simon!)

Try pasting this code at the end of your program (before the EndProg of course)

Slowsequence
Scan (2,Min,3,0)
SDI12Recorder(Destination,SDIPort,SDIAddress,"M!",1.0,0)
NextScan

It worked for me, so give it a try.

Cheers

Grant


aps May 4, 2010 11:35 AM

Can you please tell us what the sensor is that does not work with OS 18 please so we can investigate this.


CJ May 5, 2010 06:24 AM

Thanks for the info Grant we may have to do that.

The sensor we are using is the ES&S PumpPro 6150 level sensor however it also happens with the 6100 version.

In the mean time we have been checking the SDI-12 communications between the logger and sensor. We have also tested a Hydrolab Sensor configured with just pH for comparison (which works on the newer OS CR800 & CR1000). The most obvious thing we noticed is the data format where the ES&S sensor replies with:
00291 (Address 0 / 029 Seconds Wait / 1 Parameter)
and the Hydrolab:
103501 (Address 1 / 035 Seconds Wait / 01 Parameter)

The logger then sends a 0D0! to the level sensor and inturn receives the expected data (0+0004.795), however it then goes on to send a 0D1! and receives an invalid result which overwrites the good data, which explains why we get NAN as a result.

Is 0D1! Being sent correctly?

This is the code we normally use to read the level sensor:
#########################################
If IfTime(4,5,Min) OR ReadSensors=-1 Then SDI_Cmd="C!" Else SDI_Cmd="C"
SDI12Recorder (Level_Raw(),3,0,SDI_Cmd,1.0,0)
#########################################

And here is a short dump from the Terminal Emulator in SDI12 Snoop Mode:

###ES&S LevelPro 6100 / ES&S PumpPro 6150###
T 11:24:10.02 0C!
T 11:24:10.12 00291..
T 11:24:10.12 ..&B....N 0D0!..&B......0+0004.795....&B..... 0D1!..&B......0....&B.....

###Hydrolab MS5 Sensor###
T 13:24:00.03 1C!
T 13:24:00.13 103501..
T 13:24:00.13 ..&B....u01D0!..&B....".1+7.76..

(Also on a separate note for some reason there is no R for Recieve only T & the time stamp does not update and also noticed it jumps around erratically)

At the moment we have only had success with the M! command in a slowsequence:

#########################################
SlowSequence
Scan (1,Min,0,0)
If Read6150=-1
SDI12Recorder (Level_Raw,3,0,"M!",1.0,0)
Read6150=0
EndIf
NextScan
#########################################


Grant May 5, 2010 06:36 AM

CJ

With my particular issue, I was scanning at 10 seconds, but the Sontek Doppler had a 120 second average time. My guess was there wasn't enough time for the Doppler to respond before get another new "C!".

What is your scan rate? I notice the response time for the depth is 29 seconds and the pH is 35 seconds, may well be the same issue I had, hence why the 1 min slowsequence is working.


CJ May 6, 2010 01:49 AM

Hi Grant,

Our scan rate is also 10 seconds however in our program we use C! to take a measurement and the subsequent scans use C to read the measurement, this is then put in a loop to run every 5 minutes so that the senor has plenty of time to take a measurement and the 10 second scan time does not have an impact.

We would prefer not to use the M! command in the slowsequence as it still holds up the program and results in Skipped-Slow-Scans instead of Skipped-Scans.

We are thinking that when the level sensor is replying to the logger after receiving a C! command the format of the returned number (00291) is one digit shorter than the logger expects (002901) which is then causing the logger to send D0! & then D1! instead of just sending D0!

Maybe someone from Campbell could comment on this?

(Also the firmware history does not mention any changes that impact SDI12 in this way after CR800 OSv6)


aps May 6, 2010 02:54 PM

We are looking at this. However, can I refer you to the latest copy of the standard:

http://www.sdi-12.org/sdi-12/SDI-12_version1_3%20January%2012%202009.pdf

This does show that your ESS sensor is sending a response one digit short in response to the C! command which may well be the cause of the problem.
(For some reason the standard is that the number of digits for values to send should be one digit for M! and two for C!) It is likely the logger thinks it needs to get 10 values from the ESS sensor which is why it is asking for more.

There was a change made in CR1000 OS17, which states:

"Changed SDI12Recorder so that if the variable command is 'C' instead of a previously issued 'C!", the datalogger will return 1e-9 until the timeout response from the previous "C!" expires. At this time it will query for the data and return the data (or NAN if unsuccessful) and exit, without issuing a subsequent measurement command."

Whether the previous behaviour of the logger hid your current issue I am not sure. Bottom line is the ESS sensor is not complying with the standard for the C! command.

To avoid the skipped scans for the slow sequence you would need to set the scan rate to be >30 sec IF that is your only SDI-12 sensor. If there are others you would need to put them all in the same slow sequence with a scan long enough to deal with all of their max response times OR attach the sensors to different control ports on the logger (if you have spares).

* Last updated by: aps on 5/6/2010 @ 9:35 AM *


CJ May 9, 2010 11:17 PM

Thankyou APS,

We have contacted the manufacturer to try and get this issue fixed on their new firmware.

Log in or register to post/reply in the forum.