Hi
I am stuck with the following problem. I want to read the NMEA-String of a Aquadopp Profiler looks like
$PNORI,2,AQP5059,3,20,1.01,1.00,0*1D
$PNORS,061417,154044,00,21,14.8,1528.4,164.9,1.7,1.5,0.267,22.60,0,0*5E
$PNORC,061417,154044,1 ,0.364,-0.392,0.158 ,0.535,137.1,C ,208,204,207,,,*23
$PNORC,061417,154044,2,1.834,1.534,0.019,2.391,50.1,C,202,170,182,,,*33
$PNORC,061417,154044,3,-0.795,0.367,1.048,0.876,294.8,C,161,134,150,,,*24
$PNORC,061417,154044,4,1.677,-0.709,0.508,1.821,112.9,C,120,102,122,,,*29
$PNORC,061417,154044,5,2.191,0.564,-0.239,2.262,75.6,C,105,64,105,,,*2A
$PNORC,061417,154044,6,0.937,-0.570,-0.552,1.097,121.3,C,75,51,75,,,*35
$PNORC,061417,154044,7,1.836,-0.760,-0.341,1.987,112.5,C,57,44,54,,,*3B
$PNORC,061417,154044,8,0.500,0.047,-0.669,0.502,84.6,C,46,44,49,,,*2C
$PNORC,061417,154044,9,0.924,-2.078,-0.055,2.274,156.0,C,40,42,49,,,*31
$PNORC,061417,154044,10,0.957,-0.885,-0.095,1.303,132.8,C,39,45,50,,,*00
$PNORC,061417,154044,11,-0.382,-2.158,0.981,2.191,190.0,C,39,44,48,,,*06
$PNORC,061417,154044,12,0.025,-0.631,0.744,0.631,177.7,C,40,43,50,,,*2A
$PNORC,061417,154044,13,1.042,-1.963,1.061,2.222,152.0,C,40,43,50,,,*27
$PNORC,061417,154044,14,1.540,-0.700,1.112,1.692,114.4,C,39,44,49,,,*23
$PNORC,061417,154044,15,2.400,-1.313,0.881,2.735,118.7,C,41,44,49,,,*2E
$PNORC,061417,154044,16,1.229,0.364,1.068,1.282,73.5,C,39,43,49,,,*3D
$PNORC,061417,154044,17,-0.409,1.151,0.270,1.221,340.4,C,39,46,50,,,*2D
$PNORC,061417,154044,18,-1.915,-0.635,0.360,2.017,251.7,C,39,43,48,,,*00
$PNORC,061417,154044,19,-1.443,-0.828,0.754,1.664,240.2,C,40,43,51,,,*0C
$PNORC,061417,154044,20,1.636,-1.705,1.087,2.363,136.2,C,39,43,49,,,*26
I found the entry
https://www.campbellsci.com/forum?forum=1&l=thread&tid=3377
but I did not get it right.
I tried it by reding the comlete string
SerialInChk_val = SerialInChk (Com3)
SerialIn (rawString,Com3,100,0,SerialInChk_val) ' read in string
SplitStr (SplitResult(),rawString,"$",ProfilerCells+2,4)
For I=1 To ProfilerCells+2
SplitStr (Chksum(I), SplitResult(I), "*", 1, 4)
' reading the values for "ChkSum" and write in an array
SplitStr (LineId_read(I), SplitResult(I), "," , 1, 5)
' reading the values for "Line_ID" (PNOR*) and write in an array
SplitStr (LineStr(I), SplitResult(I), "*", 1, 5)
' read the lines before "*" and write them in an array
Next I
SplitStr (Line1Val(1), LineStr(1), ",", 8, 5)
SplitStr (Line2Val(1), LineStr(2), ",", 14, 5)
The lines with the "PNORC" ID I could not read in within a for loop or in another proper way.
Because I want to specify the number of Profiler-cells (number of lines) only in the header, I come up with the idea to read the lines within a loop that runs over the number of cells.
Maybe somene has a good solution
cheers Heiko
Do those lines end with typical <CR><LF>? NMEA sentences are what SerialInRecord() excels. Here is an exceprt of a program for NMEA-based weather station.
The sync bytes are in hexadecimal so capital "W" is 57 and "G" is 47 (asciitable.com).
Const WX_COM = Com1 'C1/C2 Const WX_BAUD = 4800 Const WX_FMT = 3 '8/n/1, RS232 Const WX_BUFF = 250 Const DOLLAR_W = &h2457 ' "$W" Const DOLLAR_G = &h2447 ' "$G" Const CRLF = &h0D0A ' 'record lengths from Table 1, PB100 WeatherStation Technical Manual r1.007 Public wimda As String * 81+1 Public gprmc As String * 74+1 Public wx_bytes Public gps_bytes Public metvals(10) ' "IMDA," consumed 'Alias metvals(1) = barometric pressure, inches of mercury ' ",I," consumed Alias metvals(2) = P_10m 'barometric pressure, bars ' ",B," consumed Alias metvals(3) = T_10m 'air temperature, degrees C ' ",C,,," consumed (no water temperature or units) Alias metvals(4) = RH_10m 'relative humidity, % ' ",," consumed(no absolute humidity) Alias metvals(5) = dewpoint_10m 'dewpoint, degrees C ' ",C," consumed Alias metvals(6) = WD_10m 'degrees E of TN ' ",T," consumed Alias metvals(7) = WD_mag_10m 'degrees E of MN ' ",M," consumed 'Alias metvals(8) = wind speed, knots ' ",N," consumed Alias metvals(9) = WS_10m 'm/s ' "M*" consumed 'Alias metvals(10) = checksum Units P_10m = mbar Units T_10m = degC Units RH_10m = % Units dewpoint_10m = degC Units WD_10m = degTN Units WD_mag_10m = degMN Units WS_10m = m/s
... BeginProg SerialOpen(WX_COM,WX_BAUD,WX_FMT,0,WX_BUFF) Move(metvals(1),10,NAN,1) Scan(1,Sec,0,0) SerialInRecord(WX_COM,wimda,DOLLAR_W,0,CRLF,wx_bytes,110) SerialInRecord(WX_COM,gprmc,DOLLAR_G,0,CRLF,gps_bytes,110) If (Len(wimda)) Then SplitStr(metvals(1),wimda,"",10,0) P_10m *= 1000 'bar --> mbar Else Move(metvals(1),10,NAN,1) EndIf ...........
Yes it does contain the <CR><LF>. I will test your recommendations. As I assume, the Met-Sensor send a 2-line output with a clear identifier. I have 2 lines with a unique identifier. Starting from the 3rd line to the end of the incomming string the identifier is alway PNORC. Maybe this could be a problem?
Thanks for the quick response
Just curious.. did you figure this out? You're right about having to use a different record start identifier since all lines begin with "$P" -- did you go with "RC" instead? or maybe "C,"?
Not yet.
But thanks for asking. I will start agin the work with the profile at the beginning of august.
Dear Heiko,
did you find any solution about? I am trying too with an AWAC NORTEK sensor (NMEA output) and i have the same problem. If you have solve the problem can you please post the correct cr1 code?
Today i realize that:
A. Hyper Terminal input data from AWAC NMEA format
$PNORI,3,WAV6034,4,5,0.41,1.00,0*21
$PNORS,100417,095047,81,31,14.5,1429.9,90.0,0.0,0.0,0.000,-6.97,0,0*7E
$PNORC,100417,095047,1,0.45,-0.20,-0.68,-0.40,0.49,114.6,C,7,7,7,7,,,,*25
$PNORC,100417,095047,2,0.38,0.01,-0.85,-0.73,0.38,88.9,C,7,7,7,7,,,,*3C
$PNORC,100417,095047,3,0.37,0.08,-0.48,-0.61,0.38,78.5,C,7,7,7,7,,,,*3A
$PNORC,100417,095047,4,-0.16,0.51,-0.72,0.13,0.54,342.6,C,7,7,7,7,,,,*0D
$PNORC,100417,095047,5,0.11,-0.30,-0.70,-0.34,0.32,160.1,C,7,7,7,7,,,,*23
B. CR1000 input data from AWAC NMEA format (connected to CR1000 RS232 port)
$PNORI,3,WAV6034,4,5,0.41,1.00,0*21
$PNORS,100417,095047,81,31,14.5,1429.9,90.0,0.0,0.0,0.000,-6.97,0,0*7E
$PNORC,100417,095047,1,0.45,-0.20,-0.68,-0.40,0.49,114.6,C,7,7,7,7,,,,*25
$PNORC,100417,095047,2,0.38,0.01,-0.85,-0.73,0.38,88.9,C,7,7,7,7,,,,*3C
$PNORC,100417,095047,3,0.37,0.08,-0.48,-0.61,0.38,78.5,C,7,7,7,7,,,,*3A
$PNORC,100417,095047,4,-0.16,0.51,-0.72,0.13,0.54,342.6,C,7,7,7,7,,,,*0D
$PNORC,100417,095047,5,0.11,-0.30,-0.70,-0.34,0.32,160.1,C,7,7,7,7,,,,*23
B. CR1000 input data from AWAC NMEA format (connected to CR1000 COM1 port)
.7,C,7,7,7,7,,,,*31
$PNORC,100217,141447,2,-0.48,-0.28,-0.78,-0.09,0.56,239.3,C,7,7,7,7,,,,*0F
$PNORC,100217,141447,3,-0.01,-0.53,-0.72,-0.48,0.53,181.2,C,7,7,7,7,,,,*04
$PNORC,100217,141447,4,-0.05,-0.05,-0.96,-0.78,0.07,226.8,C,7,7,7,7,,,,*08
$PNORC,100217,141447,5,-0.16,-0.27,-0.65,-0.59,0.31,209.7,C,7,7,7,7,,,,*03
As you can see, CR1000 COM Ports are not sufficient for AWAC NMEA communication.
I do not know why this is happening, but ... is happening
The control ports require a higher voltage to register a logic 0 state than the RS232 port. If your cable is long, the RS232 port is more likely to work properly.
The cable i use is almost 1m, so i do not think this is a "long cable" problem.
-------------------------------------------
Campbell explanation
------------------------------------------
1) When a device output serial data the baud rate is rarely exact as it is based upon the clock speed of the microprocessor (or UART) divided by a round number.
2) This means that some baud rate are often a fraction of a percent out even if set to the correct setting.
3) Some conventional UARTs are quite tolerant of baud rate errors, because they analyse each character separately and start timing of the bits (and their state) on the start bit of each character.
4) The control ports use an “ASIC” chip, which synchronises with the first start bit of each transmission, not each character. Therefore for a 100 byte (1000 bit) transmission, you will get errors in the last bytes if the baud rate is out by more than 0.1% (worst case).
A more lengthy explanation is this:
“The ASIC samples in the middle and samples two-bit clocks apart (6, 8 and 10). We do not re-sync to the start bit of each character. So with back to back bytes over time and with long transmissions you will have errors. In comparison the main H8S MPU UART (RS232 port) syncs up with the start bit of each byte so can tolerate bigger errors. "
Something else that is different between com ports and the RS232 port –
“There is of course one other difference between the control ports and the RS232 port and this is the control port needs slightly higher voltages from the sensor to work (about 3.5V for positive signals) whilst the RS232 port has thresholds around 1.4 V, so if the sensor has low RS232 levels or the ground voltage is not at 0V relative to the logger then that can lead to bad reception.”
-----------------------------------------------------------------------------------------------------------------------------
So as a conclusion, we can not use ComPorts for AWAC (NMEA setup) sensor communication.
Instead we can use the D/L RS232 port.
Just to explain the two comments above, items (1)...(4) and the "lengthy explanation" cover one possible problem which is that the sensor may not be outputting data at the exact baud rate and the control port serial ports on the CR800, CR1000 and CR3000 are not so tolerant of those errors, compared to some other serial inputs including the datalogger's own RS232 port. We have seen that on a few occasions but it is not common and is usually only a problem when long bursts of data are received where the corruptions happen towards the end of the transmission.
The second issue relates to the differences in input voltage levels between the control ports and traditional RS232 ports. The control ports on these loggers require about +3.5 V to detect a high level, which is well below the output level of most RS232 drivers in sensors (usually in the range of 5-12V) but some sensor designs output lower votlages and some even use low power RS562 drivers which only output 3.5 V, which will not work well with the control ports.
The most common incompatibilty is with sensors with "intelligent" or smart serial ports that detect whether something is connected to the serial port and only turn on their output drivers if a voltage of + or - ~5V or above is present on their received data or handshake lines. The datalogger control ports idle at 0V so the serial port of the sensor does not detect this as a valid serial connection so it either never switches on its serial port or only switches it on when it starts to transmit (which can lead to the loss of data at the start of the message). Sometimes this function can be turned off in the sensro or if the detection works on a handshaking line you can tie that line high (to 5V on the logger) otherwise those sensors cannot work with the control ports.
Another variant of the latter problem comes with serial sensors or serial convertors (e.g. RS232-RS485) which try to "steal" power from the RS232 lines of the logger, as the main power source for the sensor's RS232 drivers or the convertor. Again as the control port idles at zero volts these will not work.
In respect of other loggers, the CR6 and CR1000X have two pairs of control ports than do have full RS232 driver capability and do not use an ASIC serial port, so they would not have any of the issues above. There is a small cost to pay in power use though when this feature is used. Most of the other add-on serial interfaces for the logger, e.g. the SDM-SIO1, SC32B, SC105 have proper RS232 driver chips in them.
And just to throw in a couple of other programmng tips when dealing with data like this:
1) if you use SerialInRecord to pull different strings out of data coming in the same serial port, as is common with NMEA, make sure you are running firmware later than OS24 when this feature was added.
2) if using Serialinrecord with asynchronous sensors do not use Serialflush in the program because it generally always ends up with loss of data. This is because the Serialinrecord processes previosuly captured data, so even if it has just returned new data that data could have been received some time before and the sensor might have already started transmitting new data to the logger so flushing the buffer can result in loss or part or all of the transmission.
Thanks a lot for the explanation
I have just tested to connect AWAC to CS I/O port (as COMME), using SC32A, SC929 & SC105, and
CS I/O port received all the data from the sensor.
So i will connect AWAC sensor to SC I/O port & GPRS modem to RS232 port , and the problem solved.
Thanks a lot for your help