FriendlyElec NanoPi R5S as PTP Grandmaster Clock with GNSS/GPS Discipline (2022) | Hacker News Reader

FriendlyElec NanoPi R5S as PTP Grandmaster Clock with GNSS/GPS Discipline (2022)

blog.kylemanna.com

36 pointspbrowne0118 comments

> It’s unclear to me why there’s so much delay and jitter in the PPS timestamping.

I’ve messed around with this on a couple different GPS chips. I’ve found improvements can be made by increasing the baud rate to the maximum supported. 9600 tends to be the default, but 57600 works a lot better. Also, disable all NMEA sentences except the one you are using. Finally ramp up the update interval to be much more often. The default tends to be every 1000 milliseconds, but 100 milliseconds works better for less jitter. I’ve been using NTPsec, not Chrony, so maybe there are more nuances.

Im just a hobbyist, but I have a bit more details written up here, checkout the poorly designed hamburger menu for some charts and graphs: https://www.developerdan.com/ntp/

In the article, they are using a PPS output into a GPIO IRQ. I don't think they're using serial/NMEA for the timestamping

I’m not familiar with Chrony. With NTPsec, the PPS driver docs say [0]:

> While this driver can discipline the time and frequency relative to the PPS source, it cannot number the seconds. For this purpose an auxiliary source is required;

And so (with NTPsec), you need to define two sources even though it’s coming from the same device. One for the PPS signal for clock discipline, the other for the clock value.

> refclock pps ppspath /dev/gpspps0 prefer

> refclock nmea baud 57600 prefer

0: https://docs.ntpsec.org/latest/driver_pps.html

Sure, but that aux data should not be used for any sub-second accuracy information. The PPS is the end-all be-all definition of the start-of-second. Improving performance of another band should never affect the performance of the sub-second jitter.

They should hook up a scope to that PPS output and compare it to a solid reference. I suspect if they're experiencing intermittent dropouts on a poor GPS module that the PPS signal likely is not a high quality reference. Those ublox counterfeits might be okay, but I've been really impressed with Navspark's pin-compatible ublox "knockoffs". Super cheap, super performant.

Set up my own GPS-referenced NTP server using an RPi3, very easy. Needed to use a powered antenna though, that little PCB thing I got with the module just didn't cut it.

Been working augmenting it with a 10MHz ovenized crystal oscillator (OXCO) for kicks, in case GPS is offline. You can second-hand units cheap on AliExpress and Ebay, which is nice as they're pre-aged so shouldn't drift as much.

Quality can vary a bit between them, some have lived a hard life perhaps, so I suggest getting 5 and checking with a scope.

Chrony somewhat recently gained support for multiple PPS sources, so should be able to just hook it up. This means I shouldn't need to worry about the absolute frequency of the OXCO as long as it is stable, which is nice.

The phase of the OCXO's PPS will need to be disciplined to GPS, otherwise your offline time reference will be a stable, low jitter, and wrong.

Edit: I see you mean not feeding in PPS, only 10 MHz where phase doesn't matter. I didn't know Chrony supported that. You could also use a good reference multiplied to replace the Pi's clock.

Gepetto's GPSDO has been tempting to me for a long time. I've just never had an application to justify the cost.

https://www.tindie.com/products/nsayer/gps-disciplined-ocxo/

Sorry, sloppy wording. My circuit will allow for both, with a small uC doing the 10MHz to PPS division and also run a DAC to control the OXCO fine-adjustment.

But I figured I'll try the simple approach first.

fyi r5s is supported by openwrt upstream so you don't need to deal with vendor firmware (friendlywrt) anymore

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c0...

Reply on news.ycombinator.com