Need to understand TX to RX time jitter and offset.

Other Parts Discussed in Thread: CC1310, CC1120

Hi
I am trying to implement clock synchronization using either CC1120 (my existing board) or CC1310 launchpad.
I am running them at 915 MHz in proprietary mode.
I did read "Time synchronization over the air" article on TI site and several prior posts here.
In one post I see "sync word correlation and everything else might be off by 1/4 symbol. At 500 kBd this is 500 ns."

I am measuring jitter and offset using GPIO configured to reflect sync words.

Offset is the time difference between TX edge and RX edge and jitter is a variation of this offset.
On CC1120 I am using PKT_SYNC_RXTX. On CC1120: RATGPO0 for TX and RATGPO1 for RX.

When I run CC1120 at 50 ksps I see offsets of about 120 us (rising edge) and 150 us (falling edge) and jitter up to 6 or sometimes 7 us.
CC1120 at 100 ksps: offsets about 60 and 75, jitter up to 3 us.
CC1310 50 kbaud: offsets: rising edge: 1.7 ms, falling edge: 347 us, Jitter: up to 6 us
CC1310 500 kbaud: offsets: rising edge: 180 us, jitter: 0.6 us, falling edge: offset 70 us, jitter: about 1.1 us

So, the jitter amount roughly matches the expected 1/4 symbol.

I need to better understand the nature of that jitter and offset in order to make proper filters.

Here are my questions:
1. It is possible to reduce jitter without rising baud rate?
In particular, CC1120 has "Bit Synchronization" and "Byte Synchronization, Sync Word Detection" sections,
which mention TOC_LIMIT, SYNC_THR and other settings.
How these settings may affect jitter?
What about CC1310 settings?

2. What is the nature of the offset? it is several dozens or even hundreds of microseconds.
Is this large offset constant for a particular settings?
Can I hard code it in the code? Or will it change depending on some conditions?
Can it be different between chip reboots?

3. It appears that jitter is not completely random, but sometimes the offset have some trends,
for example its multisecond average may drift up for few seconds, then fall for few seconds,
which makes clock synchronization difficult.
How this may be explained and mitigated?
What would be the best filter to cancel jitter and recover clock?

Thank you

over 5 years ago

0 Alexis Crandall20 over 5 years ago

TI__Genius 15590 points

Hi LD,

I have forwarded your question to the SMA. He will get back to you ASAP.

Thanks,

Alexis

0 Siri over 5 years ago in reply to Alexis Crandall20

TI__Guru* 86301 points

1) We have not characterized this jitter on any of our devices, and we do not have any settings you can/should play around with to try to minimize this jitter.

2) The offset is implementation specific, and parts of the offset might be a constant while part of it might be data rate dependent.

For a given set of RF parameters, the offset should not vary significantly.

3) Unfortunately we do not have any settings etc. that can remove this jitter, and we have not done any characterization of it, so it is not possible to state anything about how it will drift/vary.

I guess my only recommendation is that you need to add margins based on testing (the offset should be pretty stable, and then you need to take the jitter into account) when implementing a synchronous protocol, and then you also need to implement re-syncing if/when the TX and RX loose sync.

I am sorry that I could not give you a more detailed answer.

Siri

0 LD over 5 years ago in reply to Siri

Prodigy 80 points

Could you, at least, tell more about this statement:
"The demodulator output is oversampled 4x the symbol rate before estimation. That means, sync word correlation and everything else might be off by 1/4 symbol."

Do I understand correctly, that there are 4 RX timer slots within duration of a sync symbol?
And GPIO output will be triggered at one of those timer slots?
Is it possible to tell which of these timer slots is more likely to trigger GPIO?
Suppose that RX and TX clocks are perfectly in sync and these 4 slots are perfectly aligned within the sync symbol,
suppose there is no noise, can we assume that GPIO will be triggered at the first slot?
What if the first part of sync symbol is corrupted by noise, could it be the second, third or fourth timer slot that will trigger GPIO in this case?

Thank you

0 Siri over 5 years ago in reply to LD

TI__Guru* 86301 points

I have talked to our design team, and afraid there is not an easy answer to your question.

What I know is that there is an «RX Timer» that does 4 times oversampling and this is used when correlating the sync word to the received signal. This RX Timer is however, not synced to the received signal. The signal routed out on the pin, for sync found, is samples with a 4 MHz clock (RAT) which again is independent of the RX Timer that does the oversampling, giving additional 0.25 us jitter.

The TX start is only controlled by the RAT and should be accurate down to 1 RAT tick (0.25 us).

Unfortunately I cannot give you more details/explanation than this.

Siri

0 LD over 5 years ago in reply to Siri

Prodigy 80 points

Hi,

Does this information about 4 MHz RAT clock applies to CC1120 as well as CC1310?

Thank you

0 Siri over 5 years ago in reply to LD

TI__Guru* 86301 points

No, this was for the CC1310.

I have not been able to dig up so much info about these things on the CC1120 since it is an older device.

What I do not is that we have not done any characterization of this (hence no data sheet numbers), and we have no registers to tweak on to improve this. There might be settings that you can change that also will change the jitter, but then you would probably affect some other RF parameters, so we recommend that you stick to the recommended settings in SmartRF Studio.

Siri

Sub-1 GHz

Sub-1 GHz forum

Need to understand TX to RX time jitter and offset.