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 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. 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
