LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What is the more efficient way for processing serial port string data?

Solved!
Go to solution

Hello everyone!

  I have a gyro sensor which sends data through UART, It can return acceleration, angle, angular rate and magnetic field data by sending hex string data.

  For example, the string data of the 3 axis acceleration are:55 51 47 FB 5F FE 87 06 A6 0F 87. The picture of data form is attached in my file. To convert it to numeric data, first, I use search/string vi. to find the header 55 51, then, it returns the rest of the strings. Second, 47 is the low byte of the x axis and FB is the high byte of the x axis. To calculate the acceleration of x axis, I convert high byte and low byte string to I16 then it was divided by 32768. finally, multiple 16(the max. range of the acceleration which can be detected by sensor). Y and z axis are the same method with x axis.

  To convert the data of angle and angular rate, the method is same as converting acceleration data.

 

My problem is: If the update rate of the sensor is low, the program works fine. But if the update rate is high(for instance 200Hz), it seems that it can't work properly. Why does that happen? Is using search/string vi. too slow to find high frequency string data?

 

Can anyone help me? Tank you.

0 Kudos
Message 1 of 10
(1,465 Views)
Solution
Accepted by topic author jackylin888

1. Replace the Timed Loop with a simple While loop.  You are just limiting your read rate and adding a bunch of overhead that you do not need.

2. Use the message protocol to your advantage.  Read 1 byte until you read a 0x55.  Then read another byte and verify it is 0x51.  If that is successful, read the rest of the message (9 bytes) and verify the checksum.  If the checksum is correct, then process the message data.  What this does is it ensures you have a proper message and you keep your messages synchronized.

3. Learn to use Unflatten From String.  It will save you a lot of effort.

4. When you are displaying your strings in something other than normal display, you really should show the display style.  Right-click on the string and choose Visible Items->Display Style.

5. For your charts, you can show the Digital Display (under Visible Items).  This will eliminate half of your indicators.

 

Here, I updated to get one of your data messages.  I'll let you figure out how to duplicate frames to get your other data types.


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 2 of 10
(1,436 Views)

@crossrulz  已寫:

1. Replace the Timed Loop with a simple While loop.  You are just limiting your read rate and adding a bunch of overhead that you do not need.

2. Use the message protocol to your advantage.  Read 1 byte until you read a 0x55.  Then read another byte and verify it is 0x51.  If that is successful, read the rest of the message (9 bytes) and verify the checksum.  If the checksum is correct, then process the message data.  What this does is it ensures you have a proper message and you keep your messages synchronized.

3. Learn to use Unflatten From String.  It will save you a lot of effort.

4. When you are displaying your strings in something other than normal display, you really should show the display style.  Right-click on the string and choose Visible Items->Display Style.

5. For your charts, you can show the Digital Display (under Visible Items).  This will eliminate half of your indicators.

 

Here, I updated to get one of your data messages.  I'll let you figure out how to duplicate frames to get your other data types.



Thanks for your reply and teaching.

In general, I can figure out your method. I tried to read acceleration data. It could read successfully.

But when I duplicated frames and tried to read other data(such as angle and angular rate) at one time, it can't work properly.

Why would that happen?

 

0 Kudos
Message 3 of 10
(1,376 Views)

@jackylin888 wrote:

Why would that happen?


Most likely you did something wrong.  Post your updated code and we can discuss from there.


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
0 Kudos
Message 4 of 10
(1,353 Views)

crossrulz
If I'm not mistaken, I think your CRC check is calculated wrong. In the example for message 0x55 0x51, shouldn't the constant be 0xA6 or decimal 166 (0x55 + 0x51 + ...). And for the case of angular rate, it should be decimal 167 (0x55 + 0x52 + ...), etc. It could be why the OP's updated code is not working.

 

CRC.PNG

 

CRC BD.PNG

 

Message 5 of 10
(1,341 Views)

@jamiva wrote:

crossrulz
If I'm not mistaken, I think your CRC check is calculated wrong. In the example for message 0x55 0x51, shouldn't the constant be 0xA6 or decimal 166 (0x55 + 0x51 + ...). And for the case of angular rate, it should be decimal 167 (0x55 + 0x52 + ...), etc. It could be why the OP's updated code is not working.


Good catch.  I have no clue why I screwed that up.  The safer route I should have done is to bring the previously read strings (the 0x55 and 0x52) into the case structures, concatenate the strings, and then do the full sum.


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
0 Kudos
Message 6 of 10
(1,334 Views)

jamiva

  Thanks for your reply. If you mean the checksum calculation is wrong, I have already corrected the numbers for every case structures. The attached file and picture are uploaded.

  By the way, the code is implemented in NI myrio.new.png

 

Download All
0 Kudos
Message 7 of 10
(1,313 Views)

You cannot start your checks by reading 2 bytes at a time.  You have to read 1 and compare it to 0x55.  Otherwise, you will likely get out of sync and miss your messages.  Once you read the 0x55, then you read another byte to get the data type.


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
0 Kudos
Message 8 of 10
(1,286 Views)

I guess an alternative would be to read all and search for 0x5552 and cut the string at the found index+2 and use the rest? (don't have LV on this computer) 🙂

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 9 of 10
(1,273 Views)

@Yamaeda wrote:

I guess an alternative would be to read all and search for 0x5552 and cut the string at the found index+2 and use the rest? (don't have LV on this computer) 🙂

/Y


I have been down that road.  It is dirt slow and you still run into issues of incomplete messages until you do some additional storing of the left over string in a shift register (which just adds to the slowness due to memory allocations).


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
0 Kudos
Message 10 of 10
(1,267 Views)