LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Starting Data Read at correct Byte

Hi All,

 

I am creating a custom interface for an IMU to collect data for post processing. 

The IMU produces data of 36 Bytes, like this:

FE 81 FF 55 37 A9 6A 6E 38 58 6C 1F B7 5B F8 62 BF 80 3E 78 BB 65 0D 28 3B 0A 37 AC
77 3D 00 28 4B FA 34 D8

Danmcg_0-1644335632329.pngDanmcg_1-1644335645829.png

I have created an interface using this example output that uses 'string subsets' & 'type casts' to split up the data into the correct parts. This works fine, but when I connect the IMU up and start receiving a data stream the data is not always captured starting with the header. 

The header always starts with FE81FF55, so I have been trying to only start collecting data after this point using some sort of string matching block and can't quite figure out if I can use the termination character on the VISA serial port. 

 

The data is currently being captured via a USB interface box, so makes use of the VISA Serial block and the visa read blocks. I also have a buffer that waits for 36 bytes to be collected, but like I say it doesn't always start with this header message. Any advice would be greatly appreciated?

 

Many thanks,
Dan

0 Kudos
Message 1 of 3
(1,258 Views)

Hi Dan,

 


@Danmcg wrote:

 can't quite figure out if I can use the termination character on the VISA serial port. 


No you cannot use a TermChar for "raw"/"binary" messages…

 

Why don't you use the CRC byte to verify you parse a valid message? Only parse valid data: starting with valid header and finishing with valid CRC checksum…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 3
(1,246 Views)

1. Turn off the termination character.

2. I would suggest something like below.  Read 1 byte at a time until the first character of the header is read (0xFE).  When you read that value, read 3 more bytes to get the rest of the header and verify it is correct.  If that passes, then read the other 32 bytes in the message.  You really should verify the CRC passes as well.  I didn't have the information on the CRC, so I did not include that.

3. I am a big fan of using Unflatten From String.  You can just wire up a cluster containing all of the data in the message as the data type and it will do all of the work for you.  Just make sure your data types are correct (SGLs for all of those floating point values).  From there, it is a simple Unbundle By Name to get the exact value(s) you care about.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Download All
Message 3 of 3
(1,228 Views)