labview not reading full serial data packet, xbee arduino sparkfun

[stevenette]

Hello,

Gear: I have a series pro S2C xbee on a sparkfun xbee shield on an arduino Uno. This gathers data then sends it to a coordinator of the same setup. The coordinator then sends out a serial data packet to labview. Labview reads these data, and then does whatever I want with it.

Problem: Sometimes the complete data packet is read until the 'n' newline, and sometimes only the last few bits are read until the newline. As with all Xbee, the start byte is 126, so I tried waiting for 126, but this resulted in issues if one of the bytes in the data packet were 126.

My concatenated string is fine, but I sometimes lose data packets because the whole packet is not present. I want all data to be clean. When checking the output through arduino ide, the data are totally clean, but as in the youtube I posted below, the read buffer section shows lots of lost data packets. I don't know how else to explain it.

Youtube: https://youtu.be/nn2KVUmbdzM

Basic program attached.

[stevenette]

I think I figured out a workaround.

Instead of just reading the serial data at any point in the progress of the program, I created a tick count measure. After X seconds, run the script instead of waiting X seconds which pauses the program. I have attached my workaround. The only issue is that now instead of one string of data, I have multiples that I have to parse out.

[RavensFan]

So are you saying you are getting binary data, where any byte from 0-255 is part of the data?  Then why do you have the termination character enabled?  Your VISA Configure has it enabled and set to a 0-byte  (null character).  That is probably the worst of the bytes to read since it is extremely likely that any binary data will have a zero byte in the middle of it.

Who wrote the program that the Arduino is running?  If it is binary data, then you should create a protocol that has a start bytes (sounds like you do), then X bytes (2, 4?) of how many more bytes will follow in the packet.  So you read individual bytes until you get the start byte.  Read the next 4 bytes, convert to an integer and feed that to the VISA Read so that you read those remaining N bytes.

The first important think in developing a program that can robustly read serial data is to make sure you have a good program written and a robust protocol for the device that is sending the serial data!

[stevenette]

Yes I am getting data from an xbee that is 0-255. 126 is the inherent start byte for all xbees, then the length, radio address, data packet, then checksum. I read each line until I see a newline character 'n' or '0'. Then I make sure the first byte is126, then calculating and comparing the checksum.  Here are the data I am getting now

126,0,24,144,0,19,162,0,64,215,112,113,41,22,1,3,11,0,3,136,2,43,1,185,0,0,69,189,
126,0,18,146,0,19,162,0,65,131,195,48,26,4,1,1,0,0,1,2,12,210,
126,0,24,144,0,19,162,0,64,215,112,113,41,22,1,3,11,0,3,136,2,47,3,255,0,0,69,113,
126,0,18,146,0,19,162,0,65,131,195,48,26,4,1,1,0,0,1,2,11,211,

The last byte is the checksum calculated after the length (0,24 & 0,18 respectively). But in hex not dec.

My problem is that if I try to receive each data packet individually, I sometimes get the full packet, and sometimes I receive proper data, but labview only reads a random point after the 126, until it reads the newline. I imagine this is because the while loop resets in between a serial transmission, meaning after the 126, yet before the checksum. That is my guess.

If I don't read the serial data for an X amount of time, it creates a large array with full proper data that I should be able to parse out later in the program.

[RavensFan]

1.  Disable the termination character in the VISA configure.

2.  Read 1 byte in a loop until it equals decimal126

3.  Read 2 bytes.

4.  Typecast that string to U16.

5.  Wire that value into the VISA Read for number of bytes to read.

6.  Do whatever the checksum calculation is.

7.  Read 1 byte and compare that to the checksum.

8.  Go back to #1 to start over with the next message.

I don't know what you mean by the checksum calculated in hex and not decimal.  A calculation is a calculation.  A number is a number.  Nothing is "hex" or "decimal" other than what format that value is displayed to you on a screen.

You talk about how the LabVIEW only reads up until the newline character.  And that is true if you have the termination character enabled (the default) and it is set for a linefeed character x0A or dec 10. (the default).  But your VI you have changed the termination character to 0.  So in those cases, it would read until it sees a zero, and not a linefeed character.

[danieladildey]

Hi guys,

I'm doing a temperature sensor using Xbee s2c PRO Zigbee.

I'm having similar problems with this protocol. I did my own VI, with some tips that you give here. In fact I really liked your answer. 

I can read the messages and identificate them, but some times, feel like my module looses itselsf, and came back 3 hours after. This could be some bug in the PORT?

In my application I use this VI a lot of times, but the port is alyaws open before and closed after my use. This VI is inside of listening.

Is there anything wrong that could explain not receiving messages for hours? Or anything that you already saw in other cases like this? Normally the modules send messages every 20s.

[Frozen]

I see no loops in your program. I certainly hope you are *not* using the continuous run button.

[danieladildey]

I'm using other software to test in the application local, that have the loops and a queue that I add commands of search the modules, add them, configurate them, and after that I just listen the samples coming.

What I've sent is a library that we're developing.

[Frozen]

In the first screen-shot, you have open, read close (no loops)
In the second screen-shot, you have your open and close inside your loop. Usually not a good practice. (Why is there a sequence structure around your code?)

However, in neither of the screen-shot do I see the port being configured. Perhaps it is time to stop sending screen-shots and provide the actual code.

Have you simplified your code down to a simple Open, Start loop, read, Stop loop, close sequence yet?