Hi,
I have a project with different types of sensors from Aanderaa (deep sea sensors).
All should work in the same way. Oxygen and conductivity sensors work fine, but from the temperature sensor I do not get data in. All sensors work in polling mode and send ascii data via RS232.
When I connect the temp sensor to a PC with hyperterminal I see a little difference in the protocol.
After the polling command "do_sample" it responds with # and CRLF first before the datastring comes out -> lines copied from hyperterminal:
do_sample
#
MEASUREMENT 4050 65 Temperature(DegC) 2.321629E+01 Rawdata Temperature 8884153
part of my code:
SerialOut (COM3,WakeUpString,"",0,100) 'wake up
Delay (0,15,mSec)
SerialOut (COM3,OutString,"",0,100)
Delay (0,5,mSec)
'take bytes between "M" and CR LF
SerialInRecord (COM3,TempInString,&H4D,0,&H0D0A,NBytesReturnedTemp,01) '&H4D is M &H0D0A is CR LF
SplitStr (TempInStringSplit(),TempInString,"",4,0) ' split and take numeric data only
I do not get any data in from the temp sensor.
I assume that is has something to do with the # that comes before the data string. Because this is an obvious difference between the temp sensor and the other sensors.
Any idea how to deal with it?
Thanks and regards, Uta
You only allow 5 mSec after the Serialout command before the SerialInrecord. At 9600 baud (I guess) this will not be long enough for the response to be transmitted even without any time it takes to do the measurement.
Also note that you have two "M" in your return string so the Nybytesreturned will not be as big as you might expect.
Also make sure the input buffer is set to be large enough to take the full string, including echoes, extra CRLF and etc.
The oxygen and the conductivity sensor do fine with just 5msec delay and even without any delay. So I think the temp sensor should do too. I can try a longer delay, though.
I know that my string starts at the second "M", that is not a problem.
The input buffer size seems not to be so critical to get data at all. If I connect the oxy sensor to the temp port I get a data string as long as the buffer allows.
But from the temp sensor I get nothing at all, only NAN and Nbytesreturned=0. This is what is strange to me.
What do you think about the # and CRLF that comes first before the actual data? I do not know exactly how I should deal with it. But I think even with that I should get something in the InString, not just NAN.
At 9600 baud it takes about 1 ms per character transmitted. This means you need to wait at least 60 ms or so before the whole response will come back from the sensor and be in the logger ready to process.
If you are only using 5 msec with the other sensors too and they have similar lengthy strings, it is most likely the serialinrecord is actually processing the data from the previous request in the previous scan which will explain why the data appears a scan too old.
The extra # and CRLF should make no difference to Serialinrecord.
Ok, I understand.
But where do I have to insert the delay, before or behind the serialIn? I thought that the next step does not begin before the whole serialIn is completed.
What about sequential and pipeline mode for this issue?
Thanks, Uta
What about the delay option?
I implemented an elapsed timer and I see that the time is not effected if I use delay option 0.
Do I need to use option 1 or 2?
The delay you need to change is the one after the last serialout, i.e.
SerialOut (COM3,OutString,"",0,100)
>>>>Delay (0,5,mSec)<<<<<<<<<<<
I would try at least 100 msec as a starter, maybe longer if the sensor takes time to respond.
Serialinblock does work in a different way in pipeline mode. To avoid confusion I would force your logger into sequentialmode, using the instruction of the same name.
In sequential mode I do not get data at all :-(
The temp sensor still does not work at all at the logger. I am in contact with the manufacturer, noe clue so far.
But I am not happy with my lack of understanding how the logger in detail works. (I am not totally new to programming and datalogging in general)
Do you maybe have a working example that deals with several RS232 sensors or know a customer who works with this kind of sensors?
Best regards
One other thing to try in sequential mode is to set the first parameter of the delay to 1 as serial instructions should then be dealt with as processing instructions, so your delays may not be working.
It may help you initially is to not use the Serialinrecord instruction, which is neat when it works, but as it will not return anything if the start and end characters are not there, can be difficult to debug. It also has this special mode of operation in pipeline mode that is designed for capturing high speed data but that can be difficult to synchronise with anything other than the SerialOutblock commands in pipeline mode.
However, as you are running in polled mode you know when the data is coming back, so you can use a simpler construct of flushing the serial port (Serialflush), sending out the command (serialout), then using SerialIn to read the data.
You could try replacing your code with this:
SerialOut (COM3,WakeUpString,"",0,100) 'wake up
Delay (1,15,mSec)
'Now flush the buffer to get rid of unwanted stuff
SerialFlush(COM3)
'Send the outstring and wait for the sensor to echo the "#" followed by CR LF.
'Wait for up to 1 sec for the initial ack.
SerialOut (COM3,OutString,"#"&CHR(13)&CHR(10),1,100)
'The next thing in the buffer should be the data.
'Read using SerialIn
'Terminate this when we see character 10 (LF) or hit 255 characters.
'Wait for up to 1 sec
SerialIn(TempInString,COM3,100,10,255)
SplitStr (TempInStringSplit(),TempInString,"",4,0) ' split and take numeric data only
With that type of construct you will at least see something in the TempInString.
I am afraid I do not know anyone else working with these specific sensors, may be some other Forum users do.
There is a plan to produce an online tutorial for dealing with serial sensors, but it is still in the works I believe.
* Last updated by: aps on 4/8/2010 @ 11:30 AM *
I experienced a similar communication problem with a serial sensor on the Com ports, but commuication worked on the RS232 port (search for thread "problems using C1/2 instead of rs232 port").
If you can communicate with the temp sensor via hyperterminal and the logger's RS232 port, but not C1-4, then it may be the sensor requires inputs levels as described in the reference thread.
SJP
Thanks for your hints.
I now have to work on hardware issues first. Get back to this stuff next week.
Uta
removed
* Last updated by: uta on 4/9/2010 @ 4:37 AM *
One additional tip which is a useful tool for anyone debugging these systems is to use the dataloggers special serial sniffing mode (the W command in the terminal mode).
To use this connect to the datalogger either with our standard software or hyperterminal (or similar). Open a terminal session and then press enter a few times until you get the CR1000> prompt back. Then quickly type W and press enter. You will then be asked which serial port to monitor. Select the port the sensor is connected to and answer the follow up questions (ASCII or Hex).
You will then see all the data sent out by the logger and received by it on that serial port along with a timestamp (logger time).
If you see no data at all coming from the sensor and the logger is evidently sending the right commands and you are sure of the wiring, then this could be an issue of the sensor needing true RS232 levels. However, as the other sensors from the same manufacturer seem to work, you would be unlucky if the one sensor does not, but having said that I know some Vaisala sensors will and some will not work on the control ports.
I got it running now! The sensor needs true RS232 levels.
In automatic mode you can use the loggers digital I/O as input if you connect the sensors Rx input to +VCC.
This post is under review.