Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

How to parse 10 byte encoded data from Omegatte HH306 Thermometer/Datalogger?

Solved!
Go to solution

I am trying to write a simple code for an OMEGAETTE HH306 Thermometer/Datalogger from omega.com.

 

Here is the problem. I communicate with the device via RS-232, using Labview 8.5.1 and windows xp. I query it for "all encoded data", which is basically the only option. It returns 10 bytes of encoded data, the manual describes the meaning of each byte, and I understand all of it. The problem is that I cannot seem to parse the information for use within labview, for example: I want to extract the temperature and simply display it.

 

upon query, I get: 10bytes (read as a string from the serial port read buffer):     HEX display: 02 00 A8 B6 48 FF EF B6 49 03      This is perfect, and what I expect.     Codes Display: \02\00\A8\B6H\FF\EF\B6I\03               The Normal Display is a series of special characters, which I don't understand, especially since I don't think they represent the ascii characters that should correspond to the hex numbers returned!   For the life of me, I cannot figure out how to extract the information (which is the 6 48 in the hex display) from what is returned. All the string manipulation functions seem to only work on what is given in the Normal Display. (The 4th and 5th byte of the data are the BCD codes for the temperature: for example the temperature was 64.8 degrees farenheight when I took this reading).

 

Can anyone help me to parse the data returned by this device?

0 Kudos
Message 1 of 9
(4,590 Views)
Solution
Accepted by GDUB

Ok... I think I figured it out. I found this: http://digital.ni.com/public.nsf/websearch/77C8F61D36F5A23086256634005ACB38?OpenDocument.

 

I guess the garbled normal display is the ascii characters corresponding to each hex number. I am just not used to seeing ascii characters beyond the decimal number 127, or hex 7F.

So basically, to parse the 10 bytes of data:

 

1) break up the string read from the serial port into the 10 individual ascii characters (using  String subset vi)

2) wire each output string into the left input of 10 distinct Type Cast vi's.

3) wire a U8 constant into each "type" terminal of the Type Cast vi's.

4) wire the string output of each Type Cast vi into the input of a  number to hexadecimal string vi.

5) concatenate or use as you would like the hex numbers (now in string format) that result.

 

Cheers.

0 Kudos
Message 2 of 9
(4,585 Views)

Hi

 

just a tip.

instead of using 10 times stringsubset, you also can use string to array of bytes

and do your calculations in bytes.

greetings from the Netherlands
Message 3 of 9
(4,575 Views)

This also works brilliantly!

 

Thanks.

 

Also, I found the number to boolean array function, which allows me to analyze each bit of data within each byte.

0 Kudos
Message 4 of 9
(4,569 Views)

The solution shown in this posting has a URL reference to a KB article, but the URL in that solution has an extra (unicode?) character in it that does not allow it to work even if you cut and paste it into your web browser.  So the name of the article it references is "How Can I Convert ASCII Characters to ASCII Codes and Vice-Versa?" and it is knowledge base document ID: 1B0AGRVJ.  I will paste the proper URLhere again but it might not work, let's see if it does:

http://digital.ni.com/public.nsf/websearch/77C8F61D36F5A23086256634005ACB38?OpenDocument

0 Kudos
Message 5 of 9
(3,728 Views)
Your link works fine for me.
0 Kudos
Message 6 of 9
(3,716 Views)

Hello 

 

This link should direct you to the same Knowledge Base article 

 

http://digital.ni.com/public.nsf/allkb/B9142E44E5363BAD86257441005A7454?OpenDocument

Chris S.
0 Kudos
Message 7 of 9
(3,702 Views)

Hi Chris, This is strange, the URL you just provided to that article show that it is the same document ID, but it is newer by almost a year and a half.  Also, there are two extra attachments on the newer one (string2ascii.zip and String to Hex String.vi), but clicking on either of them yields an exception "item not found" from your web server.  The good news is that the original attachment that is shown on both KB articles (string2ascii.vi) is downloadable from either article, and they open and run fine in LV2012SP1.

0 Kudos
Message 8 of 9
(3,696 Views)

The plot thickens: a brute force google search for "String to Hex String.vi" sends you to the following URL (same document ID, but presumably is the Japanese version of the KB article.  However, this one does a walk-through of how the LV block diagram is doing the conversion.  Google-Translating it to English via the Chrome web browser seems to do a decent job of understanding the walk-through.

http://digital.ni.com/public.nsf/allkb/862567530005F0A1862568D50067FCED

 

0 Kudos
Message 9 of 9
(3,693 Views)