discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Async Messages for Tx Timestamps


From: Josh Blum
Subject: Re: [Discuss-gnuradio] Async Messages for Tx Timestamps
Date: Mon, 08 Apr 2013 18:40:08 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4

> Gnuradio end-of-burst tags will signal UHD firmware to bring down the TX
> chain. The tag gets converted into a flag in a metadata struct. This
> struct is sent with an 1-sample buffer of samples when send(...) is
> called in gr_uhd_usrp_sink. (See line  376 and thereabouts here:
> http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/lib/gr_uhd_usrp_sink.cc).
> 

A little background here: Jordan has a use case that requires continuous
generation of some sort of baseband carrier, which needs to be present
with or without actual data to send.

The challenge is to continually send data, but to not to the extent that
it backs up the pipeline completely full of empty carrier. The transmit
DUC in the usrp pulls samples out at a fixed rate, so waiting on the
pipeline to drain 100% before getting useful data transmitted can be
quite a long wait.

1) The solution is to implement some sort of point-to-point flow control
between the source block and the TX DUC in the USRP. Now something like
this actually happens to exist which is used internally in UHD to
implement transmit flow control. However, it reports consumed sequence
numbers of packets, which isnt useful to the source block because its
cant translate between items produced and packet counts over the ethernet.

2) Now we could make it work. This one liner could enable the async
messages for the usrp2 tx flow control back to the user api.
http://pastebin.com/1nsmMUPu

And this one liner could enforce fixed length packets, so you could
easily relate samples produced to packet sequence numbers consumed:
http://pastebin.com/fig7YeSf

3) So aside from that, I was also thinking of another way to do a sort
of point to point flow control, but using the rx timestamps as the async
reporting. By transmitting samples at a known time, and using a receiver
stream and its timestamps to judge when a certain window of samples had
been consumed by the DUC chain.

4) Or another way, depending upon the tolerance to variability, one
could also forgo the RX timestamps and poll the get_time_now call on the
sink block periodically to establish the same concept of time window.

Thoughts?

-josh

> 
>> Thanks!
>> Jordan
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> Hope this helps!
> 
> --sean
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



reply via email to

[Prev in Thread] Current Thread [Next in Thread]