Get PPS working with GPS

[geerlingguy]

I noticed in the course of debugging #12 that cgps / gpsmon aren't showing any PPS output from the GPS module... that would be pretty important to getting nanosecond-accurate time.

I see there are two PPS devices currently:

$ ls /dev | grep pps
/dev/pps0
/dev/pps1

But if I try querying them, I get nothing:

$ sudo apt install pps-tools
$ sudo ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)

(Same for PPS1).

gpsmon shows no PPS available:

[geerlingguy]

The M2 card is definitely sending 1PPS:

IMG_1666.mp4

But reading the Tindie product page docs, it looks like the PPS output on the GPS module is linked directly to the PPS in on the NIC:

1PPS from GNSS to SDP2 on I226: The 1PPS signal from the GNSS module connects directly to the NIC, allowing the NIC to discipline itself to GPS time. This feature is essential for building a reliable grandmaster clock, providing accurate time sourced directly from satellites.

[geerlingguy]

# Install testptp
cd ~ ; mkdir testptp; cd testptp
wget https://raw.githubusercontent.com/torvalds/linux/refs/heads/master/tools/testing/selftests/ptp/testptp.c
wget https://raw.githubusercontent.com/torvalds/linux/refs/heads/master/include/uapi/linux/ptp_clock.h
sudo cp ptp_clock.h /usr/include/linux/ptp_clock.h
gcc -Wall -lrt testptp.c -o testptp
sudo cp testptp /usr/bin/

# Verify it works
$ sudo testptp -d /dev/ptp0 -l
name SDP0 index 0 func 0 chan 0
name SDP1 index 1 func 0 chan 0
name SDP2 index 2 func 0 chan 0
name SDP3 index 3 func 0 chan 0

Then I can set the output to go to the SMA nearest the 40-pin connector on the HAT:

pi@mini-time:~/testptp $ sudo testptp -d /dev/ptp0 -L0,2
set pin function okay
pi@mini-time:~/testptp $ sudo testptp -d /dev/ptp0 -p 1000000000
periodic output request okay

[geerlingguy]

Trying to discipline to 1PPS from GNSS, though, seems to fail:

$ sudo phc_ctl eth1 "set;" adj 37
phc_ctl[581747.718]: set clock time to 1744301043.896250523 or Thu Apr 10 11:04:03 2025

phc_ctl[581747.718]: adjusted clock by 37.000000 seconds

$ sudo ts2phc -c /dev/ptp0 -s generic --ts2phc.pin_index 2 -m -l 7
ts2phc[581761.260]: config item (null).message_tag is '(null)'
...
ts2phc[581761.260]: PHC slave /dev/ptp0 has ptp index 0
...
ts2phc[581761.260]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
ts2phc[581761.261]: PTP_EXTTS_REQUEST2 failed: Operation not supported
failed to arm slaves

More info:

$ sudo phc_ctl eth1
phc_ctl[581928.878]: 
capabilities:
  62499999 maximum frequency adjustment (ppb)
  0 programable alarms
  2 external time stamp channels
  2 programmable periodic signals
  4 configurable input/output pins
  has pulse per second support
  doesn't have cross timestamping support

[geerlingguy]

Ah... found:

$ sudo ts2phc -c /dev/ptp0 -s generic --ts2phc.pin_index 2 --ts2phc.extts_polarity both -m -l 7
...
ts2phc[582100.926]: /dev/ptp0 extts index 0 at 1744301434.000000001 corr 0 src 1744301434.104869404 diff 1
ts2phc[582100.926]: /dev/ptp0 master offset          1 s2 freq +6953628
ts2phc[582101.826]: /dev/ptp0 extts index 0 at 1744301434.893761438 corr 0 src 1744301435.4868316 diff -106238562
ts2phc[582101.826]: /dev/ptp0 master offset -106238562 s2 freq -62499999
ts2phc[582101.926]: /dev/ptp0 extts index 0 at 1744301434.999997342 corr 0 src 1744301435.104868541 diff -2658
ts2phc[582101.926]: /dev/ptp0 master offset      -2658 s2 freq +6950969

Some of the other docs on the tindie page indicate the default Pi OS kernel seems to only allow 'both' rising/falling edge for the i226. If you use the default (rising) by not specifying the polarity, it fails like above.

See: [Linuxptp-users] PPS Error: PTP_EXTTS_REQUEST2 failed.

[geerlingguy]

Supposedly there's a rising-edge-only patch for i225 here (https://raw.githubusercontent.com/opencomputeproject/Time-Appliance-Project/refs/heads/master/Incubation/Software/I225_ppsin_fix/i225_pps_rising_edge_only_1-31-2025.patch), but that link 404s now.

@JulianStj may have it elsewhere in another Linux fork...?

@ahmadexp the only reference I can find now is this commit in a removed file: https://github.com./Time-Appliances-Project/Incubation-Projects/blob/45274f934c26cf6b1155fadff3268a95ce810cd8/Software/I225_ppsin_fix/i225_pps_rising_edge_only_1-31-2025.patch#L72

The patch now lives here: https://github.com./Time-Appliances-Project/Incubation-Projects/blob/master/Software/I225_ppsin_fix/i225_pps_rising_edge_only_1-31-2025.patch

[geerlingguy]

I noticed after 10 minutes, it didn't seem like the PHC was synced:

But that's apparently due to it using the rising and falling edge (the both above).

So I'll have to apply the patch to get that fixed.

[geerlingguy]

Aha! Reading through some Intel documentation on timestamping, if I override the pulse width parameter from the default, I can get sync:

$ sudo ts2phc -c /dev/ptp0 -s generic --ts2phc.pin_index 2 --ts2phc.extts_polarity both --ts2phc.pulsewidth 100000000 -m -l 7
...
ts2phc[584253.826]: /dev/ptp0 extts index 0 at 1744303587.000000014 corr 0 src 1744303587.4846666 diff 14
ts2phc[584253.826]: /dev/ptp0 master offset         14 s2 freq   +7119
ts2phc[584253.926]: /dev/ptp0 SKIP extts index 0 at 1744303587.100000006 src 1744303587.104849225
ts2phc[584254.826]: /dev/ptp0 extts index 0 at 1744303587.999999992 corr 0 src 1744303588.4846416 diff -8
ts2phc[584254.826]: /dev/ptp0 master offset         -8 s2 freq   +7101
ts2phc[584254.926]: /dev/ptp0 SKIP extts index 0 at 1744303588.099999993 src 1744303588.104843307
ts2phc[584255.826]: /dev/ptp0 extts index 0 at 1744303589.000000002 corr 0 src 1744303589.4847016 diff 2
ts2phc[584255.826]: /dev/ptp0 master offset          2 s2 freq   +7109
ts2phc[584255.926]: /dev/ptp0 SKIP extts index 0 at 1744303589.100000014 src 1744303589.104848482
ts2phc[584256.826]: /dev/ptp0 extts index 0 at 1744303590.000000010 corr 0 src 1744303590.4847432 diff 10
ts2phc[584256.826]: /dev/ptp0 master offset         10 s2 freq   +7117
ts2phc[584256.926]: /dev/ptp0 SKIP extts index 0 at 1744303590.100000021 src 1744303590.104848268
ts2phc[584257.826]: /dev/ptp0 extts index 0 at 1744303591.000000029 corr 0 src 1744303591.4847828 diff 29
ts2phc[584257.826]: /dev/ptp0 master offset         29 s2 freq   +7139

[geerlingguy]

Trying to discipline the system clock (CLOCK_REALTIME), I see:

$ sudo phc2sys -s /dev/ptp0 -c CLOCK_REALTIME --step_threshold=1 --transportSpecific=1 -O 37 -m
...
phc2sys[585071.551]: CLOCK_REALTIME phc offset       240 s2 freq -62509628 delay   1948
phc2sys[585072.552]: CLOCK_REALTIME phc offset       125 s2 freq -62509671 delay   1967
phc2sys[585073.556]: CLOCK_REALTIME phc offset        35 s2 freq -62509723 delay   1967
phc2sys[585074.557]: CLOCK_REALTIME phc offset         5 s2 freq -62509743 delay   1948
phc2sys[585075.572]: CLOCK_REALTIME phc offset        -2 s2 freq -62509748 delay   1948
phc2sys[585076.587]: CLOCK_REALTIME phc offset        -4 s2 freq -62509751 delay   1967
phc2sys[585077.610]: CLOCK_REALTIME phc offset         5 s2 freq -62509743 delay   1967
phc2sys[585078.617]: CLOCK_REALTIME phc offset        -6 s2 freq -62509753 delay   1968
phc2sys[585079.630]: CLOCK_REALTIME phc offset        -2 s2 freq -62509750 delay   1968
phc2sys[585080.643]: CLOCK_REALTIME phc offset         9 s2 freq -62509740 delay   1968
phc2sys[585081.654]: CLOCK_REALTIME phc offset         2 s2 freq -62509744 delay   1967
phc2sys[585082.664]: CLOCK_REALTIME phc offset         7 s2 freq -62509739 delay   1948
phc2sys[585083.673]: CLOCK_REALTIME phc offset         8 s2 freq -62509736 delay   1967
phc2sys[585084.673]: CLOCK_REALTIME phc offset -10695401 s2 freq -73205142 delay   1715
phc2sys[585085.712]: CLOCK_REALTIME phc offset   -336628 s2 freq -66054990 delay   1967
phc2sys[585086.746]: CLOCK_REALTIME phc offset   3101446 s2 freq -62717904 delay   1975

I'm guessing chrony is adjusting the time every so often, and phy2sys and chrony are duking it out... indeed, over in chrony logs:

Apr 10 12:01:26 mini-time chronyd[671]: System clock wrong by -2.473483 seconds
Apr 10 12:01:43 mini-time chronyd[671]: System clock wrong by -2.504405 seconds
Apr 10 12:01:59 mini-time chronyd[671]: System clock wrong by -2.467934 seconds
Apr 10 12:02:15 mini-time chronyd[671]: System clock wrong by -1.600861 seconds
Apr 10 12:02:47 mini-time chronyd[671]: Can't synchronise: no selectable sources
Apr 10 12:03:03 mini-time chronyd[671]: Selected source GPS
Apr 10 12:03:03 mini-time chronyd[671]: System clock wrong by 1.329226 seconds

[geerlingguy]

If I stop chrony, I see the offset sub-10ns:

phc2sys[586053.634]: CLOCK_REALTIME phc offset        -8 s2 freq -62509850 delay   1948
phc2sys[586054.670]: CLOCK_REALTIME phc offset         6 s2 freq -62509838 delay   1948
phc2sys[586055.673]: CLOCK_REALTIME phc offset         0 s2 freq -62509842 delay   1948
phc2sys[586056.705]: CLOCK_REALTIME phc offset        -2 s2 freq -62509844 delay   1947
phc2sys[586057.716]: CLOCK_REALTIME phc offset         1 s2 freq -62509842 delay   1948

See #12 for Chrony follow-up.

[geerlingguy]

Fixed by telling Chrony to use the PHC /dev/pps0 as the time source, and now I'm also seeing the PPS value in gpsmon, yay!

TOFF:  0.057123628       PPS:  0.000008401 

Just need to get the fix a little better, likely with the outdoor antenna, because the VDOP/HDOP are like 3-5 now (+/- 25m). Was better earlier, after the Pi had been running for a few days, but after a reboot, took a while to get his new fix.