Duty cycle calculation working correctly?

XBee & XBee Gateway XBee - Point-to-Point/Multi-Point
1

My XbeePro868 is configure the following way:
115200 8N1, API Mode 2

In the application i additionally configured

ATMT0   - Only one multicast transmission
ATAC    - Apply changes

using the AT Command Frame. The response status is success.

Afterward i send TX frames every 3 seconds:

TX Frame (0x10), Id=0x4a, broadcast_radius="0", options=0
   Dest/Net: 00:00:00:00:00:00:ff:ff/fffe
   Data:  54 65 73 74

After every TX message i query the Duty Cycle status with ATDC. What i see now is that the duty cycle count is slowly increasing.

I don’t know how the RF frame looks like. IMHO it should be less than 1000 bits (<125bytes) on the air. With an RF data rate of 24kbit/s, this means we TX for less than 1/24s in 3 seconds. This gives a duty cycle of about 1.4%.

So why is the DC increasing slowly?

Is the DC a moving average over one hour or is it reset to zero after every hour?

How can i estimate the duty cycle without randomly testing?

TIA,
Michael

2

Update:

I let the test run for an hour and the DC stopped increasing at 6 (6% of allowed duty cycle or 0.6% duty cycle). That means the packet has approximately 432 bits or 54 bytes. For comparison the API Frame sent to the XBee module has 22bytes.

So i can answer the first two questions myself. But it would be nice to have an answer to my last question as well. What is the overhead i have to take into account when trying to estimate the duty cycle?

TIA,
Michael

3

Hi

Sorry, my english is realy bad.

I’ve made some little tests with X-CTU
The setting was:

RR (MAC retries): 0
MT (Multi Transmit): 0
PL (Power Level): 0

BD (Boud Rate): 4 (19200)
NB (Parity): 0 (none)
SB (Stop Bits): 0 (one stop bit)
RO (Packetization Timeout): 3
FT (Flow Control Treshold): 0x11
AP (API Enable):0 (OFF)
AO (Api Options): 0 (OFF)

The total data-volume is about 864000 Byte/h
2400Bit/s / 10Bit = 240Byte/s (8 data bit + 1start bit + 1stop bit)
240Byte/s 6060 = 864000Byte/h

I’ve reached in several tests with X-CTU (17Byte per transmition) about 289000Byte/h.

This means that the overhead is about 2/3 of the transmition volume.

Maybe someone knew’s a setting to enlarge the useable data volume.