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 <a.sen...@lancaster.ac.uk>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
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
