Hello Digi Community,
I am working on a time-critical application using XBee3 modules and I’m trying to minimize the round-trip time (RTT) as much as possible.
My application requires an RTT below 10ms. Through careful measurement, I’ve determined that a significant portion of my total latency comes from the internal processing time of the XBee modules themselves. After accounting for host processing and the RF time-of-flight, I’m left with a consistent ~5 to 9ms one-way internal processing delay within the XBee module. This means my total RTT has a 10-18ms floor from the modules alone, which is a major bottleneck.
My goal is to understand if this processing floor is reducible.
Hardware and Configuration:
-
Modules: 2x XBee 3 RF Modules (XB3-24)
-
Firmware: 802.15.4 v2014
-
Topology: 1x Coordinator, 1x End Device (simple point-to-point link)
-
Host Interface: UART baudrate 921 600
Test Methodology:
To assess the module’s internal processing time, a 2-channel oscilloscope was used to measure the one-way latency from the UART Tx of the coordinator to the UART Rx of the End Device. Measurements consistently showed a 5ms to 9ms delay, which includes airtime, though this is negligible for a 1-byte payload.
The measures show a lot of variation (jitter) on this delay (from 5ms up to 9ms)
For the tests, a 1-byte payload was transmitted in API mode 1 with 16-bit addressing, and also in Transparent mode. Regardless of the transmit mode, the on-air frame size was consistently 12 bytes and there are few differences of delay between the two modes.
During the test, no external interference or retries (zero CCA failures) were observed.
Optimizations Already Implemented:
I have already performed extensive optimizations based on the documentation and community best practices. My current configuration includes:
-
Transmit mode Optimization: For 1 byte payload there are few differences between the AP and Transparent modes
-
No Sleep Modes: Both modules are configured with SM=0 to prevent any sleep-related latency.
-
Bluetooth Disabled: To eliminate potential delays caused by Bluetooth, it has been disabled. The SoC utilizes a shared RF transceiver for both 802.15.4 and Bluetooth functionalities..
-
Maximized UART Speed: The UART is running at its maximum speed (921 600 baudrate) to minimize serial transfer time.
The Core Question:
Despite these optimizations, the ~5-8ms internal processing delay remains. This suggests it is not due to RF contention or serial buffering, but rather the time the module’s firmware/SoC takes to process an incoming API frame and prepare it for the radio (or reverse).
Is this 5-9ms latency floor an expected characteristic of the XBee3’s EFR32 SoC and its 802.15.4 stack?
Are there any advanced configuration parameters, undocumented AT commands, or specific firmware behaviors that could help reduce this core processing time? For example, settings related to the SoC’s clock speed, interrupt priorities, or other stack timing parameters?
Any guidance or insights from the Digi team or expert users on how to break through this 5-9ms barrier would be greatly appreciated.
I found some literature regarding latency in the Digi Knowledge base, but it does not take into account of the processing time:
Thank you in advance for your help.
