Ah lovely to see this. This article was the inspiration for me to automate the process, add audio recording and build a sound localizing audio recorder.

All the steps in Austin's nice article I've automated into a single install script. In addition, I've added the audio recording part that uses jackd.

One that that Austin's article didn't seem to cover is "Will this work when you disconnect from the network". Specifically, I couldn't get it to lock. In the end I discovered that the default installation of gpsmon and chrony result in a startup order that stopped the communication betweek gpsmon and the chronyd with the result that the PPS source wasn't used.

I automated fixing that problem and fixed some other things as well so if you install sbts-aru with my install script, even without any network connectivity, the time syncs to sub-microsecond error without a minute of starting up typically.

Note also, that Raspberry Pi's have a well known problem with SD card corruption from unplanned shutdowns. In addition to the above, the install code will shrink the OS and create new partitions so that the rootfs runs with an memory overlay file system to avoid this problem.

It even runs on a 15 euro battery for 24 hours portably.

Try this out and let me know what you think. If you need to communicate with me, I can be contacted on wildlabs.net.

https://github.com/hcfman/sbts-aru

Kim Hendrikse

(Now to move onto my next project, which is adding the deepfaune AI model to make a wolf, bear, lynx etc alerting system with my sbts-install project)

(Sorry about all the typos, ADHD problem). And the communication problem was that for gpsmon to communicate "with shared memory" correctly to chrony gpsmon needs to start first. The default installation sets the order the other way around. At least it was my findings for me that the instructions in the article only worked because people tended to still leave network based time services in the chrony configuration. If you take these away it would not lock.

In any case, fixing the start order made this problem go away so it must have something correct about it.

I followed the guide at https://blog.networkprofile.org/gps-backed-local-ntp-server/ which references that article. Fun little project for old Pi's laying around.

meh

Why stop at microseconds?

Why stop at local, either?

:)

  [root@garage-nuc12 ~]# chronyc tracking
  Reference ID    : 50545030 (PTP0)
  Stratum         : 1
  Ref time (UTC)  : Wed Oct 11 06:00:28 2023
  System time     : 0.000000114 seconds slow of NTP time
  Last offset     : -0.000000115 seconds
  RMS offset      : 0.000000098 seconds
  Residual freq   : -0.000 ppm

So it stays at roughly 100 nanonseconds from the time server.

The time server is low phase noise rubidium, and stays +-10ns to GPS.

My results are similiar on one of my units:

$ chronyc tracking Reference ID : 50505300 (PPS) Stratum : 1 Ref time (UTC) : Wed Oct 11 06:38:29 2023 System time : 0.000000172 seconds slow of NTP time Last offset : -0.000001066 seconds RMS offset : 0.000000628 seconds Frequency : 4.422 ppm fast Residual freq : -0.162 ppm Skew : 0.030 ppm Root delay : 0.000000001 seconds Root dispersion : 0.000010108 seconds Update interval : 4.0 seconds Leap status : Normal