Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: RF Timing



Richard:

The “push out” of the radio data at the presentation time is a timing event that affects the PLL that  regenerates the radio’s clock.  This PLL will have a LPF to average out the jitter of these “push out” events.

 

Rich

 

From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On Behalf Of Richard Maiden
Sent: Wednesday, April 13, 2016 3:58 PM
To: stds-1904-3-tf@xxxxxxxx
Subject: RF Timing

 

Hi all,

 

Please find a short presentation attached where I try to frame the requirements from an RF perspective. Ultimately I’d argue that the only thing that matters is that the appropriate sample is put on the air at the appropriate time. The block which determines this is the egress buffer (FIFO) in the radio. This FIFO has 2 controls on the egress side, clock and read address. There are so many ways to generate these signals that I think this topic is out of scope for 1904.3. We just need to make sure that we do not do anything to box ourselves in with the packet definitions which preclude any particular mechanism.

 

Kevin brings up a good point with the accuracy of our timestamp field. The granularity of its accuracy means that if it is regularly used (rather than a one-time start mechanism), it will be tricky to ensure that we don’t introduce jitter every time we receive a timestamp. Effectively we’d have a moving time-quantization error. For LTE 20MHz for example, we have 30.72MSps for each AxC or 32.5520833333’ns per sample interval. Right now our timestamp granularity is 0.25ns. If we perform a one-time timestamp, we’ll have some quantization error on when we actually send but that would not be a problem. However, on the next presentation time timestamp, we will likely have a different quantization error and so we will in effect jump forwards or backwards in time on when we actually transmit that sample – that’s a problem. Adding more granularity (fractional bits) would reduce this error but I’m not sure how far we’d have to go.

 

Thanks,

 

Richard

 

 

Richard Maiden

ALTERA (an Intel Company)

101 Innovation Drive

San Jose, CA 95134

 

Tel:  +1 (949) 382-5402