On 18/01/2024 14:21, Steve Hamn wrote:
That might be a bigger project. Can I just hook the Trig Out to a
Oscilloscope to meausre the Pulse Width 1 PPS? Or is that a different
signal?
Thanks,
Steve
A qualified "maybe". The GPS PPS signals I think go into the FPGA for
processing, so the TRIG OUT may have been "massaged"
by the FPGA.
On Thu, Jan 18, 2024, 08:06 Marcus D. Leech <patchvonbr...@gmail.com>
wrote:
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
