On 18/01/2024 02:24, Steve Hamn wrote:
Hi Marcus,
Do you know what the Pulse Width of the PPS in the N3XX GPSDO is?
(I.e. how much time difference would this result in?).
I've been seeing ~100ms of timing error with an N320 using GPS vs an
N320 using WR, that I've been trying to debug. I'm using UHD 4.4 so
I'm wondering if this could be a cause?
Thanks,
Steve
I don't know off the top of my head. Update host and radio to UHD4.5
or 4.6 and try again?
On Wed, Jan 17, 2024, 13:47 Marcus D. Leech <patchvonbr...@gmail.com>
wrote:
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.
Eugene:
Talking to R&D folks (or, rather, R&D-adjacent) at NI, there was a
problem in UHD starting in 4.1 where the PPS was aligning on
the *trailing* edge, so time would be off by the pulse-width.
Make sure (on the N3xx case) you're running UHD 4.5 or UHD 4.6 on
both the host and the device itself.
________________________
Eugene Grayver, Ph.D.
Aerospace Corp., Principal Engineer
Tel: 310.336.1274
________________________
------------------------------------------------------------------------
*From:* Rob Kossler <rkoss...@nd.edu> <mailto: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>
<mailto:usrp-users@lists.ettus.com>; Mark Kubiak
<mark.kub...@aero.org> <mailto:mark.kub...@aero.org>; Jason W
Zheng <jason.w.zh...@aero.org> <mailto: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
<mailto: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
