Sometimes the last character is missing when I query an SDI12 sensor when using the command with CRC (aMC! )

[ionel-dragomirescu]

Hello,

I am using the SDI-12 library, version 2.3.0. I am working on a SAMD21 processor board, similar in hardware to the SARA SFF variant from Sodaq. I am able to query SDI12 sensors and I have tried with several types of sensors: Teros21 (Meter), SI431 (Apogee), TRWS224 (MPS).

I noticed that when I want to query the data using the command with CRC, i.e. aMC!, sometimes the last character in the response is missing, i.e. the last character in the CRC. The first 2 characters in the CRC are correct, but the library fails to read the last character. If I retry, sometimes it succeeds in reading the entire message, sometimes not.

Has anyone else encountered this?

Interestingly, if I use the command without CRC, i.e. aM!, it reads the entire message from the first query and there is no need to retry. What is different in the library when using aMC! instead of aM! and can it lead to "losing" the last character in the response?

[jackdeath5]

I have encountered this using the library on ESP32 processors. In addition, I have found that sometimes the last character, or even the middle character would sometimes be read improperly. Here's a few examples of bad readings I've come across for one of the sensors I was working with (note: the ESP32 consistently read these across repeated calls for aD0! to get the same string back):

Response with CRC Read	Expected CRC
0+7.84+0.00+50+0+0+0+0A/M	A_M
0+7.45+0.00+44+22+0+0+0N/C	N_C
0+7.27+0.25+54+9+0+0+0KN>	KN~
0+7.07+0.00+54+18+0+0+0HY=	HY}
0+7.27+0.10+52+3+0+0+0Mp_	Mpv
0+5.97+0.00+38+14+0+0+0Dz*	DzS
0+5.97-0.00+37+12+0+0+0M|V	M|f
0+3.87+0.78+42+0+0+0+0Ey/	Eyn

I've only experienced this with one out of 3 of my sensor so far though. I believe that sensor it happens with might be irrelevant, as I was able to send these strings from another ESP32 to a different ESP32, which read everything just fine. Could be whatever is sending the serial data in the sensor, but that info is beyond me. This leads me to believe that this is more of a timing tolerance issue with the microcontroller running the code than a fault of the library itself, and might require more MCU-specific implementations/fixes to get it more consistent. Everything I tried with the ESP32 with specific implementations didn't work unfortunately.

What is different in the library when using aMC! instead of aM! and can it lead to "losing" the last character in the response?

Having looked through the library extensively, I can confirm that that it's not doing anything differently for the aM! and aMC!. I think the bits for 0-9, +, and - and . just happen to work out better than characters and edge cases. If you look at the bits for the incorrect characters from the table above, you can see that many of them are 1 bit off what they should be.

I DID find that delaying and waiting for the entire response to get received before parsing it instead of parsing characters in the response as they were received was a bit more consistent. Still wasn't perfect, but was slightly better nonetheless. I also just ended up working around the issue slight, improving CRC verification by checking for a combination of consistent responses and close enough CRC values. For example, if it kept reading a string with an invalid CRC across multiple aD0! responses, it would check for both, 1) the responses are the same across multiple calls, and 2) two of the characters in the CRC codes match.

As of right now, I've currently started experimenting with a hardware UART on the ESP32, which I found to be able to run at 1200 baud just fine so far, and I believe might give will me better consistency over the library. The library itself is fine in general, but this is a MCU-specific fix that not everyone using the library will have.