Martin,
Thanks for the reply - your comment:
>what the PPS does is tag one specific up-flank of the 10 MHz signal as
>beginning-of-second flank
explained it perfectly. I was hoping it did, or there was a way to use the 200
MHz clock to sample the 1PPS signal for time tagging or time measurement.
>I don't quite understand what you're trying to do
The GPSDO I'm using phase locks the 1PPS and 10 MHz, but at a random phase that
I can't control, which can change every power cycle, or when the GPS timing
drifts too far. Rather than the 1PPS always being on the rising 10 MHz edge and
driving that to 0 ns UTC, this GPSDO puts the 1PPS at 0 ns UTC (regardless of
where that is relative to the 10 MHz) and then phase locks the 10 MHz and 1PPS.
So, one power cycle it can be at the rising edge, another it can be at the
falling edge, and another it can be somewhere in between.
Once locked, there are exactly 10M cycles between 1PPS pulses, and the phase
doesn't change. But for example if I capture a signal when the 1PPS is at the
10 MHz rising edge, then power cycle the GPSDO and capture the exact same
signal, but with the 1PPS at the 10 MHz falling edge, the correlation of the
two captured signals will appear to be 50 ns different simply due to the 10 MHz
phase difference, even though the actual difference should have been 0 ns.
If the 1PPS and 10 MHz were always at the same phase, then this error would
calibrate out, but in my case it adds up to 100 ns of uncertainty to the
measurements. So I'll have to implement a way to determine the 1PPS/10 MHz
phase so I can calibrate out the error manually.
Thanks,
Pat
On Tuesday, July 1, 2025 at 08:30:13 AM EDT, Martin Braun
<[email protected]> wrote:
Pat,
the USRP expects the PPS to stay consistent with respect to the 10 MHz signal.
Electrically speaking, what the PPS does is tag one specific up-flank of the 10
MHz signal as beginning-of-second flank. The 200 MHz master clock rate is
generated from the 10 MHz with a zero-delay mode of the corresponding PLL, so
you get exactly 20 cycles of 200 MHz signal per cycle of 10 MHz signal. The PPS
therefore also can accurately tag a 200 MHz flank, which is how we get the
accuracy of our timed commands. You can set all sorts of stuff at 5ns
resolution this way, but with a timing accuracy that is better than 5ns (it
depends on the quality of your reference signal).
If you start to drift the PPS relative to the 10 MHz, then that will throw off
the USRP, but one thing to keep in mind is that we increment the timing counter
with the 200 MHz clock, independent of the PPS signal. That means the USRP
won't care that you're drifting the PPS relative to your 10 MHz until you do
something with the PPS signal. The get_time_last_pps() value is such a value.
So if 10 MHz and PPS are drifting apart, eventually you'd see a non-integer
value there.
I'm not sure if this is helping answer your question... I don't quite
understand what you're trying to do.
--M
On Sat, Jun 28, 2025 at 10:59 AM Pat Daderko via USRP-users
<[email protected]> wrote:
Hi,
I’m using an X310 w/ UBX160, referenced to an external 10 MHz and 1PPS from a
good quality GPSDO (Jackson Labs Micro-JLT). I’m using it to receive a signal
from a signal generator with precise timing, and trying to make precise timing
measurements. E.g. begin capturing exactly on the 1PPS, correlate, and find
the delay.
The problem I’m running into is that there seems to be an additional delay
uncertainty depending where the 1PPS is relative to the 10 MHz phase. I.e. it
seems that the 1PPS is registered on the 10 MHz edge, instead of the master
clock (200 MHz) like I would have expected. So, instead of 5ns uncertainty
(would be OK), I’m seeing 100ns of uncertainty.
The reason it’s particularly problematic is that (oddly) while this GPSDO phase
locks the 1PPS to the 10 MHz, every time it locks to GPS, the 1PPS locks at a
random phase (wherever is closest to 0 ns to UTC). It doesn’t lock (for
example) the rising edge of the 10 MHz to the 1PPS. And if it does a “jam
sync” from the OCXO drifting outside the allowed window, it again moves the
1PPS, disregarding the phase of the 10 MHz. From the documentation, it sounds
like its PPS resolution is based on a 180 MHz clock (5.55 ns).
I’m using a modified rx_samples_to_file, which sets external reference, syncs
to 1PPS, starts at a specified time, etc… which has 100% consistent timing,
until the 1PPS/10 MHz phase changes (GPSDO power cycle or jam sync). The
signal generator creates the sequence to correlate against precisely on the
1PPS with just a few ns of jitter from phase of the reference.
I was able to synthetically create conditions to test this. I connected the
signal generator and X310 to the same 1PPS and 10 MHz reference, and
captured/correlated at 5ns steps. There’s a small amount of variation due to
the GPSDO 5.55ns step resolution and signal generator 3.125ns resolution, but
basically, the computed timing moved linearly with the shift in phase relative
to the 10 MHz.
Images are attached. On the oscilloscope plots I used infinite persistence,
triggered on the rising edge of the 1PPS. The yellow trace is one of the chips
of the sequence from the signal generator, which you can see has consistent
timing vs. the 1PPS. The blue is the 1PPS input, and magenta is the 1PPS
output from the X310. The green trace is the 10 MHz (buffered square wave from
the signal generator). I noticed the X310 1PPS output also always has
consistent timing, so it seems it’s not actually the 1PPS registered in the
FPGA for timing. The 2nd oscilloscope image shows when I had shifted the 1PPS
180 degrees out of phase from the 10 MHz in the first image. The correlation
results for each shift were plotted in Excel.
First of all, does anyone know if the 1PPS triggering/time tagging is supposed
to only have 100ns resolution? Anyone have any ideas on how to improve this,
or is there some other way of determining what the offset actually is (at say
5ns resolution) even if it everything still operates at 10 MHz?
I’ve looked at the metadata from the stream, and it always returns the exact
same timing values. Calling get_time_last_pps() also always returns the same
value (e.g. 3.000000000 seconds)… I was hoping one of these might say
2.999999990 or something, in which case I could infer that there was a 10ns
shift. Any other timing functions that’d measure with the 200 MHz master
clock? Or should I give up on this and figure out another solution?
Thanks,
Pat_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
