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

[Nick Foster]

Hey, I'm losing my mind, apparently. Sorry about the confusion. I was recently hacking on timed TX and my brain apparently read source as sink.

The easiest way to get around it is to schedule your receive thread to start sometime less than 1 second before your set_start_time() call expires. This will keep recv() from timing out.

--n

On Tue, Jun 19, 2012 at 8:37 AM, Andrew Senior <address@hidden> wrote:

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@hiddenuk>> 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@hiddenorg>
   https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
   <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>