[USRP-users] How good can USRPs with internal GPSDOs being synchronized?

Josh Blum josh at ettus.com
Thu Sep 5 18:31:33 EDT 2013



On 09/04/2013 11:53 PM, Cheng Chi wrote:
> Hi josh,
> 
> {{{
>     stream_cmd.stream_now = false;
>     stream_cmd.time_spec = uhd::time_spec_t(time_to_receive);
>     usrp->issue_stream_cmd(stream_cmd);
> }}}
> 
> In this code, the time_to_receive is a double value. So I am using this
> function time_spec_t (double secs=0) to create the time_spec_t. Would it
> provide better accuracy if I use time_spec_t (time_t full_secs, double
> frac_secs=0) to specify frac_secs also?
> 

I guess you could say accuracy is a relative thing. Its really important
that the time to stream is exactly the same for all channels. But as far
as what that time is? I dont think it matters.

Basically, you just need to find a time that is "slightly in the
future". That means the time wont be late when the command is sent to
the USRP; and a time that isnt so far in the future you have to wait
forever. :-)

//this will make a time that is 100ms in the future
//but +/- some delta for communicating with the usrp
uhd::time_spec_t time_to_stream =
	usrp->get_time_now() + uhd::time_spec_t(0.1);
stream_cmd.time_spec = time_to_stream;

Use this time exactly for all USRPs in your experiment,
as in, dont call usrp->get_time_now() on each device, because then you
would come up with different random times for each USRP.

> So far, I haven't figured out how to use the time_t data type. Every time I
> compile, there is error "expected initializer before time_t". I try to find
> examples about how to use this time_t in uhd example directory, but can't
> find any. Do you have any example which uses the time_t data type?
> 

time_t should just be a typedef for an integer, so you can use it the
same as int for example. Comes from #include <ctime>. uhd::time_spec_t
happens to use it for representing seconds because other posix calls
also use it to represent seconds.

-josh




More information about the USRP-users mailing list