Sleep Timing, Retry Timing, and Encryption Throughput
Below are timing charts showing details associated with transmit/receive timing of our modules. Note that next to each module type is the firmware version. Timing schemes may vary by firmware version.
Sleep Mode Timing
| Modem (firmware version) |
XCite (111) | XStream (42B0) | XTend (2001) | XBee/XBee-PRO (1061) | |
|---|---|---|---|---|---|
| Power up | 68.5 ms | 40 ms | 45.2 ms | 25 ms | |
| /SHDN | n/a | n/a | 37.3 ms | n/a | |
| SM=1 Pin Sleep/Pin Hibernate | 69 ms | 40 ms | 1 ms | 9.5 ms | |
| SM=2 Serial Port Sleep/Pin Doze | 88 ms | 45 ms | 83.2 ms | 1.8 ms | |
| SM=3,4- Cyclic Sleep (pin wakeup) |
69 ms | 40 ms | 1 ms | 1.8 ms | |
| SM=3,4- Cyclic Sleep (RF wakeup) |
n/a* | n/a* | n/a* | 1.1 ms | |
| SM=3,4- Cyclic Sleep (RF "sniff time") |
52 ms | 100 ms | 80 ms | 30.5 ms | |
| * These times are deemed invalid due to the RF "header" of the coordinator | |||||
Retry Timing
This timing chart shows the inter-packet time spacing of each redundancy modes.
| Modem (firmware version) |
XStream (42B0) |
XTend (2001) | |||
|---|---|---|---|---|---|
| RF Data Rate (bps) | 9600 | 19200 | 9600 | 115200 | |
| RR- Retries 1 byte | 63 ms | 51 ms | 86 ms | 9.1 ms | |
| RR- Retries 32 bytes | 88 ms | 63 ms | 110 ms | 11.1 ms | |
| MT- Multiple Transmit 1 byte | n/a | n/a | 69 ms | 7 ms | |
| MT- Multiple Transmit 32 bytes | n/a | n/a | 94 ms | 9 ms | |
| * Retry times are based on time spacing with no received ACK | |||||
XBee & 9XTend Encryption Throughput
Encryption (256 bit AES for the 9XTend and 128 bit AES for the XBee) will slow down throughput for the XBee only. The 9XTend has a much more powerful processor which allows the 9XTend to process the encryption "real time" while the XBee which must perform an additional operation to process the encrypted data.
| Measured Throughput | Encrypted | Not Encrypted | ||
|---|---|---|---|---|
| XBee | ~47Kbps | ~80Kbps | ||
| 9XTend | ~111Kbps | ~111Kbps | ||
The throughput figures were measured with HyperTerminal''''s Zmodem (Zmodem was chosen because of the low associated overhead). It is important to note that these measurements were done by sending large files of data and averaging the throughput based on the entire file. It is also important to note that smaller packets will reduce throughput with encrypted data.
