Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?

[Josh Blum]

On 01/04/2013 01:55 AM, LD Zhang wrote:
> Hello,
> 
>  
> 
> Thanks for the note below. 
> 
>  
> 
> I am reading an older email exchange between Josh Blum and a guest. Josh
> mentioned that there is a downstream block (in GRC I guess) that can use the
> timestamp tag to decide which samples are to be stored. Also there appears
> to be metadata utility to use. Maybe these magic functions such as stream
> tags (or) and get_time_last_pps to get the job done. So far I have used none
> of these utilities. My goal here is trying to avoid using the PPS if
> possible. Since the data gathering is done infrequently, I tend to think
> that the PPS can be avoided. I am trying not to use the PPS at least for
> this phase of the development. Yes for the next phase with enhanced
> capabilities, the external reference need will resurrect again. But it is
> better not to use the PPS right now, unless I am wrong here and need
> re-education of the USRP. The mimo cable is not an option since the 2 units
> are not co-located.
> 

If you want to use the PC clock, I recommend calling set time now with
the current PC time before scheduling streaming. This will make the USRP
tick counter roughly match the PC clock.

python:
usrp_source.set_time_now(uhd.time_spec_t(time.time())

c++
usrp_source->set_time_now(uhd::time_spec_t(secs, micros, long(1e6));

This way, your only time-ambiguity is the variance in ethernet control
packets and the difference in time between the different PCs. That
should satisfy referenced to PC's time anyway...

--------------------------------------

The next step would be to schedule when a stream begins for each device
so they send RX samples to the host at the "same time" (according to the
USRP anyway).

I think the USRP source block supports setting the time, and streaming
at a specific time, but there isnt a way to do this at the GRC level. So
you might need some hand coded python added to the generated flowgraph,
if you are using GRC.


> 
> So is it possible to do the downstream block and metadata stream tags in GRC
> (currently using UHD source block and file sink block)?
> 
>  

The file sink does not save metadata, but I suspect you dont need to
save the metadata if you presumably have asked the devices to stream at
the same time.

-josh

> 
> Thanks very much,
> 
>  
> 
> LD
> 
>  
> 
> From: John Malsbury [mailto:address@hidden 
> Sent: Thursday, January 03, 2013 11:24 PM
> To: LD Zhang
> Cc: address@hidden
> Subject: Re: [Discuss-gnuradio] How do I capture of the time of USRP N210
> samples with host computer system time?
> 
>  
> 
> You can get the synchronize two USRPs with an external reference or a USRP
> MIMO <https://www.ettus.com/product/details/MIMO-CBL>  cable, and specifying
> the time to start streaming for both.
> 
> -John
> 
> 
> 
> 
> On Thu, Jan 3, 2013 at 11:18 PM, LD Zhang <address@hidden> wrote:
> 
> Hi Folks,
> 
>  
> 
> We are testing 2 USRP N210 units with data gathering (using GRC source and
> file sink). The command from the host to the N210 is sent at the
> approximately simultaneous time (referenced to system NTP time). However,
> the samples gathered from the 2 units appear to differ by as much as 0.4-0.5
> seconds! The intention is to gather data at the 2 units at approximately the
> same time as the pre-programmed system time commands. The gathering is done
> with the top_block.py code generated from GRC. What happens inside the USRP
> appears to be beyond my control here. So the natural thing to do here is to
> time-stamp the samples with host computer system time. I hope that we don't
> have to use an external reference for the USRP. Isn't there an internal USRP
> clock that is continuously counting. If we can get the USRP clock counts to
> tie together the samples counts and the host computer system time, we would
> be in good shape. Is this a good idea? 
> 
>  
> 
> Your thoughts and help are appreciated.
> 
>  
> 
> LD Zhang
> 
> 
> _______________________________________________
> 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
>