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 03:15 PM, LD Zhang wrote:
> Hi Josh,
> 
> Thanks for replying. I have some thoughts on using the "set_start_time".
> Please see my comments and questions  below:
> 
> =========================================================
> 
> There is a set_start_time() call. setting this will effect what time the
> streaming begins when the flow graph starts
> 
>>>>
> Once the set_time_now command is performed. I consider the USRP have the
> same (or approximately the same) time as the host computer, correct?
> 
> The set_start_time() call looks nice, but it requires a time passed to it. I
> currently don't know how to dynamically call the set_start_time() command
> with a variable of system time in hour:min:sec.microsecond format. I found a

You pass it a uhd.time_spec. SInce you are using the PC's time, there is
already something you may find convenient: uhd.time_spec.get_system_time()

http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html#a28bb1e25ad03f333078bea59d21b4854

> discussion a while ago on some problems with the set_start_time. Someone was
> complaining that the time-out window in the cpp code is too short so a
> future scheduled time did not work.

The timeout in the current implementation of uhd usrp source is no more.
The work function just keeps going, samples or no samples.

> 
> Thinking about what I need to achieve, the set_start_time command is
> certainly good to make to work. But maybe I have an easier task here. Since
> the time is already sync'd, and presuming that I can get the time tag of the
> first sample, it is OK if the start time is off a bit(as long as it doesn't
> jump around by more than 0.1 seconds each time I perform the same function),
> all I need is to know the time of the start sample referenced to the host
> system time. So I say all I need right now is to get the time tag of the
> beginning sample and that would suffice, just to make it easier.
> 
>>>>
> 
> Also, as an alternative, there is access to the issue_stream_cmd(). You can
> leave the flow graph running and issue commands to turn streaming on and
> off, schedule bursts, etc...
> 
>>>>
> I will try to make the previous approach to work before I mess with this
> one.
> 
> LD
>