> > 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? 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? 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? 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> 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 > > Thanks, > Derek > > On Thu, Dec 1, 2016 at 1:42 AM, Meelis Nõmm <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 >> >> _______________________________________________ >> 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
