RF Transmit and Receive Timings

I went through a similar exercise trying to mux 4 units while streaming data (i.e. ABCD ABCD ABCD ABCD...).   I finally hung 4 o-scope channels on the 4 units monitoring GPIO pins, and used RF Rx interrupt flags to toggle the GPIO bits upon receive where I saw the same variability.  I’ll try to find and post the data. 

I believe it is due to the digital correlators in the Rx demodulator.  Upon receive the position of the correlation data is random in the Rx demodulator when compared to the Rx data.  If you are lucky and are a few bits early, within a couple of clocks the data will be decremented and there will be a match in the matched filter.  If you are several bits late then the filter word will have to be decremented many times before there is a match, couple in a corrupted packet and the additional re-tries in the demodulator, the time can be very long.  I found it to be a trade of decreasing the number of header bytes to reduce the worst / best time delta while also trying to minimize the number of retries within the demodulators ( not retries between units).  

While each round (ABCD) is only 125us, it appears to be many multiples of the correlation periods precluding me from trying to stay in sync with it to always have a short period. The larger the multiple, the larger the resulting error even if each error is small.

Extracting RSSI and other extra bits from the header also helped reduce the sync time variation.  These items can be added to the payload data but will then not be part of the filter. With my data I can afford to drop a few packets or even have a false packet get through without impacting system performance so it works…. In short if sync does not happen in a predetermined window (12us), I cut it off and use the data from the last transmission and wait till the next units turn.

CC2510 Data Sheet

13.8.5 Packet Handling in Receive Mode

In receive mode, the demodulator and packet

handler will search for a valid preamble and

the sync word. When found, the demodulator

has obtained both bit and byte synchronism

and will receive the first payload byte.

Thanks for your explanation.  That might explain some of the behaviour I've experienced.

After starting TIMER1 upon Node A transmit, I tried stopping the timer progressively at different stages in the code.  Up until before strobing SRX(), the timings are dead on, with no variation at all.  After SRX(), however, is when I see the variations occur.

I also shaved off ALL the header bytes to the minimum, sending only 2bytes preamble (16/16 bit correctness), 2bytes sync and 2bytes data.  No LQI, no CRC checksum etc.  Even then, the timings fluctuated by more or less the same amount.

If you have data that shows these timing irregularities, that would be great.  It'll help us make a decision on whether to use cc2510 for our purposes.  I'll try and collect some so we can compare results =).

Hi SIMTech,

I was wondering if you overcome your problems with accurate timings using the cc2510? I am trying to develop a similar application at present and having this timing issues as you discussed regarding the moment you enter RX(). apprecaite if you have any information as to how you overcame this problem?

regards,

Sean