Independance?

[Canoe001]

Would this feature be possible?

Would it be difficult to have an option to have PPS-Client do its task of disciplining system time to TOS (top of second) from a PPS signal, but while running independently:

• PPS-Client would run using the current system time whole second (whatever that may be),
• without using or even having NTP installed,
• the Pi could use an independent software of choice (using its own independently selected time reference) to set system time to a whole second,
• PPS-Client runs independently without needing to know what that software was, its reference source, nor even if it has done its task - simply align the system time whole second to PPS.

Workable?

[rascol]

Short answer: yes the feature is possible.

Long answer: There is no special reason to use NPT to set the whole-second time of day. It was just that it was convenient to use it. The only requirement is that periodically whatever is providing the time of day should be queried for the current time and then the difference in seconds, (provider_time - clock_time) if there is a difference, should update the system clock. Updates are necessary to account for local time changes caused by daylight savings time and leap seconds.

As I recall, making direct changes to the system clock externally to PPS-Client caused some problems because the parts of NPT that are embedded in the kernel prevent slews to a new time of day of more than 500 microseconds each second. I got around this by making the correction through its kernel driver below the NTP code. I don't know whether doing external time settings is still an issue in later Linux kernels. I haven't looked at the code in more than a year so before before committing to a code revision I will have to investigate this again.

What do you have in mind for setting the whole second time of day?

Ray

------ Original Message ------ Received: 02:06 PM EST, 11/23/2017 From: Canoe001 notifications@github.com To: rascol/Raspberry-Pi-PPS-Client Raspberry-Pi-PPS-Client@noreply.github.comCc: Subscribed subscribed@noreply.github.com Subject: [rascol/Raspberry-Pi-PPS-Client] Independance? (#1)

Would this feature be possible?

Would it be difficult to have an option to have PPS-Client do its task of disciplining system time to TOS (top of second) from a PPS signal, but while running independently:

• PPS-Client would run using the current system time whole second (whatever that may be),
• without using or even having NTP installed,
• the Pi could use an independent software of choice (using its own independently selected time reference) to set system time to a whole second,
• PPS-Client runs independently without needing to know what that software was, its reference source, nor even if it has done its task - simply align the system time whole second to PPS.

Workable?

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rascol/Raspberry-Pi-PPS-Client/issues/1

[Canoe001]

• I like running Lady Heather, as it takes GPS or GPS timing messages and displays a lot of info, some in graphs and some in skyview maps. So between having a DS3231 based RTC for reboots and having LH do a crude setting of system time to the whole second, having (a) PPS-Client discipline system time to TOS from PPS to +/- 1 us would be golden.
• LH has the option of looking at the GPS time vs. system time and will set system time when the delta is more than x ms, with x being a settable parameter.
• But for independence, I'm thinking that whatever is setting the whole second should be independent and unknown by PPS-Client, hence fully decoupled from (a) PPS-Client.
• The idea would be that one could use NTP, NPTsec, LH, ..., on the Pi without PPS-Client even needing to know about them.
• The source for LH and NTPsec is available.
• The whole Pi can be encased in a thermally managed environment for increased stability. Essentially turning the Pi/system-time into a UTC reference source, to be run 24/7.
• I'm thinking that NTP or NTPsec could use (the disciplined) system time as its reference source, making that available to requests. Entirely unaware of the GPS or PPS-Client, nor needing to as PPS-Client is disciplining system time to TOS. Also doing periodic updates of the RTC, for a tighter reboot time.
• To get around the loss in precision going through the Pi Ethernet on a USB controller, one could also use the Pi UART to have a Pi "PPS-Server" provide a System-Time PPS onward to a serial port input on a polling machine. There may even be a way of calibrating that onward PPS exactly to TOS, or calibrate with the receiving machine so it sees and then presents the PPS at TOS on the receiving machine.

But all of the above is just thoughts without my knowing anything about the internal workings of PPS-Client.

Michael

[Canoe001]

Well that was a lot easier than I thought it would be. Install happened like the documentation said. Running pss-client would exit as it wouldn't find NTP. In pps-client.cpp, I commented out the check for NTP and disabling/re-enabling NTP. I was able to rebuild the installer. pps-client runs and -v runs. Lady Heather is running too, producing nice skymaps.

I didn't pay attention to exactly when, but around ten minutes in:

• jitter is +/- single digit
• frequency offset is -3.120994
• avgCorrection is typically 0.00000, -0.016667 or -0.033333, occasionally 0.016667 or 0.033333
• clamp is 1

At the 1023 mark it displayed "sh: 1: ntpq: not found" At 1024 it displayed: "Number of server addresses: 0" "Starting a time check." Nothing appeared to happen and status messages continued as they had. At 2048 it displayed: "Starting a time check." No discernible activity from this. Same message displays roughly every additional 1000 seconds. So I have no idea if the above indicates anything is 'broken', but it appears to get past those checks and the status 'printout' seems to indicate that it is successfully disciplining System Time to TOS from the PPS. I have no idea if the holdover behaviour will do what I need.

To test for stability, I gave the heatsinks on the Pi 3 a moderate blast of canned air. Jitter jumped up to 50 to 54. As jitter started to drop back, clamp jumped to 4. Over a few minutes jitter falls back to single digit, then clamp slides back to 1 while the jitter returns to low single digit values.

After running overnight:

• jitter is typically between -2 and +3, with a regular value ranging between -5 and +10
• frequency offset is stable at -3.0_____ with the last 5 digits the same for a number of seconds at a time

To ensure it's doing what I expect, I'm going to have to turn the logging on. Then I can look back at the pps-client corrections during the periods that Lady Heather's graphs show the GPS accuracy jumped from sub 12 ns (typically 6 to 8 ns) to 30 ns to 50 ns during periods of low sat count or low sat signal (I have less than half a skyview and multipath).

It's a rude and crude mod as it doesn't take any consideration of what/how pps-client is working, but PPS-Client appears to be doing the main job of disciplining System Time to TOS from the PPS. Certainly better than I'd ever dreamed would be possible on a Pi 3.

Michael

[rascol]

OK. I revised the code over the weekend to allow pps-client operate without NTP by setting a command in the /etc/pps-client.conf file. Any program will be able to set the system time of day exactly as originally requested. It will take a few days to a week to look for unforeseen problems and to update the docs.

BTW, I'm happy you were able to get ops-client up and running. From what you described, so far so good. The time checks you observed will disappear when NTP is disabled.

Ray

[Canoe001]

Nice. I had my copy of the code working with a command line argument, but in conf is much cleaner.

Time issues are fairly new to me, so I'm operating from partial understanding. It is very interesting, the co-ordinating with the kernel when there is external disciplining by PTP or pps-client, etc.. I'm still wrapping my head around that with using NTP as client-server vs. server-only, related holdover behaviour and what NTP/NTPsec will do when using a refclock of local with/without other refclocks.

This morning Lady Heather showed me how my sat count was down to one for 95% of an hour and a half period last night as a new sat would come into my skyview just before the last one would leave. The NEO-M8T provided a timing solution throughout, but there were some accuracy spikes. PPS-Client just pulsed along, keeping the Pi in line with ease. Love it!

Thank you very much for PPS-Client.

Michael

[rascol]

The revisions have been made. When you have had a chance to try out the new code, if there are no issues, I will close this issue.

Ray

[Canoe001]

Sounds great. My internet has been tragically slow since Saturday. As soon as it can download files without timing out, I'll install and test. (driving me nuts... even times out on sending/receiving email)

[rascol]

Been there. No hurry.

[rascol]

I'm going to close this issue. The code has come a long way since this issue was opened. I'm convinced that the request was satisfied. If there are any further difficulties, raise a new issue.

Ray