Home/Support/Support Forum/Minimizing receiver delay

Minimizing receiver delay

0 votes
I recently purchased and am new to the XBee Pro 900 MHz developer kit. Upon initial set up, I am dissapointed to see significant delay in my receiver. I have tested using both the latest DP and DM firmwares. To conduct the test, I have ensured both modules are using the same basic serial settings, baud (9600), etc. They are also both in transparent mode.

My setup is as follows. I have one module, which I'll call the receiving module, connected to the computer with XCTU. The transmitting module is attached to an Atmega328 MCU. The MCU sends a single byte, starting at 0, delays 10ms, then sends the next increment of the byte all the way up to 255.

When I conduct the test, the transmit light on the transmitting module's dev board stays lit, indicating to me that there are no significant delays in the transmission. However, the receiving module's receive LED blinks sporadically. On the console, all the bytes are eventually received, but they are received in odd sized chunks and significantly delays (especially in the case of the DP firmware).

The following two links show images obtained using a logic analyzer that show the delays
DP Firmware

DM Firmware

My desire is to optimize the speed that I can transmit/receive a datastream without inducing delays, the datasheet claims 200 Kbps is possible. Basically I would like a real time data stream.

Can anyone please give advice on how I can accomplish my goal?

Thank you
asked Oct 7, 2015 in DigiMesh Proprietary Mesh Networking by pwnyholm New to the Community (2 points)

Please log in or register to answer this question.

1 Answer

+1 vote
Best answer
First off, the 200 K RF date rate you are referring to is the rate that the two radios talk to each other. It is not the streaming limit. You need to look at page 45 of the manual for that.

Next, the radio packitises all data going into the UART for transmission. By default, the module waits for 3 character times of silence on the UART before it starts the channel initialization and transmission process. Now you can improve on this slightly by setting RO to 0 and setting the DL and DH addresses to match the SL and SH of the receiver. But regardless, there will always be some added delay.
answered Oct 7, 2015 by mvut Veteran of the Digi Community (12,786 points)
selected Oct 12, 2015 by pwnyholm
Thank you for your response. First, I can't seem to find a good manual for the module I have, on the Digi site I get the datasheet (a two pager) and a getting started with the dev kit (21 pager). Could you direct me to the manual?

I think I understand the packetization info, thank you. So does setting the DL and DH to match the SL and SH of the receiver broadcast to that receiver specifically?

Thanks for your help, I'm new to this. A good datasheet/manual would go a long ways.
The manual can be found on line at http://www.digi.com/support/productdetail?pid=5576&type=documentation.

Yes, setting the DL and DH to match the SL and SH of the other node puts the radio in Unicast mode instead of Broadcast mode. IE, it says only this module with this matching 64 bit address to output the data on its UART.
Thank you, just skimming over some of these topics in the manual has answered a lot of my questions.

One lingering question is about delaying the MCU after sending some data. The images I shared were with a delay of 10 ms. I found that going below 10 ms makes it so the receiver module does not receive anything, however if I remove my delay statement altogether it seems to stream better. Do you have any insight to this? Does inserting a delay cause the XBee to finish "packetising" the data, take a short break, and then begin making a new packet when the subsequent serial data is received?

Thanks again
Yes and No. The short delay does allow for the data to be broken up and transmitted.  But the needed delay for that to occur is based off of the RO parameter.

The longer delay in your case is allowing the radio the needed break to transmit the data and get the required responses back before it moves on to the next packet.