Adafruit modules (ie MTK3339 ) a poor choice for timing because of the PPS to NMEA offset

[basrijn]

Hi,

I'm fairly certain the Adafruit modules (or any Mediatek MTK3339 based modules) are a poor choice for clock applications. The timing of the NMEA output relative to the PPS signal is very unfortunate as it hovers around 500ms. Since it moves around the 500ms mark the applications have trouble determining what second to round to. You might up with a time that has very high accuracy for the rollover to the next second (since PPS drives that), but end up being off by a full second from the correct time.

You can see this issue in your examples with the 512ms offset reported my chrony sources.

To show it's actual effect on the time on your system, run:
watch -n 1 date +"%T.%3N"

I've found some other reports on this issue. Somebody mentioned this being a navigation GPS chip vs a chip that is designed with timing in mind. Timing chips place the NMEA string at a specific offset to the PPS and prefer high in the sky satellites to reduce multipathing.

To take any Linux OS issues out of the mix, I tested this on a microcontroller with a very basic test program to show PPS timing vs NMEA timing, and it confirms the consistent ~ 500ms offset. Interestingly it seems to always be around 500ms, it's not different for every boot

[domschl]

An offset of several hundred milliseconds between PPS signal and serial time is to be expected and not necessarily a problem. Did you follow the instructions at: Synchronizing the offset between serial time information and PPS in order to compensate for that offset?

Chrony uses other time-sources (NTP servers) to decide which full-second time is actually correct. So you once 'nudge' the offset into the right direction (chrony requirement is <200ms offset), and then the PPS impulse can be used with very high precision (<1 microsecond).

[basrijn]

I'll do some more testing, but I'm pretty sure I had the offset configured correctly and did not see chrony doing what you described. NTP was much closer to the PPS (32ms or so), so that should work.
When you say "nudge" the offset, do you mean the setting in the config file?

[domschl]

'nudge': sorry, yes the offset setting in:

refclock SHM 0 refid GPS precision 1e-1 offset 0.512 delay 0.2 noselect

512 ms (= 0.512) in this example.

I had checked quite a number of different GPS chips, and the only difference that mattered in real life was reception: some chips support multiple GPS systems and thus can receive more satellites. Making sure that reception is good (free view of sky) has (in my experience) much larger impact on time signal quality than chip set optimizations.

There are also variants of GPS chip sets specifically suited for precision time applications (eg NEO-M8T), but it didn't improve the precision for networked clients: the error introduced by network time synchronization always outweighed those optimizations. So optimizing the hardware like that only provides (possibly) an advantage on the time server host itself. You should get good results with any GPS chipset (even the cheapest).

[basrijn]

I just redid the full config. Tweaked the offset (0.480) as per the instructions. I don't know if the watch -n 1 date +"%T.%3N" is a good test, but it jumps seconds as before. Comparing against an phone running a millisecond clock. It's also significantly off

chronyc sources shows:

#? GPS 0 4 377 21 +24ms[ +24ms] +/- 200ms
#* PPS1 0 4 377 22 +4042ns[ +14us] +/- 329ns
^- s173-183-146-26.ab.hsia.> 2 8 377 102 -4801us[-4772us] +/- 41ms
^- ntp.mtl2.ca.leaseweb.net 2 8 377 159 -6685us[-6659us] +/- 169ms
^- ntp3.torix.ca 1 8 377 95 -3325us[-3297us] +/- 30ms
^- muug.ca 2 8 377 97 -12ms[ -12ms] +/- 80ms

Not sure if 'date' pulls time from a local clock that is not synchronized often (rtcsync, every 11 min?). I installed ntpdate and running watch -n 1 ntpdate -q localhost show the exact same behavior.

[domschl]

So your installation seems to work just fine (you have PPS lock with deviation < 1uS).

watch is not a good way to determine the precision of the time signal, it just samples the date-output.

Use chronyc tracking instead, this gives actual meaningful statistics on the precision of your clock, sample output:

Reference ID    : 50505330 (PPS0)
Stratum         : 1
Ref time (UTC)  : Fri Feb 09 15:00:40 2024
System time     : 0.000000100 seconds slow of NTP time
Last offset     : -0.000000230 seconds
RMS offset      : 0.000000804 seconds
Frequency       : 2.324 ppm slow
Residual freq   : -0.000 ppm
Skew            : 0.020 ppm
Root delay      : 0.000000001 seconds
Root dispersion : 0.000016292 seconds
Update interval : 16.0 seconds
Leap status     : Normal

The meaning of the fields is explained here.

[basrijn]

Hi

Would ntpdate be an ok test? I think that queries the NTP server directly?

[domschl]

ntpdate is a retired tool to set NTP time on a client by querying an NTP once, it is no longer used. It has been replace by ntp (or now chrony) servers on client side too.

What exactly do you want to test?