Hello, I have problem with storing data at an interval of 100 mSec (10Hz).Data stores at an uneven intervals of 100mSec, skipping many samples in between,and sometimes NAN appears randomly. I tried delay option ranging from 1 ms to 20 ms [sensors I guess has 5ms delay in response?]but to no use. sensor is set to 20Hz and I am sampling at 10HZ. Interesting part is when sensor is configured in continuous mode, i.e. as soon as power is applied to it, start out putting data, it stores at 100 ms interval, no problem, but when I configured it for character triggering mode and scan it at 100ms, I don't get it at 100ms intervals. I also tried "SerialInRecord (Com1,data,&H00,0,&H0D,NBytesReturned,01)" but some how I am not getting any output from sensors in this case.Any suggestion is well appreciated. Thanks
'Datalogger CR3000
PipeLineMode
Dim data As String *100
Public var(4)As Float
Alias var(1) = U
Alias var(2) = V
Alias var(3) = W
Alias var(4) = T
Public logger_temp, batt_volt
Public NBytesReturned
Dim scommand As String
Units U = ms-1
Units V = ms-1
Units W = ms-1
Units T = degC
'
DataTable (Table_data,1,-1)
DataInterval (0,100,mSec,0)
CardOut(1,-1)
Sample(4,var (1),FP2)
EndTable
'Main Program
BeginProg
SerialOpen(Com1,19200,10,0,500) 'for 20Hz
scan(100,mSec,3,0)
SerialFlush(Com1)
scommand = CHR(&H2A) ' ASCII (*) = 42,hex 2A
SerialOutBlock (Com1,scommand,1)
Delay(1,5,mSec)
SerialIn(data,Com1,100,13,500)
SplitStr(var(1),data,"",4,0)
CallTable(Table_data)
NextScan
EndProg
You do not say which sonic this is, but your problems could be due to two problems:
1) the sensor is not responsing as quickly as it needs to - many sonics will not respond in 5 msec if they take a measurement in response to the poll command, although some will return the last measurement they made. This is unlikely to be the root of your problem but you need to know how long the sensor takes to output data and when that data relates to in time if you intend to add other sensors to the program and synchronise them.
2) when you run in pipeline mode the serialoutblock and serialinrecord run in a higher priority digital task mode specifically to allow tight synchronisation with other measurements. Other serial instructions run as processing tasks so will fall out of sync with serialoutblock - and in your case the serialflush command will cause a problem as it may happen after the serialoutblock.
To make the system work you have two options both using serialinrecord. The first below, sends out the poll command then waits using a delay for the digital tasks calls the serialinrecord to get any data transmitted. It uses trick of using the linefeed and carriage return characters from one transmission to delimit the start and end of a transmission. There may be a proper start character that may be more suitable.
The problem with that technique is you are forcing a delay in the program and you may not know how long the sensor takes to respond and send back the data.
The two lines alternate lines in the program request the next set of data after processing the data sent during the previous scan. This means the sensor has a complete scan interval to send the data, but of course the data stored relates to the previous scan so you need to resync the data to any other measurements using slightly more advanced programming techniques.
'Datalogger CR3000
PipeLineMode
Dim data As String *100
Public var(4)As Float
Alias var(1) = U
Alias var(2) = V
Alias var(3) = W
Alias var(4) = T
Public logger_temp, batt_volt
Public NBytesReturned
Dim scommand As String
Units U = ms-1
Units V = ms-1
Units W = ms-1
Units T = degC
'
DataTable (Table_data,1,-1)
DataInterval (0,100,mSec,0)
CardOut(1,-1)
Sample(4,var (1),FP2)
EndTable
'Main Program
BeginProg
SerialOpen(Com1,19200,10,0,500) 'for 20Hz
scommand = CHR(&H2A) ' ASCII (*) = 42,hex 2A
Scan(100,mSec,3,0)
'--
SerialOutBlock (Com1,scommand,1)
Delay(2,10,msec)
SerialInRecord (Com1,data,&H0A,0,&H0D,NBytesReturned,01)
'--
'OR
'--
SerialInRecord (Com1,data,&H0A,0,&H0D,NBytesReturned,01)
SerialOutBlock (Com1,scommand,1)
'--
SplitStr(var(1),data,"",4,0)
CallTable(Table_data)
NextScan
EndProg
Andrew thanks for suggestions and sorry for missing out sensor. It is ATI's sonic k type probe. I checked out with ATI on sensor's response time and it turns out to be about 150ms.Time calculation is like this: on issuing a first command sensor samples for 100ms, at the end of its sampling, sonic takes second command for next sampling. While sampling for second command it is also processing data from first one and about 50 ms into the second command it will send out result in response to the first command, and cycle repeats. Approximately 150ms later data are available. Based on this I put delay of 150ms and implemented your suggestion in the code, it works but data are being stored at 5Hz instead of 10Hz, skipping every alternate measurements. I then removed delay and ran the code again without delay, now data were seen at 100ms intervals. I am, however, not sure if this is a correct way to do. Subsequently I added two more (licor and 3-axis accelerometer) sensors in the same loop. I used "serialInblock" and "serialflush" to read accelerometer. A delay of 15ms is provided between “serialoutblock” and “serialInblock”. While sonic and licor data are stored at 100ms, accelerometer does not. Many measurements are being missed out in the accelerometer records. Any suggestion to overcome this problem is appreciated. Thanks
* Last updated by: vk on 5/5/2012 @ 2:40 AM *
It sounds like the ATI works in not too disimmilar a way to many other sonics, where the data returned relates to a previous poll command. I am surprised it takes 50 ms to return the value from a poll command though, but nonetheless you should be able to still scan at 10 Hz, using the second example I gave and resynch the data afterwards if you know it has a fixed delay in time.
(Most Licor sensors have longer delays than this so you need to understand how to sync the data back together if you are doing EC measurements.)
With regards to the accelerometer it is hard to tell what is going on without knowing the time response of that sensor, but I would reiterate the warning that serialoutblock has a special priority when running in pileline mode. It will run at the beginning of the scan before any other serial i/o instructions (including serialflush). It is designed to be used with serialinrecord in pipeline mode which also has a high priority. This is described in the CRBasic help.