I have a sensor that provides a string like below on putty. I want to sample x, y, z, and t only using CR1000.
T:00:00:01
M:x=-33 y=17 z=18 t=1579
The problem is destination string (Dest, see below code) keeps changing, meaning the string sometimes starts with t=1579 T:00:00:01 M:x=-33 y=17 z=18 and sometimes starts with y=17 z=18 T:00:00:01 M:x=-33. Accordingly, splitstrings (in the code) sequence keeps changing. There is no consistency at all. Moreover, NBytesReturned also keeps changing. Sometimes 55, sometimes 63, and sometimes 48. I tried different combinations of SerialInRecord, SerialInBlock, but nothing is working. In SerialInRecord, I tried fixing the start character (T= &H54) and end character CRLF(&H0D0A) with no luck. I am looking for a solution to deal with it. Any help is much appreciated.
part of the code
Public Dest As String * 150
Public NBytesReturned As String * 150
Public SplitStrings(11) As String * 150
DataTable (Test,1,1000)
Sample (1,Dest,String)
EndTable
BeginProg
SerialOpen (Com1,9600,3,0,1000)
Scan (1,Sec,0,0)
Do
SerialInRecord (Com1,Dest,&H0A,0,&H0D,NBytesReturned,01)
If Dest <> "NAN" Then
SplitStr (SplitStrings(1),Dest,"",4,0)
'--
CallTable Test
EndIf
Loop While NBytesReturned > 0
CallTable Test
NextScan
EndProg
It would be helpful if you can do a terminal capture in hexadecimal.
You can use the terminal emulator in the datalogger. When it asks if you want to see ASCII, indicate 'n' for no.
Here is a video that shows how to get into the terminal.
https://www.campbellsci.com/videos/sdi12-sensors-watch-or-sniffer-mode
Thanks for the response. Please see the strings captured on the terminal emulator.
09:44:28.98 R 54 3A 30 30 3A 31 36 3A 30 31 0D 0A 4D 3A 78 20 T:00:16:01..M:x
09:44:28.98 R 3D 20 20 20 2D 32 37 20 = -27
09:44:29.00 R 79 20 3D 20 20 20 20 20 39 20 7A 20 3D 20 20 20 y = 9 z =
09:44:29.00 R 2D 31 38 20 74 20 3D 20 -18 t =
09:44:29.03 R 20 33 30 32 31 0D 0A 3021..
09:44:29.08 R 54 3A 30 30 3A 31 36 3A 30 31 0D 0A 4D 3A 78 20 T:00:16:01..M:x
09:44:29.08 R 3D 20 20 20 2D 32 39 20 = -29
09:44:29.10 R 79 20 3D 20 20 20 20 20 39 20 7A 20 3D 20 20 20 y = 9 z =
09:44:29.10 R 20 2D 39 20 74 20 3D 20 -9 t =
09:44:29.13 R 20 33 30 30 39 0D 0A 3009..
09:44:29.18 R 54 3A 30 30 3A 31 36 3A 30 32 0D 0A 4D 3A 78 20 T:00:16:02..M:x
09:44:29.18 R 3D 20 20 20 2D 32 37 20 = -27
09:44:29.20 R 79 20 3D 20 20 20 20 31 31 20 7A 20 3D 20 20 20 y = 11 z =
09:44:29.20 R 2D 31 33 20 74 20 3D 20 -13 t =
09:44:29.23 R 20 33 30 31 36 0D 0A 3016..
09:44:29.28 R 54 3A 30 30 3A 31 36 3A 30 32 0D 0A 4D 3A 78 20 T:00:16:02..M:x
09:44:29.28 R 3D 20 20 20 2D 33 32 20 = -32
09:44:29.30 R 79 20 3D 20 20 20 20 2D 36 20 7A 20 3D 20 20 20 y = -6 z =
09:44:29.30 R 20 2D 32 20 74 20 3D 20 -2 t =
09:44:29.33 R 20 33 30 31 34 0D 0A 3014..
Please suggest next steps to debug.
Both types of data lines are terminated the same.
You want to look for a unique combination of start and end for each line. There is a small chance that the scan will run right when you only have the first line of the pair, and the second is incoming. Handling that case would add a lot of complexity to the program.
Give this a try:
'Read the first line. Note that the T won't be in Dest1. SerialInRecord (Com1,Dest1,&H54,0,&H0D,NBytesReturned1,01) 'T to first carriage return 'First line is no longer in the buffer SerialInRecord (Com1,Dest2,&H0A,0,&H0D,NBytesReturned2,01) 'Line feed to next carriage return 'Use data only if second destination is valid
I tried the above suggestion, but it did not work. Moreover, after clicking the start button on the connect screen, the message comes "Table Defs suspect."
I made some errors and trail and delimited the start word with M=&h4D inSerialInRecord. With this, I can see data and data are relatively stable; only once in a while, it fluctuates. But data logger developed some other problems. While compiling and uploading the code into the logger, the below message appears.
Warning: Voltage calibration failure! Possible input to analog channel beyond +/- 8V.
Out of memory.
OS Version: CR1000.Std.32.03
I am afraid if the data logger tends to fail or some other problem. In one of the forum posts, they suggested a grounding problem, so I checked the connection that appears to be okay. Therefore I don’t suspect a grounding issue. Please suggest.