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 > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
