Re: [Discuss-gnuradio] rx_time tag after drop

[Derek Kozel]

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