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