5
\$\begingroup\$

I am transmitting continuously at 9600 bps using the default configurations for both my XBees XB24-B. The communication is one way only, the transmitter is connected to the ATMega328 UART and the receiver is connected to the PC via USB (FTDI). Here is the actual data rate for a given program:

  • Wired connection (no XBee) : 7694 bps
  • from the ZNET 2.5 Router/End Device AT to ZNET 2.5 Coordinator AT: 6800 bps (some lost packets)
  • from the ZNET 2.5 Coordinator AT to ZNET 2.5 Router/End Device AT: 0356 bps (many lost packets)
  • from the Zigbee Router/End Device AT to Zigbee Coordinator AT : 0000 bps (doesn't work)
  • from the Zigbee Coordinator AT to Zigbee Router/End Device AT : 0328 bps (many lost packets)

Why is that? Is there anything I can do to improve these rates?

Edit For higher baud rates (115200) I get even worse packet drop rates:

  • Wired connection (no XBee) : 94200 bps
  • using XBee XB24-B ZNet 2.5 : 27900 bps

Edit If I make the Coordinator address the End device, then the packet drop rate falls to the normal levels (6800 bps), which is not ideal but better than the previous scenario

\$\endgroup\$
4

3 Answers 3

Reset to default
4
\$\begingroup\$

You can [reduce to zero the dropped packages][1] by assigning the correct destination address before starting transmission.

\$\endgroup\$
2
  • \$\begingroup\$ The linked page was reported to be a malware attack site. \$\endgroup\$
    – W5VO
    Feb 14, 2019 at 15:04
  • \$\begingroup\$ Yes unfortunately the original site is not there anymore. \$\endgroup\$
    – Demetris
    Feb 14, 2019 at 18:53
2
\$\begingroup\$

whats the signal strength and speed of the wireless link look like? Check the XBee API docs you should be able to access this information. What antennas are you using?

Zigbee's raw data rate is only 250kbit/sec in the 2.4Ghz band and it is a very high overhead protocol. With near perfect signal strength and encryption enabled you should only expect ~20-25kbit/sec max data throughput without customizing the stack, a bit more without encryption. Zigbee's protocol really only supports sending data that fits in a single packet, which off the top of my head is something like 100 bytes. If your sending a stream of data the application layer has to break that data into packets, and include additional information in the data space of the packet so that it can be reassembled. This process can be quite slow and cut further into the data throughput.

Digi's digimesh stack is a bit faster as it cuts overhead and allows larger packets.

Not sure what your intended final application is here, but Zigbee is not at all designed for streaming data. Its for sending small bits of information, sensor readings, instructions, etc that fit into a single packet. You very well may have just chosen the wrong protocol for your application.

\$\endgroup\$
5
  • \$\begingroup\$ I'm streaming audio. Is there any more suitable protocol which uses the same hardware? Which protocol do you recommend? Bluetooth? \$\endgroup\$
    – Jader Dias
    Nov 2, 2010 at 17:32
  • \$\begingroup\$ If it's not already digital audio, use FM. If you can find a premade transceiver with the right bandwidth then it's easy. \$\endgroup\$
    – AngryEE
    Nov 2, 2010 at 18:12
  • \$\begingroup\$ @Jader: How were you going to stream audio at 9600bps? 1.2Kbps is way too slow. If you want to stick in the digital realm for some reason, Bluetooth has PCM interfaces designed for streaming audio. \$\endgroup\$
    – Nick T
    Nov 2, 2010 at 20:47
  • \$\begingroup\$ @Nick I won't stream audio at those rates, I was just trying to solve one problem at a time. My concern now is to optimize the XBee. I'll look into Bluetooth, thanks! \$\endgroup\$
    – Jader Dias
    Nov 2, 2010 at 22:53
  • 2
    \$\begingroup\$ you should absolutely never, ever, ever, ever use zigbee for streaming audio or anything that is timing or throughput critical. \$\endgroup\$
    – Mark
    Nov 3, 2010 at 2:43
0
\$\begingroup\$

UPDATE: With the recent revalation that the Zigbee isn't made for streaming data, I would suggest throwing it in the trash and purchasing a better transceiver with more functionality, more throughput, and about 1/4 the price

I highly recommend utilizing flow control if possible to address the lost packets. Chances are, small but significant periods of time when one device is processing, it is not looking at its UART pins and thus misses bits/bytes and can hang things up. By implementing hardware flow control (RTS & CTS pins), each device can tell the other when it is ready or not for more data.

Once you hook up flow control, I think you'll achieve the higher throughput you're looking for =)

I work with Bluetooth OBD devices that link my Android app to vehicle networks, so I work with wireless/Bluetooth quite a bit.

\$\endgroup\$
4
  • \$\begingroup\$ My MCU doesn't have builtin flow control, so i'll have to implement it. \$\endgroup\$
    – Jader Dias
    Nov 2, 2010 at 17:47
  • \$\begingroup\$ flow control will not solve the problems with throughput on zigbee, it was never designed for streaming data. \$\endgroup\$
    – Mark
    Nov 3, 2010 at 2:44
  • \$\begingroup\$ Updated my answer. I use the device that I linked to and it is a cinch to work with. \$\endgroup\$
    – Brad Hein
    Nov 3, 2010 at 12:32
  • \$\begingroup\$ Do you realize that bluetooth and zigbee are very different protocols? If you need zigbee bluetooth does not do the job. One device to another for bluetooth, perfect. For a set of slaves and a master, yes. For a mesh network with many nodes, bluetoth will not work. \$\endgroup\$
    – Kortuk
    May 10, 2011 at 10:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.