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

[Jordan Otomo]

Hi Josh and Sean,

Thanks for your replies.  Sorry for the confusion.  As Josh mentioned, my 
application is packet based, but a carrier signal is sent when packets aren't 
being transmitted.

Josh, I like your second solution.  At what point are the control messages 
generated?  Are they generated as the samples are consumed by the DUC?

I'm currently using your tx_pacer idea to ensure that the block buffers 
(gr_vmcircbuf), network buffer, and SRAM never fill completely.  This gives me 
a fairly good idea about when packets are being generated and has greatly 
reduced transmit latency.  However, I'd like to have more precise info about 
when the USRP is actually radiating the samples.

I will try your suggestion and let you know how it works out.  Thanks again for 
your help!

Jordan

On Apr 8, 2013, at 4:40 PM, Josh Blum wrote:

> 
>> 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
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio