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 <martin.br...@ettus.com
> <mailto:martin.br...@ettus.com>> 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 <derek.ko...@ettus.com
> <mailto:derek.ko...@ettus.com>
> > <mailto:derek.ko...@ettus.com <mailto:derek.ko...@ettus.com>>> 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 <meelisn...@gmail.com
> <mailto:meelisn...@gmail.com>
> > <mailto:meelisn...@gmail.com <mailto:meelisn...@gmail.com>>>
> 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
> > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> <mailto:Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>>
> > 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
> > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
> >
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
