Re: [Discuss-gnuradio] rx_time tag after drop

[Meelis Nõmm]

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

I mean that in GnuRadio, in general, time is represented by a pair of values, t_0 (absolute time of the first sample) and the sample number or the Offset of the given sample i.e.
  Offset: 0              Source: gr uhd usrp source1     Key: rx_time   Value: {1480518095 0.75052}
  Offset: 17461752  Source: gr uhd usrp source1     Key: rx_time   Value: {1480518097 0.497203}

I will try to illustrate my previous question.

Lets assume that t_0 = 0.0. At first we receive 100 000 samples correctly. Then a UDP package with 500 samples is dropped by the UHD driver. Now the question is what will be the values in the inserted Tag:

a) Offset: 100 501   Key: rx_time   Value: {100 501 / F_sample} (timestamp taken from the received UDP package)

b) Offset: 100 001   Key: rx_time   Value: {100 501 / F_sample} (timestamp taken from the received UDP package)

In case of a) the original value pair t_0 + Offset gives the correct absolute time, but in reality less samples than the Offset value were received. In case of b) it does not, but the Offset reflects the actual number of samples received.

Sorry for dragging this topic for so long.

Meelis

On Mon, Dec 5, 2016 at 7:32 PM, Martin Braun <address@hidden> wrote:

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

>     <mailto:address@hiddenorg <mailto:address@hiddenorg>>

>     >         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@hiddenorg>
>     > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>     >
>
>
>     _______________________________________________
>     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