Over the past few months I’ve crafted a simple protocol that sits on top of API2 mode and simulates a reliable Serial stream - i.e. for UNIX to Arduino comms.
It uses a Selective Repeat ARQ algorithm with a 7 frame window, a simple header with bit masks to identify sent/acked packets; and is binary safe and symmetrical.
I use Zigbee frames with no TX Status requests to reduce noise as I found the TX Status does not guarantee successful receipt.
Having testing locally and then ported the code to an Arduino, I’ve finally managed to see how it performs in the RF world.
Early results are quite disappointing. Anything much less then say a 2.5 second delay between frames; or a frame size greater than say ~36 bytes (plus API2 headers) causes missed frames and collisions and kills the performance due to the extra ACKs.
This then leaves me with ~80bps. And this is with only 1 Ack per 7 frames. A far cry from the 4000bps in a single point to point transparent mode.
The device is showing:
EA=56
TR=6
ER=0
I still have a few aces. I am using nodejs on the gateway side which can be ported to C++. But am quite concerned my approach will fail for the goal of getting say 50k of image data down in less than 10 minutes from N addressable digimesh nodes.
Welcome any feedback from XBee developers experienced in optimising RF performance.
After spending some time tweaking the protocol; fixing defects and tuning the parameters, we’re now seeing > ~400kbps of reliable, acknowledged packets across multiple nodes with scope for further improvement.
Am very happy with our protocol and of course with your devices!
The gateway code is still nodejs. If someone wants to use our protocol in return for converting the gateway code to threaded C++, feel free to get in touch.
Thanks for this. We have removed some defects and tweaked the parameters of our protocol and are now getting a reliable 3.5kbps, out of the 8kbps suggested which is adequate for delayed image capture.
However, I am curious to know how we can leverage the possible 200kbps mode?
Our devices are flagged as being XBP9B-DM, Function set: XBee PRO 900HP 200K with Firmware 8067. However, we have never seen anything greater than the 8.8kbps you refer to so am assuming we have the 10kbps models.
Would this be correct? Or is there a toggle we can use to enable the faster rates? Just trying to clarify if indeed we have 200kbps models; how to find out if we do; how to toggle the faster speed if possible; or what we need to do/purchase to get this higher speed?
The 200k rate you are referring to is the RF data rate. That is the rate the two modules talk to each other. That is not the throughput. For that you need to look in the manuals.
This is still quite confusing. There are baud rates that range right up and past 115200bps. Then there is specific reference in the manual to a 10kbps mode and a 200kbps mode. Are we to assume that the through put is still capped around that 8kbps top end regardless? Thanks
Page 47 indicates the throughput of the XBee PRO 900 HP module using the 200K Mesh Code. Depending on what version of code you have and the exact module, you may be at the best data rate.
If you are using the 900 HP module with the 200K code and 1 hop, you should be able to get around 90kbps.
Ok. So there is reference here to 105.5 kb/s for the 200 kb/s “version”. As we are getting an effective acknowledged throughput in the order of ~3kbps, I can only assume we must be using the 10 kb/s version.
So the question becomes, what do we need to do to toggle our modems to 200 kb/s? And if this is not possible, which units do we need to purchase?
Again, these are our devices: XBP9B-DM, Function set: XBee PRO 900HP 200K with Firmware 8067
Do they support such a toggle/upgrade and if so how is this achieved?
That would be the 200K code just an older version. Sounds like you need to do some adjustments to the settings and maybe an update to the latest 8071 version.
Once you have updated your Code to the 8071, I would suggest the following settings:
Thanks for that. The above settings didn’t make any real difference; and the firmware upgrades failed (using X-CTU on OSX) so we had to restore the devices to their original firmware.
However, you gave us the confidence to try and reduce the transmission delays (now only 5ms) and this has seen steady throughputs in the ~11.5kbps range which is a great improvement and there may be scope to improve further on this. It may well be that the settings changes assist at the lower transmission delay intervals.
Our protocol has been tweaked for the XBees in API 2 mode with only 1 Ack per every 14 packets - exposing reliable streams between a gateway and 1:N devices as named UNIX sockets on the gateway side.
If you wish to contact me offline to discuss in greater detail, I’d be delighted.
If you are using API mode, then make sure you are adjusting the TO value in your API frame.
To upgrade firmware, you need to be using a board that has DTR and RTS connected. If that are not, then XCTU will fail on the upgrade regardless of what operating system.
Increasing the frame data portion to 102 bytes has given an extra boost. We’re now getting some ~15.8kbps. There is also the latency in the FTDI cable setup and the code itself. Am tempted to do an unacked speed test to see what the maximum through put is for our physical setup.