Re: [Discuss-gnuradio] rx_time tag after drop

[Meelis Nõmm]

To answer Derek's question that output was generated using    UHD_003.011.000.git-95-g811444b1

We have a feeling that the development machine has some network issues, as it also keeps giving UHD connection failures after fast application restart.

> 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.

This could also explain why the rx_time tags are messed up, given the UDP packages "arrive" in the wrong order. 

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)?   

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?

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> 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>> 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@hiddenorg>
>         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
>


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio