SparkFun Forums

[Schema]

Picture is worth 1000 words:



I have four Arduinos collecting data and sending it wirelessly to a PC over Series 1 (802.15.4) XBees.

Details:

• The data rate is 57600 into the XBees and 115200 into the PC.
• Range is less than 50 feet.
• Messages are very short, around 30 bytes.
• Messages are sent every 10 milliseconds (this can be adjusted if need be).

This works very well for the most part, but I have noted some occasional weird fragmentation,where one message occasionally appears in the "middle" of another message. This doesn't make sense to me as the messages are very short and sent in a single burst through Serial.print(). So why does it fragment?

Example with a test message:

Code: Select all

Hello - I am Device #2.   Count=1168
Hello - I am Device #3.   Count=948
Hello - I am Device #2.   Count=1169
Hello - I am Device #1.   Count=1089
Hello - I am Device #3.   Count=949
Hello - I am Device #2.   Count=1170
Hello - I am Device #1.   Count=1090
Hello - I am Device #4.   Count=764
Hello - I am Device #3.   Count=950
Hello - I am Device #2.   Count=1171
Hello - I am Device #1.   Count=1091
Hello - I am Device #4.   Count=765
Hello - I am Device #3.   Count=951
Hello - I am Device #2.   Count=1172
Hello - I am Device #1.   Count=1092
Hello - I am Device #4.   Count=766
Hello - I am Device #3.   Count=952
Hello - I am Device #2.   Count=1173
Hello - I am Device #1.   Count=1093
Hello - I am Device #4.   Count=767
Hello - I am Device #2.   Count=1174
Hello - I am Device #1.   Count=1094
Hello - I aHello - I am Device #3.   Count=954
 - I am Device #4.   Count=768
Hello - I am Device #2.   Count=1175
Hello - I am Device #1.   Count=1095
Hello - I am Device #3.   Count=955
Hello - I am Device #4.   Count=769
Hello - I am Device #2.   Count=1176
Hello - I am Device #1.   Count=1096
Hello - I am Device #3.   Count=956
Hello - Hello - I am Device #2.   Count=1177
I am Device #4.   Count=770
Hello - I am Device #3.   Count=957
Hello - I am Device #4.   Count=771
Hello - I am Device #2.   Count=1178
Hello - I am Device #1.   Count=1098
Hello - I am Device #3.   Count=958
Hello - I am Device #4.   Count=772
Hello - I am Device #2.   Count=1179
Hello - I am Device #1.   Count=1099
Hello - I am Device #3.   Count=959
Hello - I am Device #2.   Count=1180
Hello - I am Device #4.   Count=773
Hello - I am Device #3.   Count=960

I have RO (Packetization Timeout) set to 3 (the default), would increasing this be of any benefit?

Is there another setting or system configuration I should look at?


Series 2/API mode are overkill (we don't need the range or a mesh), and a colleague has tried this setup with Series 2/API mode with similar results anyway.

Any other suggestions? Thanks!

[DanV]

If the messages have any chance of coinciding with one another then that's a guarantee that they will (eventually).

We don't know what your code looks like, but with multiple serial devices trying to talk into a concentrator, a semaphore to start the message to identify who it's coming from will likely be necessary to build a unique receive buffer from each device to avoid mixing them. A message terminator will also be necessary to indicate message end.

[Schema]

Good point. Though I (possibly incorrectly) assume that the XBees had an internal packet buffer, and what I am seeing is packet fragmentation. How else would one message get inserted in its entirety into the middle of another? (As opposed to individual bytes getting interleaved or dropped).

[stevech]

Xbee S1 have a buffer large enough for about 100 bytes which is the max sized 802.15.4 frame.
If you overrun that buffer with big messages or lots of small ones, data will be lost. You need to use flow control - and this can be done in several ways, including
1. Hardware: use the CTS signal from the XBee and enable it.
2. Be sure to have ACKs enabled in the XBee config.
3. Use the Digi Binary API. This enables you to send a frame and wait for the success/fail status of that frame. Even with ACKs on there will be occasional failures due to clear channel assessments, fading signals, and other causes. In any comms system, at some point the error correction in the link layer will fail and the app must decide: try again or discard data.
4. Use an application layer error correction and flow control mechanism - by handshaking between nodes with such management messages. Numbered messgaes for lost message detection. Mind the issues of 802.15.4 frames being small.

and so on.

[Schema]

Thanks, all good tips! My application can handle the occasional dropped packet, no worries there.

Turns out the trick was to increase the RO parameter to 10 - this made the messages clearly interleaved, it's working great now.

[Valen]

Looks like you'll run into a bottle neck at the PC anyway:

30 bytes per packet, ever 10 ms= 3000 bytes per second per source Xbee.
4 Source Xbees makes 12k bytes /second.

Your PC Xbee has a datarate of 115200 baud to the pc, which comes down to 11520 bytes per second, or 11.52 kbytes/second. Not enough to handle the dataflow!

[stevech]

yes.

The XBee serial link (to PC) can be 115200. But the 2.4GHz 802.15.4 link, with overhead and without delays from interference (CCA), is at the very best about 30Kbps. Plan for something like FIVE transmissions per second per XBee at the very most. I've done 60/second using the binary API but that's really pushing it. Ast 5/Xbee/sec, you should limit simultaneously transmitting XBees to not overwhelm the hub of the network.

Note that XBee S1 serial link is best run at 56K, not 115K - because as in the Xbee specs, the 115200baud rate is in error by 2+ percent. This is because the microprocessor in the XBee has an 8MHz clock and no fractional baud rate divisor. The 56K rate is still faster than the effective bit rate for incoming frames.