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.

Multiple SDI12Recorder() instructions running together

simon Apr 20, 2020 12:08 AM

I have a project where I have two SDI-12 sensors.

Sensor 1 has a measurement time of 12 seconds.

Sensor 2 has a measurmeent time of 60 seconds.

What I'd like to do, is to have Sensor 1 measured every 20 seconds.

Sensor 2 will only be measured every 10 minutes.

With both sensors on the same channel (eg C1), I can't get the 20 second measurements of Sensor 1, while Sensor 2 is measuring (M!) as the C1 channel is tied up.

Now, I thought that if I used C! commands, I could still poll Sensor 1, while Sensor 2 was in the 60 second measurement delay, but my experiments with this in the past showed that that wasn't possible.

So, I thought that if I allocate a different seperate channels for each sensor (C1 and C3), that this might open up the possibility of doing what I need. Again, my experiments in the past indicated that this didn't change anything, which led me to the conclusion that maybe there is a single SDI-12 "stack" (for want of a better term), meaning that only a single SDI-12 "conversation' can be handled by the Operating System at any one time. Possibly due to internal timers that track the measurement time?

My first request is to have someone confirm that this (above) is not possible.
I'd be very happy to know if I've made an error somewhere, and there is actually a way to always acheive the 20 second measurements of Sensor 1, even when Sensor 2 is measuring. It's possible that there have been OS changes since I last visited this, which was some years ago. I am asking now as I am working on a new project which needs this same behaviour.

I notice the following information in CR1000 CRBasic Help for SDI12Recorder (WaitonTimeout parameter).


WaitonTimeout is an optional parameter added with OS 29 and greater that when set to 1 specifies that the C! command will wait inside the instruction for the sensor’s advertised timeout and then issue the D! command to record the data.

The CR1000X Help in CRBasic for SDI12Recorder (WaitonTimeout parameter). says:

WaitonTimeout (Wait for Timeout)

An optional parameter that when set to 1 specifies that the C! command will wait inside the instruction for the sensor’s advertised timeout and then issue the D! command to record the data. This allows multiple sensors to be measured with a single instruction call.

This sounds like it "might" do what I need.

This is my second request - Will the CR1000X offers a different result to the CR1000 for this scenario?



JDavis Apr 20, 2020 09:51 AM

A CR1000 with OS 29 or newer should handle the SDI-12 recorder instruction the same as a CR1000X would. 

M! commands are exclusive communication on a SDI-12 channel per the standard. Any command on the same channel while waiting for the sensor to measure will abort the measurement. The C in C commands stand for concurrent. If properly implemented in a sensor, you overlap measurement time on the same channel. 

In your case, you need to put each sensor on its on channel on the datalogger. The easiest way to handle the programming in the datalogger with things wired that way would be to put the measurement of the slower sensor in a separate scan.

Use the SlowSequence instruction to add the second scan.


  Scan (15,Sec,0,0)
    SDI12Recorder (Sensor1Data(),1,0,"C!",1.0,0)

    CallTable Test
  Scan (60,Sec,3,0)
    SDI12Recorder (Sensor2Data(),3,0,"M!",1.0,0)


simon Apr 20, 2020 11:16 PM

So Sensor 1 will be able to perform the C! commands on C1 while the logger is waiting for the 60 seconds of Sensor 2's M! measurement time on C3?

This does seem different to what I saw last time I tested.

I don't have the sensors to test this again yet, but I will do when I have them.


simon May 20, 2020 12:22 AM

Thanks for the answer here.

I've tested this now on CR1000x and it is working as you suggested. So thanks for your answers.

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