Re: [Discuss-gnuradio] Using USRP Clock for Timers

[Marcus Müller]

Hi Devin,

On 09.06.2016 15:27, devin kelly wrote:
> A different approach makes sense.  What I need this for is doing some
> book keeping when certain frame/slots occur.
This sounds a lot like you should be doing this based on when a certain
sample flies by – and not at a certain "CPU time".
> Since I have a TDMA system, I need to make sure the metadata (e.g.
> tx_time tag) I apply to my packets is in sync with the radio time.
Yes, and the nice thing is that these tags are all relative to device
time, so there's no need to get your CPU time in sync with that –
everything has to be calculated in relation to the USRPs clock!
>   Additionally, the receive time is important to me (for estimating
> time of flight - which I do by transmitting the tx_time in packet
> payload and subtracting it from rx_time).
That seems to be exactly that approach!
>   So given these two constraints I figured it would be easiest for me
> just to use one clock for everything.
>
> The other approaches I can think of are
>
> 1) Sync the PC clock (like I mentioned before)
Won't happen. This is like trying to sync your watch to that of your
friend at the other end of the world by asking him to send a letter
whenever it's 12 o'clock. The letter's jitter and latency is much worse
than you need.
> 2) Estimate the clock difference using something like
> get_time_last_pps() in a loop (like in new version of
> query_gpsdo_sensors) and pass around that offset.
Really, I don't see why your PC clock needs to be in sync to anything.
You can, from the RX time tags, determine when exactly something
happened on the air, in radio time.
What your communication system cares about is radio time, not CPU time,
so your TX time is also in radio time.

Best regards,
Marcus