Re: [Discuss-gnuradio] USRP tx_time tags and late packets

[Stephen Larew]

Answering “question” #1 that I asked below: it looks like I can use 
gr::uhd::amsg_source to get the UHD async_metadata_t.  I will experiment with 
that for now, but questions #2 and #3 still stand for me.

> On May 2, 2017, at 16:33, Stephen Larew <address@hidden> wrote:
> 
> I am having trouble with late packets at the USRP.  I am working on a TDD 
> system with GNU Radio and x310 radios.  I understand that I should use SOB 
> and EOB tags to delimit a packet and add the tx_time tag to control 
> transmission time.
> 
> Current approach: In the source block, I set the tx_time tag to a point that 
> is in the future relative to the host computer’s clock, which was 
> synchronized with the USRP at program startup.  The samples flow through the 
> graph and get to the usrp_sink block for transmission.  The latency in the 
> flowgraph seems to vary enough such that some packets are late (UHD prints 
> ‘L’) while other packets are not late.  I have set max_noutput_items when 
> calling top_block.run() to try to bound the latency, but with limited 
> improvements.
> 
> 1. In GNU Radio using stock usrp_sink, is there a method of getting the late 
> flag without having to monitor stdout and parse Ls? I recently read on 
> USRP-users that the proper way to detect late packets is to look at the 
> metadata returned from uhd’s send function. Does the usrp_sink block publish 
> this in some way?
> 
> 2. Any tips for doing *tightly timed* TDD in GNU Radio in general?  For 
> example, we are experimenting with a) setting tx_time at the source block 
> (requires predicting the flowgraph’s processing delays in order to not be 
> late at the USRP) and b) setting tx_time at a custom block just before the 
> usrp_sink so that most of the flowgraph processing delays are not a factor 
> when computing a tx_time.  What approaches have been taken by others?
> 
> 3. When or why would supplying a max_noutput_items to top_block.run() not be 
> passed on to or respected by blocks in a flow graph?  My colleague observed 
> that noutput_items given to work() was greater than what was given to 
> top_block.run().  Do tagged stream blocks change the scheduler behavior w.r.t 
> max_noutput_items?
> 
> -Stephen