[Top][All Lists]

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

Re: [Discuss-gnuradio] Question about metadata filesink

From: Derek Kozel
Subject: Re: [Discuss-gnuradio] Question about metadata filesink
Date: Wed, 10 Jul 2019 21:45:26 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

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.

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.


On 10/07/2019 21:19, Ellie White wrote:
> Hi Marcus,
> Thanks for getting back to me! I really appreciate your suggestion --
> why didn't I think of that! I have done similar calculations before to
> determine the amount of time from the beginning of a run, but for a
> much less precise application.
> This brings me to another question, though -- I notice that when I
> read the metadata header, the time ("Seconds" field) always says zero
> when I get the file from the TCP client flowgraph, but when I save a
> metadata header file on the machine that the Ettus is connected to, it
> gives me some fractional answer (always different, never zero). Not
> sure why that is, or what time standard the UHD is using (this is the
> one I have, by the way:
> https://files.ettus.com/manual/page_usrp1.html)? Maybe the Ettus just
> needs to be connected to an external clock source -- the final system
> will have a 10 MHz clock source connected, but the temporary system
> that is set up now doesn't have an external clock. If you have any
> thoughts on this, I would be interested to hear them.
> Thanks again, and have a good afternoon!
> Best,
> Ellie
> On Wed, Jul 10, 2019 at 3:07 PM Marcus D Leech <address@hidden> wrote:
>> The thing to note is that the UHD sends a time stamp only on start of 
>> streaming and whenever there’s an overrun.
>> You can know the time of any given sample by knowing the sample rate and 
>> offset from the beginning.
>> In your case you will have to throw in some more factors to account for FFT 
>> size and decimation etc.
>> More later when I get to a real computer.
>> Sent from my iPhone
>>> On Jul 10, 2019, at 2:54 PM, Ellie White <address@hidden> wrote:
>>> Hello!
>>> I am working on a radio astronomy project with the Green Bank
>>> Observatory / NRAO Central Development Lab this summer, utilizing GNU
>>> Radio and an Ettus Research SDR, and I've got a question regarding how
>>> to collect metadata information from a filesink.
>>> I have attached the flowgraph I am using to this email. The project
>>> requires that I use two computers in tandem for data collection -- one
>>> is connected to the Ettus -- it is the TCP server, and sends an
>>> interleaved data stream to the TCP client flowgraph (attached) on the
>>> machine which will be storing the data. As you can see, I am saving
>>> integrated spectra to a file. My question is simply, how do I retrieve
>>> a time stamp corresponding to each spectra using the metadata time
>>> sink? I have been fiddling with this all afternoon attempting to get
>>> it to work properly, and I have been able to save data to a file, read
>>> out spectra (using attached Python program), and display header
>>> information using the command gr_read_file_metadata in the terminal,
>>> but this is just showing me a timestamp for the beginning of the data
>>> collection run, rather than showing me timestamps for each spectrum
>>> which is saved to file, and I am not sure how to implement this.
>>> Any advice would be much appreciated! If I can provide any more info
>>> about my system or what steps I have tried, please let me know. Thank
>>> you so much for your time -- have a good afternoon!
>>> Best,
>>> Ellie
>>> <ettus-filesink.grc>
>>> <dataGraphing.py>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

reply via email to

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