Re: [Discuss-gnuradio] rx_time tag after drop

[Martin Braun]

On 12/02/2016 05:08 AM, Meelis Nõmm wrote:
>     Since dropped samples never enter GNU Radio the behavior is correct. 
> 
> I see, before I thought the samples are dropped inside the Gnuradio
> framework.
> 
> That raises a few questions for me that are unclear
> 1. Does the UHD driver drop a full UDP package?

When you see a D, UHD didn't actually drop the packet itself. It's
telling you that it didn't get a packet it was expecting. And yes, it's
always full packets that get lost this way.

> 2. After a drop (D), does the UHD source (PC side) take the rx_time from
> the next UDP package and that is inserted to the tag?

Yes.

> 3. I would expect that the offset is incremented by the number of
> dropped samples. So that the combination of t_0 and offset still
> provides valid current sample time. The difference between the sum of
> noutput_items and offset will give the number of dropped samples?

If you have two tags, and in between, N samples, the number of dropped
samples is (t_1 - t_0) * f_s - N.

Cheers,
Martin

> Can't tell the exact UHD version, as my colleague is out of office
> today. But we used N210, during that example test we did not change the
> sample rate during runtime.
> 
> Can tell more on Monday,
> Meelis
> 
> On Thu, Dec 1, 2016 at 10:05 PM, Derek Kozel <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     Hello Meelis,
> 
>     My understanding is that the offset is the index of the sample
>     within GNU Radio which the tag is attached to. Since dropped samples
>     never enter GNU Radio the behavior is correct. The rx_time is one of
>     the few tags where this behavior is potentially confusing since the
>     rx_time is a concept based entirely outside of the host computer. It
>     is possible to calculate the number of dropped samples using the
>     rx_time tags and the total number of samples correctly received
>     between the tags, as long as the rx_time tags are correct.
> 
>     What version of UHD are you running? What USRP are you connected to?
>     Are you setting or changing the sample rate after starting the
>     flowgraph? Would you be able to try using the latest UHD maint code?
>     https://github.com/EttusResearch/uhd/tree/maint
>     <https://github.com/EttusResearch/uhd/tree/maint>
> 
>     Thanks,
>     Derek
> 
>     On Thu, Dec 1, 2016 at 1:42 AM, Meelis Nõmm <address@hidden
>     <mailto:address@hidden>> wrote:
> 
>         Hello everyone
> 
>         We have been wondering about rx_time tags after drop. In [1] it
>         is stated that "Then, if a dropped
>         packet or overflow are detected, it sends a new rx_time tag."
> 
>         The tag debugger output is shown below.
>         Initially we thought that in the tag the time and the offset are
>         bound together. Instead seems that this is true only for the
>         first tag. Meaning, the offset is always bound to the initial
>         rx_time, as one can see from the example printout. Both the
>         offset and the time increase (sampling rate is 10e6).
> 
>         Actually, now that I look at them the rx_time values are messed
>         up, they are not even monotonically increasing (the timestamp in
>         the second tag is "newer" than in the third). So what does the
>         rx_time in the tag after drop represent?
> 
>         In any case, isn't this a bit counter intuitive? I know we fell
>         for it at first. There might be more places in the code that
>         mishandle the rx_time tags after drops. I understand that drops
>         should be avoided, but still I think it is crucial that they are
>         correctly handled.
> 
>         ---------------------------------------------------------------------
> 
>         Tag Debug:
>         Input Stream: 00
>           Offset: 0  Source: gr uhd usrp source1     Key: rx_time  
>         Value: {1480518095 0.75052}
>           Offset: 0  Source: gr uhd usrp source1     Key: rx_rate  
>         Value: 1e+07
>           Offset: 0  Source: gr uhd usrp source1     Key: rx_freq  
>         Value: 1.56e+08
>         ----------------------------------------------------------------------
> 
>         D
>         ----------------------------------------------------------------------
> 
>         Tag Debug:
>         Input Stream: 00
>           Offset: 17461752  Source: gr uhd usrp source1     Key: rx_time
>         Value: {1480518097 0.497203}
>           Offset: 17461752  Source: gr uhd usrp source1     Key: rx_rate
>         Value: 1e+07
>           Offset: 17461752  Source: gr uhd usrp source1     Key: rx_freq
>         Value: 1.56e+08
>         ----------------------------------------------------------------------
> 
>         D
>         ----------------------------------------------------------------------
> 
>         Tag Debug:
>         Input Stream: 00
>           Offset: 17471916  Source: gr uhd usrp source1     Key: rx_time
>         Value: {1480518097 0.496695}
>           Offset: 17471916  Source: gr uhd usrp source1     Key: rx_rate
>         Value: 1e+07
>           Offset: 17471916  Source: gr uhd usrp source1     Key: rx_freq
>         Value: 1.56e+08
>         ----------------------------------------------------------------------
> 
>         D
>         ----------------------------------------------------------------------
> 
>         Tag Debug:
>         Input Stream: 00
>           Offset: 17476998  Source: gr uhd usrp source1     Key: rx_time
>         Value: {1480518097 0.498219}
>           Offset: 17476998  Source: gr uhd usrp source1     Key: rx_rate
>         Value: 1e+07
>           Offset: 17476998  Source: gr uhd usrp source1     Key: rx_freq
>         Value: 1.56e+08
>         ----------------------------------------------------------------------
> 
> 
>         With regards
>         Meelis
> 
>         [1]
>         
> http://gnuradio.4.n7.nabble.com/How-to-get-multipe-rx-time-tags-while-receiving-continuously-tt44492.html#a44515
>         
> <http://gnuradio.4.n7.nabble.com/How-to-get-multipe-rx-time-tags-while-receiving-continuously-tt44492.html#a44515>
> 
>         _______________________________________________
>         Discuss-gnuradio mailing list
>         address@hidden <mailto:address@hidden>
>         https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>         <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
> 
> 
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>