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.

Serial sensor (NBytesReturned keeps changing)


vk Nov 18, 2020 02:16 PM

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


JDavis Nov 18, 2020 10:41 PM

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


vk Nov 19, 2020 04:34 AM

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.


JDavis Nov 19, 2020 06:10 PM

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

 


vk Nov 20, 2020 01:55 PM

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.        

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