as some of you, too, I seem to be running into the / some kind of duty cycle problem: I have two XBee 868 PRO’s (S5) connected to two Dev-Boards. Range Test works perfectly fine, and data transfer also works well without significant packet loss.
However, even when sending only a constant data stream (one direction) of 270bit/s (without any RF-overhead / retransmits) over the X-Bees, the connection breaks down after 30-40 minutes. As the 868-PRO manual states, the Duty-Cycle limitation should only kick in for continuous RF data streams of >2400bps (10% duty cycle on the 24Kbps), and I am well below that value! If I hard-reset the transmitting X-Bee, then it re-begins transmitting, and if I wait long enough then it also begins again. When the connection is broken, it by the way still receives data from the UART (transmit LED on dev-board blinking), but the receiving X-Bee does not receive this). To investigate this behaviour, I performed some logging of the messages that I receive over time: The first image is with 272bps transfer rate and the second one with 880bps, with the x-axis being the time in milliseconds. It is pretty obvious that the x-bees begin the retransmit after pretty exactly one hour again…
The settings of my test setup / xbees are:
[li]Test in office environment, ca. 4m apart
[/li][li]Power level 0 (1mW)
[/li][li]Retransmit enabled (I could disable this of course)
[/li][li]“Receiver”-XBee is on a Win7 64bit PC
My questions are therefore:
[li]Is this really the 868-PRO’s duty-cycle limitation?
[/li][li]If yes, then why does it occur at these low data rates?
[/li][li]Do you know how big the generated RF-data overhead is? Can one calculate that? If the RF-data overhead is large, then this might explain the duty cycle problem.
If you have any recommendations please let me know. Also I’d be happy to perform some further analysis as you recommend.
Thanks & Best regards,