On 15/01/2024 20:05, Rob Kossler via USRP-users wrote:
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
My previous assertion about it being on the "unfortunate end" of the DDC
is stale. It used to be the case, but when the Radio
block was broken-out from the DDC/DUC blocks, things were shifted
into the radio block, at the notional interface to the
ADC/DAC. That would have broken apps that "knew" that it was at the
other end of the DUC/DDC, but the new mechanism
should be much "closer" to the antenna-plane.
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
