discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Question about metadata filesink


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Question about metadata filesink
Date: Wed, 10 Jul 2019 17:49:22 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 07/10/2019 04:45 PM, Derek Kozel wrote:
Hi Ellie!

The USRP has an internal time register which starts counting up from 0
when the power is applied. You can use the external 1 PPS input and the
set_time_next_pps command to snap that register into alignment with
UTC/TAI as long as you have a GPSDO or similar that outputs a 1PPS signal.

If you don't have a GPSDO then the timing will be arbitrary and
un-related to any global timestamping. You can roughly align it to your
PC's time as long as +- ~1 second accuracy is ok.

Checkout the documentation and code samples here.
https://files.ettus.com/manual/page_sync.html

Now, all of these methods require modifying the generated Python to add
in the commands to do the synchronization. Ettus Research used to
include some functions in GNU Radio Companion to do this synchronization
but there are some issues with handling situations where the GPSDO is
not locked or the 1PPS or 10 MHz signals are not present that led to
them being removed in favor of more documentation.

The timing resolution of the UHD time stamps is very very fine. I can't
remember it right now but it's good to over 10s of Giga samples/second
if I remember correctly. The fundamental timestamp is an unsigned
integer counter that increments at the master clock rate (the same as
the sample rate on the USRP1). The host computer then converts that into
time by doing counter_value*master_clock_rate_period_in_seconds =
time_in_seconds. There's going to be some floating point errors in doing
that so there's noise in the timestamps, but it's far far below the
clock rate of the USRP so rounding it to integer multiples of the clock
period is always valid.

Regards,
Derek

There's still a "sync" field in the UHD Source in UHD 3.13 with GR 3.7.13 -- but I think it just uses the PC clock regardless. However, if your PC clock is setup with NTP, things should be reasonably close--I think better than the +/- 1second that Derek mentioned.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]