On 16/01/2024 12:10, Eugene Grayver wrote:
Hi,
There should be some delay, but it should be on the order of a few
clock cycles (ADC/DAC latency). For the N321 we are observing 100us,
corresponding to ~2000 samples. The X310 delay is ~1us, which
corresponds to 20 samples. Still a lot higher than I would expect
just due to ADC/DAC. The delay changes as a function of the sample
rate. If the synchronization is after the DDC (as I think it is), I
would expect the delay to be independent of the decimation ratio.
We are doing the calibration and will use that to compensate, but I
think this is something that can be mitigated (to <1us) in the FPGA.
Eugene.
I don't think the timed streaming has *ever* been at the DAC--DUC or
ADC--DDC interface. From what I understand, timestamps
have *always* been assigned (in the RX case) as samples come off the
DDC, and correspondingly for the other direction.
Different sample rates will necessarily determine the DDC filter depth
that is being used, and the rate that some of it is
clocked at.
Having things like timed-commands account for DUC/DDC group delays
requires that either host-side UHD have a more
intimate understanding of FPGA implementation details than it
currently has, OR, the FPGA needs some understanding.
Also, since the decision was made a LONG time ago as to at what "plane"
the timestamps apply, changing it "mid-stream"
would break a lot of existing code.
Now, having said all that, (A) I'm not an Ettus/NI R&D person, so I'm
just guessing about motivations for the architecture.
Also, 100usec seems like waaay longer than you'd expect just due to
DDC/DUC group delay, and I wonder if there's something
else going on, like subtleties about when you do time synchronization
and master-clock rate changes. I recall that there's
some "gotchas" there. Like if you clock-synch, and THEN change the
master clock rate, there can be some weirdness
because the increment quantum changes across master-clock rate
changes for the time-stamp clocks.
________________________
Eugene Grayver, Ph.D.
Aerospace Corp., Principal Engineer
Tel: 310.336.1274
________________________
------------------------------------------------------------------------
*From:* Rob Kossler <rkoss...@nd.edu>
*Sent:* Monday, January 15, 2024 5:05 PM
*To:* Eugene Grayver <eugene.gray...@aero.org>
*Cc:* usrp-users <usrp-users@lists.ettus.com>; Mark Kubiak
<mark.kub...@aero.org>; Jason W Zheng <jason.w.zh...@aero.org>
*Subject:* Re: [USRP-users] Bug/problem aligning PPS to samples
Hi Eugene,
Are you expecting that the RF output (for Tx case) should be synced to
the PPS "at the RF output connector"? It is my understanding that the
sync occurs at some place in the FPGA logic for the "radio" block.
There will be delay as this goes through D/A and RF chain. Same in
reverse for Rx. As long as you get a consistent delay (for a given
sample rate), can you calibrate and then choose a playout time that
syncs the RF pulse to the PPS pulse?
Rob
On Fri, Jan 12, 2024 at 4:38 PM Eugene Grayver
<eugene.gray...@aero.org> wrote:
Hello,
There appears to be a bug related to alignment of the PPS to
samples. The issue applies to both TX and RX and was replicated
on N321 and X310 using UDH 3.15 and 4.6. It therefore appears to
be an FPGA issue.
*TX experiment*
----------------------------
* USRP is provided with external PPS and 10 MHz
* The PPS input is split and goes to the USRP and a scope
* The USRP output goes to a scope
* USRP outputs a file
o
First 1000 samples are 1, remaining are zero
o File size = sample rate (i.e. repeats every second)
* Setup the experiment using both:
o GR file_source + usrp_sink
+ Sync to unknown PPS
+ usrp.set_start_time(5)
o Standalone C++ application (based on tx_samples_from_file)
+ Added code to set_time_unknown_pps(0), then set start
time using metadata to 5
Results:
* The USRP output is delayed relative to the PPS as observed on
the scope
* The delay is ~1.2 us for X310 and ~100us for N321
* The delay changes slightly (<1us) depending on the sample rate
(e.g. 10 Msps vs 20 Msps)
*RX experiment*
----------------------------
* USRP is provided with external PPS and 10 MHz
*
USRP input is a pulse (generated using technique above) that
repeats every second
o
Pulse is aligned to PPS, verified using a scope
*
USRP records samples starting on a second boundary (time_t(5))
o
GR usrp_source + file_sink
o
standalone C++ application (based on rx_samples_to_file)
+ Added code to set_time_unknown_pps(0), then set start
time using metadata to 5
*
Recorded samples are analyzed to find the first 'large' value
Results
* Recording appears to start late relative to PPS (only verified
on N321, delay is ~100 us, same as for the TX delay)
*Thoughts*
* I recall (years ago) there was a fix to a similar problem.
The FPGA was modified to trigger ADC/DAC samples after the DDC
rather than before. Did it regress at some point?
* The delays are very consistent, indicating that the PPS is in
fact being used (i.e. it is not random).
* We ran some experiments to analyze the stability and accuracy
of *relative* timing between RX and TX (i.e. turn-around) when
the start time for TX and RX are specified. The results are
excellent – delay is stable and accurate to < 100 ps.
This seems like a simple thing to fix in the FPGA – there is no
reason for the delay to be > 1 sample clock.
Eugene.
________________________
Eugene Grayver, Ph.D.
Aerospace Corp., Principal Engineer
Tel: 310.336.1274
________________________
_______________________________________________
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 tousrp-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
