Re: [Discuss-gnuradio] Timeout problem using usrp_source.set_start_time()

[Nowlan, Sean]

Oh, for receiving you should use UHD stream commands. I've never done anything 
with this myself, but I think "set_command_time" in uhd_usrp_sink will help you.

http://files.ettus.com/uhd_docs/manual/html/sync.html#align-cordics-in-the-dsp

http://gnuradio.org/doc/doxygen/classuhd__usrp__source.html#a59558860e816995c0cbbc43a44523ab7

Sean



-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Andrew Senior
Sent: Tuesday, June 19, 2012 11:38 AM
To: Nick Foster
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Timeout problem using 
usrp_source.set_start_time()

Hi Nick,

thanks for replying. I'm a bit confused though: it's receiving data from the 
USRP with gr_uhd_usrp_source that's giving me trouble, not sending it with 
gr_uhd_usrp_sink.

Looking again at gr_uhd_usrp_source.cc I see that tags are added indicating the 
time of the received samples. I guess this would allow me to figure out where I 
am in the stream if it's started at some random time, but this is conceptually 
quite different to actually starting the stream at a defined time. Am I missing 
something else here?

Regards,

Andrew.

On 19/06/12 15:49, Nick Foster wrote:
> Andrew,
>
> There is a better way. If you look in gr_uhd_usrp_sink.cc, it's 
> expecting to see tags indicating start of burst ("tx_sob") and end of 
> burst ("tx_eob") as well as a transmit time ("tx_time"). To issue a 
> start of burst, for instance, use:
>
> add_item_tag(0, //stream ID
> nitems_written(0)+i, //absolute sample number to tag 
> pmt::pmt_string_to_symbol("tx_eob"), //tag name pmt::pmt_from_bool(1), 
> //set this true to indicate start of burst d_me //block src id );
>
> Similar syntax applies for marking the end of burst (use tx_eob 
> instead). To use the tx_time tag, use a pmt::pmt_from_tuple where the 
> bool is above. The tuple is (uint64_t, double) where the integer value 
> is seconds and the double value is fractional seconds.
>
> The block source ID d_me above is really just a convenience identifier 
> and one way to put it together is:
>
> std::stringstream id;
> id << name() << unique_id();
> d_me = pmt::pmt_string_to_symbol(id.str());
>
> It does sound a little complicated but it works well in practice. Feel 
> free to keep asking questions. The best reference is 
> gr_uhd_usrp_sink.cc, and you'll probably want to look at 
> gruel/src/include/gruel/pmt.h.
>
> --n
>
> On Tue, Jun 19, 2012 at 6:08 AM, Andrew Senior 
> <address@hidden <mailto:address@hidden>> wrote:
>
>     Hello all,
>
>     I've been trying to use the set_start_time() method of usrp_source
>     to start my USRP N210 streaming data at a known time. The USRP has
>     the GPSDO fitted and the time is set automatically from this, so I
>     can specify an absolute time for when I want streaming to begin.
>     I've done this successfully using UHD in C++ programs, but I
>     couldn't get it to work in GNURadio. For the record, I'm using
>     GNURadio 3.6.1 and UHD 3.4.2.
>
>     The problem seemed to be that despite calling set_start_time(),
>     streaming didn't start when it should, yet if I specified a start
>     time in the past, the program failed with an error as I'd expect, so
>     the start time seemed to be interpreted correctly.
>
>     Having studied gr_uhd_usrp_source.cc, I realised that the problem is
>     that the timeout for the first call to the recv() function in UHD is
>     very short so that if my start time is many seconds in the future,
>     the call times out and the block is done.
>
>     My question is: is this the intended behaviour and if so, how do I
>     avoid my flowgraph stopping before it's even started, so to speak? I
>     could delay starting the flowgraph until the time is sufficiently
>     close to the wanted start of streaming, but that sounds a bit risky.
>
>     I have made a small patch to gr_uhd_usrp_source.cc to automatically
>     set an initial receive timeout based on the device time when the
>     streaming command is issued and the wanted streaming start time.
>     Being new to GNURadio, I'm not sure if this is the right way to
>     solve the problem but I'm happy to share the patch if anyone thinks
>     it might be useful.
>
>     I would welcome any comments and suggestions on this.
>
>     Thanks,
>
>     Andrew.
>
>     _________________________________________________
>     Discuss-gnuradio mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
>

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio