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 <a.senior@lancaster.ac.uk
> <mailto:a.senior@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 <mailto: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
No comments:
Post a Comment