Maximum API packet rate?

XBee & XBee Gateway XBee - 802.15.4
1

Hi,

My application requires 1 coordinator, spending most of its time waiting for API packets, and two end devices correctly associated. One device is sending one api packet every 160ms with 100 bytes payload, the second one is sending a 10 bytes payload every 250ms. All Xbee modules are set on 57600 bauds.
When only one end-device is active, everything is fine. When both are connected, I am loosing some packets, and the overall packet rate at the coordinator is cycling between normal and stall.
I am starting to wonder if XBee can do it. any experience around with this kind of issue?

regards.

2

Could you provide a bit more information here?

  1. Are the coordinator and end devices sleeping between packets? (I’m guessing not, because of the different sending periods.)

  2. What sort of API packets are these? Transmitted data, line passing, etc?

  3. What are the firmware and hardware versions (VR and HV parameters)?

  4. Are the end devices sending their packets to a broadcast address or specifically to the coordinator?

I don’t know whether you can extract and post the non-default parameter settings from the XBees, but if you can it might help.

The data rates don’t sound too extreme, so maybe some other problem is causing the trouble.

3
  1. neither the coordinator, nor the end devices are sleeping.
  2. Packets are TX transmit request 64 bits. the 160ms device has ACK enabled, the other one has not.
  3. firmware version: 10CD, Hardware version 1707.
  4. the end-devices are set to send their packets to the coordinator only.

I was playing around with the XBee Retry parameter, setting it to 5 helps but I can have up to 1 second without receiving any frame.

Coordinator
panID 3310
MY 0
RR 5
CE 1
A2 4
NI XBEECOORDINATOR
BD 6
AP 1

End Device 160ms
panID 3310
MY FFFE
RR 5
A1 4
NI MYBOARD
BD 6
AP 1

End device 250 ms

PanID 3310
MY FFFE
RR 2
RN 1
A1 4
BD 3

Thanks for your help.

4

Mm. Nothing obvious springs to mind. I’m assuming, by the way, that “BD 3” for the 250ms device is a typo - otherwise it wouldn’t work at all.

Do packets from both devices get lost? If you can, it might be worth monitoring the TX response packets received by the 160ms device (since that one has ACK enabled). The status value in the response packet should indicate why packets are being lost. Also if you can, enabling ACK on the 250ms device and monitoring its response packets ought to give more information.

If you can’t monitor the response packets, I’d be inclined to try a test rig, sending similar packets via two XBees at similar intervals from a PC. That way the responses could be monitored. I know that’s a hassle to set up, but I’m afraid it’s the best idea I’ve got at the moment…

Ah, well, there might be one idea. You could check with the good folks at Digi support and ask whether there are any known issues between firmware 10CD and hardware 1707. I mention that because the hardware version is earlier than the current versions (maybe Rev A?). For a hint that such issues are possible, look back in this forum for the topic entitled “Run module without antenna”.

5

BD 3 is not a typo. I thought it the RF section was not affected by uart speed. I’ll do a test with all the devices running the same baudrate.
Since I have increased RR less packets are lost. In the current status of the test, I can only monitor the 160ms device, and when losing a packet, TX Status is noACK. Today I could measure about 1.2 seconds without any packets at the coordinator when the two end-devices try to send their information at the same time. Weird isn’t it?
Running the 250ms device with ACK is not a peace of cake, I think I’ll simulate it on another PC.
I’ll try to talk with digi’support for sure. And i’m going to check the forum immediately.

6

Oops - sorry, I wasn’t thinking straight. There’s nothing wrong with BD 3, as you point out.

Looks like the experiment and the support request are the way to go.