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