The time stamp resolution (or time stamp timebase) is always the master clock rate. On X310, unless you tell it something else, that's 200MHz.
Let's craft an example: Let's say you receive 2000 samples contiguously, at 100 samples per packet (that's 20 packets total). Let's say that the 0-th packet has timestamp t_0, and the 10-th packet has timestamp t_1, so that t_1 = t_0 + 1000/200MHz. Also assume the DDC is decimating by 10. (Note the packet sizes are not realistic, but let me do easy math here). The output of the DDC will produce 2 packets. The first packet will be timestamped t_0, and the second packet will be timestamped t_1. The first output packet will approximately hold the content from the first 10 input packets, and the second output packet will approximately hold the content of the 11-20th input packet. However, the timestamping etc. does not account for any group delays. Like Marcus says, we have filters for anti-aliasing. We have half-band filters with 47 taps (so, 23 samples group delay) and CIC filters with variable decimation (I don't know the group delay of the top off my head). When you decimate, the visible group delay gets reduced of course by the decimation. But let's say you're decimating by 4, then that means you have 2 half-bands and a decimation of four, that will give you approx. 23 samples delay. (I always embarrass myself when doing math on the fly, so don't believe the exact numbers without doing the math yourself). It would be possible to also adjust timestamps. In GNU Radio, we have the "declare_sample_delay()" API which helps moving stream tags to the right position. However, there's no "correct" answer here if we really should modify timestamps, so we go with the simplest solution and don't. Side note: If you run the capture at full rate (200Msps) then this will not occur. However, there may still be some fixed, residual delay. This is something that the application needs to handle appropriately. --M On Wed, Mar 26, 2025 at 6:57 PM Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > > > On Wed, Mar 26, 2025 at 12:32 PM Marcus D. Leech <patchvonbr...@gmail.com> > wrote: > >> On 26/03/2025 12:09, Rob Kossler wrote: >> >> >> >> >> Hi Marcus, >> I think that the gain is set from the "radio" block which operates at the >> master clock rate rather than the downconverted rate. It doesn't make >> sense to me why the latency of the gain setting would be related to the >> downconverted sample rate. >> Rob >> >> >> Let us ignore for a moment the gain-setting hardware on the radio. Let's >> pretend that some noticeable signal parameter, >> as seen at the antenna plane, changes suddenly--like the signal level >> comes up by 5dB. How long before that effect is >> actually seen in the sample stream? That will depend on the (very >> small) group delay in the analog hardware, and the delay >> in the DDC filters, which DOES scale with sample-rate, because >> different filters are switched-in depending on the commanded >> sample rate, and those filters have non-zero length... >> >> True. But if the comparison is between the gain setting time stamp and > the Rx samples time stamp (inserted at the radio) it still seems that it > would be sample rate independent (with the caveat that the time stamp > resolution may have to change to the decimated sample rate with some type > of quantization) > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
