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 <
usrp-users@lists.ettus.com> wrote:

Martin,

Thanks for the reply - your comment:

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.

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 martin.braun@ettus.com 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 usrp-users@lists.ettus.com 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 -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com

USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com