How to find, separate, and convert hex strings streaming through com port?

[superomario]

Hello, 

I have an xbee wireless network set up with 3 sensors. 1 (23bytes) outputs at 20hz, the other 2 (46bytes each) at 1hz. The data is coming into the computer correctly and I can see the stream on my basic serial read VI (attached). on my XCTU software (terminal program that comes with the wireless nodes) the console displays the packets being received: 

08-22-2016 13:36:04.196,6126,RECV,7E00178100002B00205A203030303230207A2030303031350D0A00
08-22-2016 13:36:04.252,6127,RECV,7E00178100002B00205A203030303230207A2030303031350D0A00
08-22-2016 13:36:04.296,6128,RECV,7E00178100002B00205A203030303230207A2030303032300D0A04
08-22-2016 13:36:04.346,6129,RECV,7E00178100002C00205A203030303230207A2030303032320D0A01
08-22-2016 13:36:04.346,6130,RECV,7E00178100002F00205A203030303230207A2030303032320D0AFE
08-22-2016 13:36:04.436,6131,RECV,7E002E81000032004F20303230362E332054202B32352E38205020313031382025203032302E3237206520303030300D0AC4
08-22-2016 13:36:04.436,6132,RECV,7E00178100003200205A203030303230207A2030303032300D0AFD
08-22-2016 13:36:04.486,6133,RECV,7E00178100003600205A203030303230207A2030303031350D0AF5
08-22-2016 13:36:04.536,6134,RECV,7E002E81000032004F20303230362E362054202B32362E38205020313031392025203032302E3237206520303030300D0ABF
08-22-2016 13:36:04.596,6135,RECV,7E00178100003800205A203030303139207A2030303030380D0AE9
08-22-2016 13:36:04.596,6136,RECV,7E00178100003300205A203030303138207A2030303030380D0AEF
08-22-2016 13:36:04.652,6137,RECV,7E00178100003100205A203030303139207A2030303032320D0AF4
08-22-2016 13:36:04.652,6138,RECV,7E00178100002F00205A203030303139207A2030303032340D0AF4
08-22-2016 13:36:04.738,6139,RECV,7E00178100002F00205A203030303139207A2030303032310D0AF7
08-22-2016 13:36:04.786,6140,RECV,7E00178100003000205A203030303139207A2030303032300D0AF7
08-22-2016 13:36:04.836,6141,RECV,7E00178100003200205A203030303139207A2030303032320D0AF3
08-22-2016 13:36:04.886,6142,RECV,7E00178100003200205A203030303139207A2030303031380D0AEE
08-22-2016 13:36:04.946,6143,RECV,7E00178100003200205A203030303139207A2030303031330D0AF3
08-22-2016 13:36:04.996,6144,RECV,7E00178100002E00205A203030303138207A2030303031310D0AFA
08-22-2016 13:36:05.046,6145,RECV,7E00178100002C00205A203030303138207A2030303031360D0AF7
08-22-2016 13:36:05.096,6146,RECV,7E00178100002C00205A203030303139207A2030303032350D0AF6
08-22-2016 13:36:05.146,6147,RECV,7E00178100002E00205A203030303138207A2030303031340D0AF7
08-22-2016 13:36:05.146,6148,RECV,7E00178100002F00205A203030303138207A2030303031330D0AF7
08-22-2016 13:36:05.236,6149,RECV,7E00178100003000205A203030303138207A2030303032300D0AF8
08-22-2016 13:36:05.286,6150,RECV,7E00178100003300205A203030303138207A2030303032320D0AF3
08-22-2016 13:36:05.346,6151,RECV,7E00178100003700205A203030303138207A2030303031360D0AEC
08-22-2016 13:36:05.396,6152,RECV,7E00178100003900205A203030303138207A2030303031320D0AEE
08-22-2016 13:36:05.446,6153,RECV,7E002E81000032004F20303230362E332054202B32352E38205020313031382025203032302E3237206520303030300D0AC4
08-22-2016 13:36:05.446,6154,RECV,7E00178100002A00205A203030303138207A2030303031360D0AF9
08-22-2016 13:36:05.506,6155,RECV,7E00178100002600205A203030303138207A2030303032320D0A00
08-22-2016 13:36:05.506,6156,RECV,7E00178100002300205A203030303138207A2030303031380D0AFE
08-22-2016 13:36:05.566,6157,RECV,7E002E8100002E004F20303230362E362054202B32362E37205020313031392025203032302E3237206520303030300D0AC4

Since this is an endless stream of hex strings, how can I isolate each one so that I can then convert them to their sensor numeric values for plotting, display, etc? 

[Sam_Sharp]

It looks like you need to read the documentation for the device you're communicating with - it will have some sort of protocol definition which defines how the packets are structured. From the looks of it, the packets have a header (e.g. 7E) and the length is then variable (perhaps one of the bytes defines the packet length??). In this case - you can keep reading until you get the header, then read the length of the packet and then the rest of the packet.

The other method I've used is to read everything into a string buffer, and then split up the packets afterwards.

[superomario]

How do I set labview up to locate the header, then if a certain header appears, it's that sensor over a different one? Then once it has identified which sensor it is, break off into an IF tree basically and IF header A appears>23bytes following is hex string for A> convert to number>plot else if header B appears>46bytes following is hex string for B> etc. 

[Sam_Sharp]

As I mentioned above - you can either create a string buffer and then search the string for the start header, or you can read a single byte at a time until you get your start header (and then do subsequent reads until you read the end of your packet).

[superomario]

I found out how to set a node transmitter name so now my packets all have an identifier in them: 

08-23-2016 08:23:45.220,298,RECV,7E00178103332200205A203030303331207A2030303033350D0ACF
08-23-2016 08:23:45.290,299,RECV,7E00178103332200205A203030303331207A2030303032390D0ACC
08-23-2016 08:23:45.350,300,RECV,7E002E81044423004F20303230372E342054202B32352E36205020313032302025203032302E3334206520303030300D0A94
08-23-2016 08:23:45.400,301,RECV,7E00178103332300205A20303030333120

The identifiers are 333, 444, 555. So how do I create a string buffer to read until it finds the 333, for example, then all data following that until the next  identifier is the string I want and send that to the proper chart depending on what the identifier was? 

The overall packet information is in the picture below, which I think helps since the structure is always the same, so it goes identifier, RSSI, Options, Data I care about, Checksum. Is string subset what I am looking to use here? Since the RSSI will change in value but its length in the packet should always be the same, I can use the offset/length in that block to find the data? 

(also is there a way to break up this HEX stream like XCTU does but in labview? I dont' need the RSSI or other info about the packet now, but could in the future who knows) 

[crossrulz]

Based on the data I am seeing, you will want a state machine for reading your data.  First have a state where you read 1 byte at a time until you find a 0x7E.  That will mark the beginning of your message to read.  From there, read 2 bytes and that will give you your message length (not counting the CRC).  So then read the message length+1 bytes.  You will now have your entire message.  I recommend passing that string to another loop via a queue for processing.

For processing, just use String Subset to get the parts you care about.

[superomario]

Is there a tutorial you can refer me to for creating  a state machine? 

[udka]

Tutorial on State machine : http://www.ni.com/tutorial/7595/en/

-Inbuilt example: Help-> Find examples-> Search for State machine.

[superomario]

Okay so that is a crazy confusing tutorial......does this sound remotely like a correct interpretation of it in the context of my question? 

I have no idea what they mean by the initial state of my system is, it's just always on and reading data....is the initial state the VISA serial configure? 

The "states' are the different node identifiers (333,444, or 555).  So when a 333 appears (not sure how to get this callout, event structure?) the "machine" needs to read the hex string 4 bytes after 03 33: 

7E 00 17 81 03 33 1F 00 20 5A 20 30 30 30 33 31 20 7A 20 30 30 30 33 31 0D 0A D6

I don't understand this states and paths thing, there are are 3 nodes, and they all have one path....how am I splitting them up? 

[superomario]

Do you have an example of this? I am looking at the example state machine fundamentals in the help library, but what is my initial state? and where do I put things like visa read or wire things between states? do I have a visa configure in each state box? 

---

@crossrulz wrote:

Based on the data I am seeing, you will want a state machine for reading your data.  First have a state where you read 1 byte at a time until you find a 0x7E.  That will mark the beginning of your message to read.  From there, read 2 bytes and that will give you your message length (not counting the CRC).  So then read the message length+1 bytes.  You will now have your entire message.  I recommend passing that string to another loop via a queue for processing.

For processing, just use String Subset to get the parts you care about.

---