Parsing variable length data measurement format for Newport THP/N

[DSandelman]

I am trying to parse the response from a Newport zED-THP/N sensor. The response comes back with ID SEQ TYPE TEMP C HUMD %.

ID = 1, SEQ is always changing, TYPE = 15, Temperature = nnn.n

I am trying to capture the Temp, and  this has presented a challenge. (The Humidity is easy, I am reading after the C - "C"5a)

The SEQ number starts as n and grows to nnnn.. so using 7x4a does not work because of the changing length of SEQ.

When I use "15"4a, because the Type is always 15, and when SEQ contains a 15 in the number, that also becomes a problem.

All that I have that is constant is that  there are spaces between each of the values and the temperature value I am looking for begins after the 3rd space.

Any help would be great

David Sandelman

[HeatherBaker]

Hi David,

What hardware are you using? We can assist configuring National Instruments; however, if you are not using NI hardware then it would probably be best to contact DASYLab. 

[CJ_Butler__DASYLab_Pro]

I would be inclined to add an extra channel for the sequence number, so that you have one more channel than you need.

You can use the space as a delimiter...

n nnnnn 15 nnn.nn C nn.nn %

Ch 0: a\x20

ch 1: a\x20

ch 2: a\x20

ch 3: a\x20

ch 4: 2x a\x25

Your data is on Channel 3 and 4

You can display the sequence number on channel 1 if you want to verify the data transmission.

[DSandelman]

This worked for the first time around, and then on the second read from the port, the values got out of sync and I ended up with 0s in most of the channels. Your solution got me the furthest, but still not correct. I am not clear on how repeating the a\x20 (ASCII then skip 20 characters) worked. I have provided a actual response from the control. One is an all sensor read, and one is a senor by channel number read. It does not matter which I use, as long as in the end I can parse the four sensors into 8 values of temp and humid.

Thanks

David

I can read one or all sensors with either of two commands.

an ERDG00A returns all the sensor with one command

0 84 15 18.5 C 64.5 % <CR><LF>
1 50 15 18.4 C 64.2 % <CR><LF>
2 214 15 18.5 C 64.7 % <CR><LF>
3 237 15 18.3 C 64.3 % <CR><LF>
<CR><LF>

an ERDB000 returns one sensor per address

0 84 15 18.5 C 64.5 % <CR><LF>
<CR><LF>

an ERDB001 returns, and so on

1 50 15 18.4 C 64.2 % <CR><LF>
<CR><LF>

[CJ_Butler__DASYLab_Pro]

Ok. I wasn't sure about the cr lf.

On the last channel, do a\r\n

that will force it to account for all of the characters on the line. It should skip over the space % space.

[DSandelman]

Thanks - CJ, that worked better, now I get one good read, then all zeros on all 5 channels, then a good read, then the data is shifted 2 postions down. (0 in the 1st and 2nd channels, channel # in 3rd postion, Seq# in 4th position, and Type in the 5th position). And then it continues to update in those postions.

I have

a\x20

a\x20

a\x20

a\x20

a\r\n

It is getting much closer. Thanks

David

[DSandelman]

CJ - Problem solved, almost...

I did not put the data request ERDB000 in each of the  5 channels. I only had it in the first channel "0", and \r in rest.

Once I changed the \r to ERDB000 in all 5 channels it worked.

So then I moved on to get the next set of values from ERDB001 by adding channels 5-9 and placing the data request as ERDB001 and putting a\x20,a\x20,a\x20,a\x20,a\r\n in 5-9. I wound up getting ERDB000's values in both channels 0-4 and 5-9.

My quess is should I be using the ERDG00A   which willl return all my sensors in one data request as follows:

0 84 15 18.5 C 64.5 % <CR><LF>
1 50 15 18.4 C 64.2 % <CR><LF>
2 214 15 18.5 C 64.7 % <CR><LF>
3 237 15 18.3 C 64.3 % <CR><LF>
<CR><LF>

Or should I read one sensor at a time, but how

Thanks

David

[CJ_Butler__DASYLab_Pro · Accepted solution]

Great... progress is good.

If you use the single command, ERDG00A tol return all my sensors in one data request:

The only data request channel that should be filled in is the channel 0. All other channels should be blank. Not \r, just blank. I should have mentioned that in the original post. Then set up the channels as before, ensuring that each humidity channel is a\r\n. The next channel group should be a\x20.

To explain, just the a tells DASYLab to find the variable length number, and it always needs a delimiter to terminate it. Many devices use a comma, but these use a space. The ASCII Hex for a space is 20, so we tell DASYLab to find the numbers in an ASCII string, and stop when it finds a space, using DASYLab's notation for hex, \x20.  \r is notation for the return character (<CR>, or hex 15), and \n is the notation for the line feed character (<LF> or hex 12).

0 84 15 18.5 C 64.5 % <CR><LF>
1 50 15 18.4 C 64.2 % <CR><LF>
2 214 15 18.5 C 64.7 % <CR><LF>
3 237 15 18.3 C 64.3 % <CR><LF>
<CR><LF>

I like the idea of a single data request command for all four channels -- less handshaking needed.By interpreting the device number, you'll be able to ensure that the parsing is working correctly.

CH 0: a\x20

CH 1: a\x20

CH 2: a\x20

CH 3: a\x20

CH 4: a\r\n

CH 5: a\x20

CH 6: a\x20

CH 7: a\x20

CH 8: a\x20

CH 9: a\r\n

CH 10: a\x20

CH 11: a\x20

CH 12: a\x20

CH 13: a\x20

CH 14: a\r\n

[DSandelman]

CJ

Thanks for you help. Your explanation was perfect and so was the solution.

Thanks

David