Hi Nick,
thanks for your help, I'll give that a try.
Regards,
Andrew.
On 19 Jun 2012, at 18:15, Nick Foster wrote:
> 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 <a.sen...@lancaster.ac.uk>
> 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 <a.sen...@lancaster.ac.uk
> <mailto: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 <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
