Re: [Discuss-gnuradio] rx_time tag after drop

[Martin Braun]

On 12/05/2016 04:24 AM, Meelis Nõmm wrote:
> Now to what Martin told
> 
>     > 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.
> 
> By " N samples ", do you mean Offset_{t_1} - Offset_{t_0} (the offset
> difference between 2 tags)?   

The offset difference dictates how many samples there *should* be (if
nothing was dropped). Subtract the number of samples you actually
received from that, and you have the number of dropped samples.

> I guess this leads to the core question. What does the offset show?
> 1. sample number related to the GnuRadio stream or
> 2. sample number related to the USRP stream?

There is no offset. The tag is the absolute time of the sample
(rx_time). Ore are we speaking about different things?

Cheers,
Martin

> In case of 1. offset knows nothing of dropped samples and in case of 2.
> it takes them into account.
> 
> Things are starting to clear up
> Meelis
> 
> 
> 
> On Sat, Dec 3, 2016 at 2:05 AM, Martin Braun <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     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>
>     > <mailto: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>
>     >     <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>
>     >     <mailto: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 <tel:1480518095%200>.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>
>     >       
>      
> <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>
>     <mailto:address@hidden <mailto:address@hidden>>
>     >         https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>     >         <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > 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 <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
>