Timestamps on RX samples are put in the CHDR Header by the Radio Core and are not changed by the DDC downstream, except for the case of interpolation / decimation. But even in this case, the remaining samples should still be repackaged with timestamps consistent with those given by the Radio Core.
Timestamps on TX samples are assigned on the host machine and compared against vita_time in the radio core before they are transmitted (in USRPs that support timed TX and RX). All of that said, the b2xx doesn't support timed operations that interface with the AD936x, including timed TX and RX. As I understand it the group delay on RX samples would be from Antenna -> AD936x > Radio Core, and this delay would be non-deterministic. No additional delay (from a CHDR timestamp perspective) is introduced downstream. Sam On Wed, Feb 5, 2020 at 4:05 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 02/04/2020 04:05 PM, YENDstudio . via USRP-users wrote: > > Hi Markus, > > Yes, I am using a timed-command. The loopback delay is about 50 samples. > Checking from the UHD API, I can see that there are three digital filters > (FIR_1,HB_1,2,3) enabled. The FIR filter alone has 128 taps, and the group > delay would exceed what I measured. I am now suspecting that the timestamps > are taken at the ADC/DAC rather than at the TX/RX controller (before DUC > and after DDC), or the group delay introduced by the digital filters has > been compensated. In this case, the loopback delay I measured only shows > only the Analog filters' delay which can be predicted. > > I will check AD9361's datasheet but I am still unsure of how the > timestamps are interpreted; whether the DUC/DDC filter delay is taken into > consideration. Otherwise, even while using a GPS PPS trigger, there would > be an offset between the start of the TX signal (measured at the antenna) > and the actual GPS time. Personally, it would make sense to compensate for > DDC/DUC delays by the UHD driver/firmware based on the selected digital > filters and the interpolation & decimation factors. > > > > My understanding is that timing on the B200 is referred to the host > transport stream, and NOT after the DUC/DDC filters. Which means that > for any given master-clock/host-sample-rate configuration, it would need > to be characterized by the end user. > > There have been improvements in this regard with other hardware (X3xx, for > example), but I'm about 70% certain that the timing on the > B200 is relative to the host transport as it enters/leaves the DSP chain. > > > >> >> >> ---------- Forwarded message ---------- >> From: "Marcus D. Leech" <patchvonbr...@gmail.com> >> To: usrp-users@lists.ettus.com >> Cc: >> Bcc: >> Date: Mon, 03 Feb 2020 12:40:48 -0500 >> Subject: Re: [USRP-users] USRP filter delay >> On 02/02/2020 04:40 AM, YENDstudio . via USRP-users wrote: >> > Hi, >> > >> > I want to know the actual timestamp of TX and RX signals at the RF >> > antenna. For this I have add/subtract the group delay introduced by >> > digital filters in the TX and the RX paths from the UHD timestamp. >> > Through loopback test, I am able to calculate the aggregate delay, but >> > cannot know the TX delay and the RX delay separately. The UHD driver >> > has APIs to get the list of filters used in the signal paths. But my >> > calculated values do not match with the loopback delay I measured. >> > Could someone help me with this? I am using USRPB200 set with 30.72 >> > MHz master clock rate and 1.92 MHz sampling rate. >> > >> > Regards! >> > >> > >> So, you use a timed transmit sequence, or you just note the time the >> samples left your application? Latency measured through the entire >> stack will be MUCH larger, and variable, than if measured using a >> timed-command transmit sequence. >> >> Quite apart from the analog delay that Nick has already mentioned, >> filter-delay will be "shared" between filters in the FPGA, and filters >> in the >> AD9361 chip--there's a kind of "shared" DSP going on there. The >> AD9361 datasheet might be a fruitful place to look at DUC/DDC filter >> latencies within the chip. >> >> >> > > _______________________________________________ > USRP-users mailing > listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
