Large delay in continuous read_data() operations

danslinger commented 10 months ago

I am attempting to send a sample message using API mode from one XBee to another at 1 Hz. I have confirmed the sender does send the data at 1 Hz. And, using a basic serial connection I can confirm the message comes in very quickly, as expected.

My issue arises when using an XBeeDevice and its read_data() method. My simple loop looks like this:

xbee = XBeeDevice("/dev/ttyUSB0", 115200)
xbee.set_sync_ops_timeout(0.1)
xbee.open()

try:
    while True:
        msg = xbee.read_data()
        if msg:
            print(msg.data)
except KeyboardInterrupt:
    pass

finally:
    xbee.close()

Despite my sender sending at 1 Hz, the fastest I can receive messages is once every 4 seconds. I did some digging and discovered AbstractDevice._DEFAULT_TIMEOUT_SYNC_OPERATIONS is set to 4. I discovered the set_sync_ops_timeout() method and hoped that would fix it but it did not.

I dug some more and figured out the spot where the operation is actually delayed. In PacketListener.run() after a packet arrives, if it has information about the remote device that sent it, it will attempt to add it to the XBeeNetwork. That process includes creating a new remote XbeeDevice, which then utilized the same AbstractDevice.__DEFAULT_TIMEOUT_SYNC_OPERATIONS value. I'm not exactly sure where that ends up slowing things down, but if I edit the _DEFAULT_TIMEOUT_SYNC_OPERATIONS to 0.1, I am able to get messages at 1 Hz as expected.

I have also attempted this with the basic read example that uses callbacks that I found in this repository and have the same 4 second delay.

I appreciate any advice on this. Is there a way I can make sure the remote device is created with a shorter timeout value? Is it safe to do so? 4 seconds seems like a really long timeout for serial read operations, but I wonder if there was a specific reason for that.

sayaz commented 10 months ago

I do have the same problem. Just a note, that I am using firmware 'Digi XBee 3 802.15.4'. But when I change the firmware to Digi XBee3 Zigbee 3.0 (1013 Newest version) everything works out fine (i.e. no delay).

Moreover, if you check the logsl, the specific reason is: DEBUG : 9789 - Error while trying to get 64-bit address of XBee (FFFFFFFFFFFFFFFF - - 0000): Response not received in the configured timeout.

danslinger commented 10 months ago

I am using the Digi XBee 3 802.15.4 latest firmware. I will try the Zigbee one and report back. Thank you @sayaz for your response and suggestion.

rubenmoral commented 10 months ago

@danslinger, please check if this response solves your issue.

danslinger commented 10 months ago

I tried what @sayaz suggested and switched my firmware. It mostly improved it (I could still sense a slight delay at about 1Hz just by looking at my screen printouts).

I also tried was @rubenmoral suggested. This is the work-around that worked for me. And I didn't have to change the firmware to a different protocol to allow it to work. Thank you @rubenmoral !

I'll leave this open and let Digi decide how to triage it. I still consider this a defect in this library. This behavior isn't seen if using XTCU or any other home-built serial application, which implies this "fix" is really a work-around to the underlying issue.

sayaz commented 10 months ago

@danslinger @rubenmoral True. While the 4 sec delay issue is solved for me, it seems the airtime of the communication is high. For e.g. If I send a frame of only 16 Byte payload, the receiver receives (reads and prints) it after about 20-30ms. I need to get that down below 10ms (to sense the environment and report back to server). I am using the same machine to connect both Coordinator and End Device just to be accurate on the time stamps.

Few observations:

If I use the throughput tool of XCTU software, with max payload size of 100 Bytes, the throughput is about 15 Kbps (115200 baud). And if I decrease the payload size to say 10 Byte, I can get a throughput of only ~3 Kbps (while I am on same wireless channel and same baud rate). I understand that the header size is not changing, but If I lower the payload size, it should have a less airtime (compared to that of 100 Byte).
Increasing the baud over 115200 also bricked by device. I had to reset them. Though the device may support higher baud rate, it also needs to be supported by the laptop interface

tatianaleon commented 10 months ago

@danslinger, what @rubenmoral suggested is NOT a workaround, it is the way 802.15.4 devices work. We really recommend to read user manuals to check how XBee modules work, in this case, Digi XBee® 3 802.15.4 RF Module so you can properly configure them.

@sayaz, when using baudrates over 9600 it is recommended to use hardware flow control, especially with a lot of traffic that may overrun serial buffers.

Closing this issue as it is a problem of configuration.

Best Regards.

digidotcom / xbee-python

Large delay in continuous read_data() operations #296