Something I should know that I don't... I'm trying to troubleshoot an issue we're having with an SDI12 sensor. When I look at the "Comms Watch" (sniffer) in the CR1000 terminal, it always show the sdi12 command transmitting twice. For example:
T 19:18:54.43 0R3!
T 19:18:54.51 0R3!
R 19:18:54.73 0+7.5+3.1+6.4+100.0
T 19:18:54.85 0R4!
T 19:18:54.93 0R4!
R 19:18:54.73 0+208.1+203.8+213.3+10.7
Is this actually sending a double transmit or what am I seeing here?
I have seen this before also. I believe this is what happens when a SDI12 sensor 'times out'. My best guess is the CR1000 will continue to send subsequent M/C/R! commands if it does not get a response after 15 milliseconds apparently (as per the sdi12 spec - I see a new spec v1.4 has been released in August). Some clarification on this would be helpful.
What is the sensor you are trying to communicate with?
Do you have other SDI12 sensors on the same channel? (I presume yes.)
Have you tried just a single SDI12 sensor on the channel?
What is the cable length of your SDI12 sensor? Total cable length between all sensors on same channel?
I only have one sensor on the sdi12 channel. It's a Lufft ws500. I am reading multiple buffers from it to get all weather data back from it. I have about 5m of cable running to the sensor.
Your setup looks like it should not cause a 'time out'. Have you tried turning it off and then back on again? <sarc/>
Haha. The end all answer for everything. We have this happening on two different sites that are remote with cell modems. I'm wondering if it's actually a double transmit because that would cause the sdi12 interface on the sensor to timeout every once in a while...
Not all SDI12 sensors are created equal. I would suspect you are correct about the sensor timing out with the double transmit. I have seen similar types of situations where the 'aggressive' restransmission of the measurement command by the datalogger (it can happen more than twice) cause the sensor to queue up the requests and then all sort of shenanigans start happening. Are you getting intermittent NANs from your sensor?
It appears that the retransmission is causing the replies to come in the wrong order. In an averaged measurement this isn't too big of a deal because it only happens once in about an hour... But with my totalized Rain measurement, this makes the rain measurement completely unreliable.
Your options may be limited. I would like to have confirmation from a CS rep that what we are seeing is the datalogger retransmitting the measurement command if the SDI12 sensor is not honoring the 15ms response time as per spec.
If you are on site, you could try this and may be able to catch when the response order gets mixed up by logging it.
Another option could be to slow down/break up the polling of the sensor with a slow sequence/delay/subsequent scans etc.
If an SDI-12 sensor does not respond within the maximum response time specified in the official SDI-12 specification, the CR1000 will retry the command automatically.
Per the SDI-12 spec, the datalogger will issue a sequence of 3 tries, with the sequence being repeated 3 times.
When issuing retries, if no response is received from a sensor, the recorder must wait for at least 16.67 milliseconds after the last stop bit of the command, but no longer than 87 milliseconds, and then issue a retry (without a break). (This period of 87 milliseconds includes the 16.67 milliseconds spent waiting for a response from the sensor.) If a correct response is not received after re-transmitting the command at least two more times, with at least one of those retries more than 100 milliseconds after the end of the break, the entire sequence (including the break and the retries) should be repeated at least two more times.
The logger will send break, command, command, command, break, command, command, command, break, command, command, command to a non-responsive (or non-present) sensor.