Xbee API mode speed issues

I have Series 1 chips and was trying to setup a star “mesh” network using the api mode. This includes one xbee plugged into a usb explorer on my laptop in Coordinator mode. Then I have to others setup as End Devices connected to two musical instruments collecting their data in order to relay the data to play midi on the host computer.

Now if I just have 4 xbee’s setup in transparent mode just as cable replacements, this things fly. No lag, delay, etc. But if i try to do a proper star topology in API Mode, there is a huge amount of delay and I’m not receiving all my hits. (plus i keep getting random checksum errors)

So my question is, am I doing something wrong or is API Mode not suited for this high rate of data transmission? And could the issue be that I’m using Series1 chips and not a proper mesh network with Series 2 chips? Is there an increase of speed between them and would they be better suited for this?


PS I’m using the xbee-arduino and xbee-processing libraries


There are several issues here. The one I’d concentrate on first would be the random checksum errors, because there’s definitely something going wrong if that happens. Could you post example packets, with and without the errors?

You also ask whether API mode is suitable for your transmission rate, but you don’t say what the rate is. A bit more detail would be helpful.

As for using series 2, I don’t think you’d see an improvement. Series 2 are good for routing (long distance transmission) but that itself comes with a cost in speed.

Further thought: if you use X-CTU to save your XBee settings to .PRO files, and attach those to a post, it’ll give even more insight into what’s going on.

Its interesting… Now its not working at all when i reflashed with the old API mode files. Here they are if you can make heads or tails of it:

Ok, the .PRO files don’t look like the source of the problem. On the other hand, if I understand you correctly, these don’t reflect the state of the system when you had it partially working.

If you can restore things to the partially working state, and then capture and post some packets (including examples with and without checksum errors), and ideally also post the .PRO files from that state, we can try again.

I don’t think it’s a cause of the problem, but just in case, try resetting the CE parameter to 0. You don’t need a designated coordinator unless the other xbees are sleeping.

For the life of me i can’t seem to get it to work again in any configuration I had before. I’m not even getting a blue sync light on my adafruit usb explorer. Nothing coming up on XCTU’s terminal either. Is there a chance anybody has a working set of .pro files?


> Is there a chance anybody has a working set of .pro files?

Much better than that: use the RE command to reset all parameters to the factory defaults, and then the WR command to save the settings to flash. Now you’re back at a known starting point, and you can experiment from there.

Try getting it working with a low data transmission rate first - no more than 10 packets per second. The XBee can do much better than that, but you’ll be testing the correctness of your setup before seeing how fast it can then go.

Well, its been a year. I finally got back to this. It seems the issue was the library I was using wasn’t parsing the packets fast enough. I used a more streamlined java library and got it much faster. But, still too much latency to do real time midi from two devices (Anything over 10ms is noticeable lag). Point to point is fine (cable replacement in transparent mode). So if you want to do midi you would need two modules per channel. That gets expensive. I’m going to have to switch to RF or Bluetooth. Hope this helps somebody else!

Anybody feel free to correct me if I’m wrong :slight_smile:


I actually just posted a new thread, and then saw your topic was virtually the same as mine (http://forums.digi.com/support/forum/viewthread_thread,10743). To sum up my post, when using API mode my transmissions take about 1/4 second but I would like to speed that up.

Could you go into any more detail about parsing the packets? My library is open source, written in C++ and seems to be very well put together so I am not sure if I can increase the speed but could be worth looking into.

Also, did you try increasing the baud rate to maximum to determine if that could increase the transmission speed (in case the delay is caused by the micro communicating with the zigbee)?


Is this a ZigBee/S2 or 802.15.4/S1 question?

802.15.4 can work with 50msec or less latency. ZigBee (due to node discovery) at times will force up to 5 seconds of latancy.

If you really want less than 10msec, you’ll need to switch to a dumb (non-packetized) radio design without error correct. I don’t see how BlueTooth even would help.

Also, at those speeds I doubt Java is a viable option. At 4 byte packet at 9600 takes nearly 5msec just move acorss 1 serial buffer/channel, so add in 2 serial channels and RF and you’ll see 10msec is tough to hit. So using 115kbps will help, but you still have ‘time’ lost in the physicall shifting. You’ll probably need to use C/C++ at least to process the incomign data ASAP.

I am using 802.15.4/S1.

For some reason, when testing today the speed seems much faster. Not sure why, but I will post here if I can figure out anything related.


I have found out this problem was due to me sending xbee packets every iteration of my main loop, which would be every couple milliseconds (maybe even less). I guess this caused too much traffic in the xbee buffer, and was responsible for the small delay. Now I only send xbee packets when an event changes, which is much less often.

Thanks for the help.