3

Am looking to have a small NTP server (Chrony) provide time to different computers located on the same student under water vehicle connected via ethernet cables. We are primarily concerned with having different parts of the vehicle synchronized to each other to <10ms over several days.

Some electronics are being synchronized directly by a 1PPS source, so keeping the NTP server and the 1PPS source synchronized is important.

"System time" synchronized to the real world is not required but nice to have if it comes for free.

Currently we have:

  • 1PPS frequency source
  • imbedded computer with an RTC which is read at startup
  • GPS Receiver but this ideally cannot be relied on as GPS does not work well underwater.

We currently feed the 1PPS signal and the GPS serial string into a USB-Serial converter (FTDI), this is then ready by gpsd, which correctly picks up the 1PPS and the GPS string for Chrony. This works and provides us about 2us synchronisation with 1PPS & GPS.

The existing setup has limitations for our application:

  1. gpsd requires a valid gps time string to initialize the time, this is not always available as we have poor GPS reception on the water and none, underwater.

  2. gpsd also require continuous valid strings to process the 1pps interrupt. This is mainly an issue if we want to disable the GPS receiver underwater to save power but want to keep syncing to the 1PPS.

  3. Once GPS is lost or the GPS unit is turned off, the system time starts drifting from the 1PPS source.

I realize that "gpsd" is heavily relying on gps, so i am using the wrong tool.

Questions:

  1. Is it possible to feed the 1PPS directly to chrony?

    1.1 Could chrony use this 1PPS and the system time alone without ever getting real world time source apart from the RTC?

  2. Are they examples on how to add a /dev/pps source using an FTDI USB-to-Serial converters RI or DCD pin? e.g what gpsd does under the hood, but without using it.

ilkkachu
  • 133,243
  • 15
  • 236
  • 397
Alexis
  • 31
  • 2
  • I had a similar question https://unix.stackexchange.com/q/655488/272848. My solution was to change `RootDistanceMaxSec=` in `/etc/systemd/timesyncd.conf`. That won't work for you (because your distance is infinite), but maybe the phraseology in that question will help you. – Stewart Jan 24 '22 at 16:43
  • I'm a bit confused: You say "under water vehicle" and GPS: GPS is known not to work under water. Then how are your vehicles connected to each other? Doing high quality PPS via serial-to-USB converter is a bad idea (I'm unsure: Can USB trigger an interrupt meanwhile? Years ago it could not and had to be polled) – U. Windl Jan 25 '22 at 08:20
  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking. – Community Jan 25 '22 at 08:20
  • @U.Windl, I understand USB 3 has something in the way about async notifications from the device, but I wonder if serial-to-USB devices would support USB 3 anyway. But as long as the time signal is 1 PPS on average, shouldn't it be enough to compensate for at least simple clock drift? – ilkkachu Jan 25 '22 at 13:18
  • Depends on how long your "autonomous" operation of the vehicles will be and what your accuracy requirements are: Maybe investing in a Rubidium oscillator and calibrating it on land (before operation) will yield better results. Standard quartz oscillators are rather temperature sensitive. – U. Windl Jan 25 '22 at 13:42
  • Chrony is a cut-down version of ntp. You might consider changing to ntp as it supports many diverse clock sources including some PPS clocks [example](https://support.ntp.org/bin/view/Support/ConfiguringAtomRefclocks). – meuh Jan 25 '22 at 14:03
  • Find if your system (what OS?) provides a compatible way to use directly the PPS source with chrony (check chrony.conf' refclock option) or else as already suggested use ntpd (might require a specific "full" package) which might have other hardware support. – A.B Jan 25 '22 at 16:49

1 Answers1

0

Partially answering my own questions from our own trial and errors.

Questions: 1. Is it possible to feed the 1PPS directly to chrony?

Answer:1 Chrony config uses 2 methods to get PPS:

  • Get it from SHM1 (shared memory) which is where gpsd puts it
  • Get it directly from a /dev/pps device

Example Config lines:

refclock SHM 1 refid PPS precision 1e-9
refclock PPS /dev/pps1 refid PPS2 precision 1e-9

Some potential pitfalls about delays are also covered in FAQ

Questions: 1.1 Could chrony use this 1PPS and the system time alone without ever getting real world time source apart from the RTC?

Answer:1.1 Yes if you add this line:

local stratum 10

Then chrony will fall back to the local clock if it loses all its sources. This also seems to be the line required for the time server to continue to be happy if all it has is a /dev/pps source and no data coming from a gps

Questions: 2. Are they examples on how to add a /dev/pps source using an FTDI USB-to-Serial converters RI or DCD pin? e.g what gpsd does under the hood, but without using it.

Partial Answer (Workaround) 2.: gpsd will accept pps from either RI or DCD and propagate the timing data to SHM1. gpsd also automatically creates a virtual /dev/pps1 device and links it to the com port, this is not the same 1pps that gpsd uses internally!

When using ppstest on /dev/pps1, you can see the PPS transitions for DCD but no transition for RI. Using ppscheck on the com port shows the pps transitions when using either RI or DCD.

We believe gpsd is rolling out its own new 1PPS detection scheme, but the virtual dev/pps1 port is using the older ldattach (line discipline) which is hardcoded to us DCD only. see this post.

Alexis
  • 31
  • 2