Hi all,
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:
[ul]
[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
[/li][/ul]
My questions are therefore:
[ul]
[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.
[/li][/ul]
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,
Philipp