Occasional Blog

[Falcon-118]

Phil, I know this is not a gpsctl issue per se. I tried to contact you via the gmail on your occasional blog, no joy. I think your cookbook on the occasional blog needs some updates. I'd be glad to help and/or be the guinea pig to test when complete. Just trying to make contact, feel free to delete this as its off topic. The email from me is pacbell.net.

ie:
in /etc/udev/rules.d/ the file 80-gps-to-ntp.rules no longer exists. It's now 99-rules.com

in lsmod | grep pps I can never get the pps_core to show

hwclock does not survive reboots: after reboot sudo hwclock -w -v hwclock from util-linux 2.36.1 System Time: 1695232199.691253 Trying to open: /dev/rtc0 Trying to open: /dev/rtc Trying to open: /dev/misc/rtc No usable clock interface found. hwclock: Cannot access the Hardware Clock via any known method.

[philrandal]

My blog says to create that file. It's not wise to mess with system-provided config files.

$ cat /etc/udev/rules.d/80-gps-to-ntp.rules
# Change MODE of ttyAMA0 so it is readable by NTP and provide

# a symlink to /dev/gps0
KERNEL=="ttyAMA0", SYMLINK+="gps0", MODE="0666"
# Symlink /dev/pps0 to /dev/gpspps0
KERNEL=="pps0", SYMLINK+="gpspps0", MODE="0666"

No idea why hwclock isn't working for you.

Did you follow my "Postscript, June 21st, 2020" instructions?

[Falcon-118]

Started all over, clean slate.

Still do not get pps_core from lsmod | grep pps

sudo ppstest /dev/pps0 fills with errors:

sudo ppstest /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" ok, found 1 source(s), now start fetching data... source 0 - assert 1695253438.010717963, sequence: 72 - clear 0.000000000, sequence: 0 time_pps_fetch() error -1 (Connection timed out) time_pps_fetch() error -1 (Connection timed out) time_pps_fetch() error -1 (Connection timed out) time_pps_fetch() error -1 (Connection timed out)

Yes, I've read your postscript and tried to follow, however, The line hw-clock-set with --systz -- badyear does not exist The line --systx only does exist Then there is a line with --hctosys ???

When I go to run sudo configure-r3028.sh I am told "command not found", though it clearly exists in the prescribed directory.

I'm just following your cookbook. Step for step. All is well until lsmod | grep pps

As I mentioned in my email... if you got it, the 80-gps-to-ntp.rules does not exist and your instructions say to edit it... not create it. I realize you can do both, but it's not clear.

Phil, I really want to make this work, I'm retired and have done a fair amount of technical writing, I'd like to help clean this up and make the changes inline for your postscript notes... I'll be the first to admit I don't know this stuff as well as you. I think your build is superior as it eliminates the location and motion elements of GPS, but there have been a lot of updates the past few years.

[Falcon-118]

OK the problem is Bullseye. I backed off to the latest version of Buster at RPi and have gotten a bit further. At least seeing the pps_core.

pi@RPi4b-NTP-GPS:~ $ lsmod | grep pps pps_gpio 16384 0 pps_core 16384 1 pps_gpio pi@RPi4b-NTP-GPS:~ $ dmesg | grep pps [ 3.028722] pps_core: LinuxPPS API ver. 1 registered [ 3.028766] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti giometti@linux.it [ 3.042234] pps pps0: new PPS source pps@12.-1 [ 3.042356] pps pps0: Registered IRQ 66 as PPS source

And PPS test isn't throwing errors

pi@RPi4b-NTP-GPS:~ $ sudo ppstest /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" ok, found 1 source(s), now start fetching data... source 0 - assert 1695262931.001079928, sequence: 5092 - clear 0.000000000, sequence: 0 source 0 - assert 1695262932.001079604, sequence: 5093 - clear 0.000000000, sequence: 0 source 0 - assert 1695262933.001081215, sequence: 5094 - clear 0.000000000, sequence: 0 source 0 - assert 1695262934.001082352, sequence: 5095 - clear 0.000000000, sequence: 0 source 0 - assert 1695262935.001084813, sequence: 5096 - clear 0.000000000, sequence: 0

I get to this point, just following the cookbook, not postscript notes applied so far.

[philrandal]

Have you done

• sudo apt update
• sudo apt full-upgrade

and rebooted?

[Falcon-118]

Yes, Sir. If it's in your cookbook, I'm following it set by step.

One of the other builds I did (Kreeblah, here on Github) had an issue I found that was OS related, so I pulled the versions of Buster around the time you wrote your build but I decided to start with the latest version of Buster still accessible via the Pi imager - Legacy, Buster, Lite. The build fails if I start with Bullseye image, As you see, it works if I start with Buster... and do the full-upgrade. I stopped after the "ppstest /dev/pps0" last night. I'll pick back up with "Enabling PPS/ATOM" after I have breakfast.

Is there any specific points in the process you feel are the best to process your postscripts?

[philrandal]

I'm at a loss. I'm currently running bullseye / bookworm 64-bit without issues. My postcripts are just notes. The RTC info is based on an early uputronics GPS HAT containing thr rv3028, where I had to do the extra config (in the script) to make it work.

[Falcon-118]

Starting with Buster and following your cookbook, everything is as your cookbook shows (for the first time). I have a complete build save the June 21, 2020 postscript. Once I get to "sudo configure-rv3028.sh" the systems says it is not found even though I am IN the directory where it resides. Oh, and I'm running a ver 6.3 Uputronics GPS hat

pi@RPi4b-NTP-GPS:~/gpsctl $ sudo configure-rv3028.sh sudo: configure-rv3028.sh: command not found

So if you have a fix for the above error, I think I have a complete, working system. If you are saying it is not a necessary step, then this should be good. I'll wait for you before I run the hwclock write.

Incidentally, on my first run at your build I got greedy and used a 64bit version of Bullseye. It failed early. I've seen this before where you can start old and work your way to current... But you can't start current. Ie: there is a HUGE difference in the presentation of /lib/udev/hwclock-set between a Buster and a Bullseye start point. Buster gives me exactly what you indicated. A Bullseye build does not.

[philrandal]

Use the full path to the configure script, or ./ in front of it.

I honestly can't replicate your issues.

I built from scratch using bullseye 64-bit, and fixed any errors that I found in my blog post in the process.

[Falcon-118]

Thanks, Phil. That worked. Seems to be fully working as per your cookbook. I'll clone this SD card before walking the update path.

Did you use a full raspian 64 bit load or the lite?

[philrandal]

I used the 64-bit Raspi OS lite build.

On Thu, 21 Sept 2023, 16:48 Falcon-118, @.***> wrote:

Thanks, Phil. That worked. Seems to be fully working as per your cookbook. I'll clone this SD card before walking the update path.

Did you use a full raspian 64 bit load or the lite?

— Reply to this email directly, view it on GitHub https://github.com/philrandal/gpsctl/issues/21#issuecomment-1729851822, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADRPDNFSCLJNPOMMPQREQDX3ROWJANCNFSM6AAAAAA5AJ5ENU . You are receiving this because you commented.Message ID: @.***>

[Falcon-118]

I sent this over to one of the kids who used to work for me, he stays pretty active in this stuff. He says judging by your build and note dates, he is guessing your build was in or before 2020? In which case the 64bit build would have been Debian 10 Buster. So maybe that is the catch. Who knows? After I clone and update... work in your auto update... do some testing and tuning... I may try an older 64 bit load out.

  Raspbian has only been available as ARMHF 32bit.
  Raspberry Pi ARMHF Operating System May 2020 onwards is based off Raspbian.
  Raspberry Pi ARM64 Beta and Early release Operating System was based off Debian 10 Buster. 

Also, just a tidbit from my past. I started my adult life as a US Navy fighter pilot and went on to work in the Dark World for a number of years. You really don't want to use GLONASS for time...

[philrandal]

My 64-bit build was bullseye

[Falcon-118]

Ok, I have working copies of your build both on 32bit and 64bit platforms. But even on the 64bit I had to revert to Buster to get things to work from your cookbook. Fortunately as I've gone through this process, I have two of the Uputronics hats and a few RPi4b/2GB. The key to the builds working completely is seeing the pps_core when you run lsmod.

The build works per your instructions with the latest 64bit Buster (2021-05-07) but not the earliest Bullseye (2021-10-30) from the Raspberry Pi archives. I think I've built your system up about 12 times now.

Curious, did you have access to an early Beta of 64bit Bullseye? Your latest postscript is dated October 17, 2020 but the earliest 64bit Bullseye image Raspberry Pi support could provide was October 30, 2021.

You are obviously more proficient with the Pi stuff than I am... Would you suggest upgrading to Bullseye before working on the auto-update and tuning or after? Either way, I'll get the 64bit image archived (so I don't have to build it again...) and start working on the rest of your document.

Thank you plowing this path. I'm glad to have this up and running for my pfSense box.

[philrandal]

I edited the blog post, and didn't update the postscript date or time.

Unfortunately I don't have the time to do a complete rebuild to triple-check.

I'll probably wait until the bookworm release of RaspiOS is released before trying a rebuild.

Sorry you're having so many issues.

[Falcon-118]

Waiting for Bookworm is probably the best bet. I understand about being busy, BTDT. Seems everything today eats more time with less rewards.

But... If/when you do decide to look into this, my offer to help with the testing and/or the documentation stands. My way of helping and saying thanks.

You should have my email in your gmail account listed on your Occasional Blog... or you can reach me here.

[Falcon-118]

Phil, everything seems to be running fine on this end, just doing some checking and cleanup. I notice when I view the gpsctl config file the top of the display shows entries for the Antenna and power... but those are not in the /etc/gpsctl.conf file. I am running an active u-Blox ANN-MB-00 (3.0-5.0vdc) antenna. Do those settings need to be set and if so, where? Or are they auto set?

pi@RPi4b-NTP-GPS:~ $ /usr/local/bin/gpsctl -a -Q config U-Blox GPS configuration Antenna: Power enabled: no Short detection: no Open detection: no Power down on short: no Auto recovery from short: no

[philrandal]

Short answer: The code is there to inspect.

I think those are just the defaults. I just parameterised the stuff in the original gpsctl when I forked it.

My main intent was to be able to enable Galileo support. Anything else was a bonus.

[philrandal]

I've rebuilt my server using bookworm 64-bit and updated my blog post to match.

ntp.conf updated to use ntpsec "refclock" lines instead of the old ntp.conf style "server" lines for our GPS clock sources.

[philrandal]

I didn't want to touch antenna power settings as I have no way of testing, sorry.

Also, the Uputronics HAT provides antenna power regardless.

[Falcon-118]

Phil, I've been up and running fine for a few weeks and seems very stable after a couple rounds of tuning. But since you posted the new updates for running under Bookworm, I wanted to give it a try. I have the extra RPi, hat and antenna.

Need some clarification if you will. Under the section where you edit ntp.conf (now moved from /etc to /etc/ntpsec) you used to have the "server 127.127.20.0 mode....." and the "fudge 127.127.20.0 flag1..." lines in the ntp.conf file. Those are no longer in that file or your example, but your very next line in the instructions still has your note: (Note that I used “fudge 127.127.20.0 time2 0.050....)

So should the note about server and fudge be omitted or do those lines need to be added back to ntp.conf under the NMEA section?

[philrandal]

The refclock lines replace the server / fudge pairs.

The links to the ntpsec docs explain the syntax.

I'll fix my blog post.

Now to get it working on my Pi 5.... Even after a change from ttyAMA0 to ttyAMA10, I'm getting "could not synchronise". Arrgh! Not sure when I'll have the time to dig deeper.

[Falcon-118]

Thanks, I'll play with this some more. I followed your new cookbook step for step but I'm having an issue getting the asterisk to move to NMEA instance. It wants to stay on the "preferred" server entry.

pi@RPi4b-NTP-GPS:~ $ ntpq -p remote

oPPS(0) .PPS. NMEA(0) .GPS. *montpelier.ilan.caltech.edu .GPS. -tick.usnogps.navy.mil .IRIG. +time-a-b.nist.gov .NIST. +timekeeper.isi.edu .GNSS.

[philrandal]

refclock nmea prefer minpoll 4 maxpoll 4 mode 8 stratum 2 baud 115200 time2 0.060 path /dev/ttyAMA0

Not sure if you need a prefer line on any of the other server lines

[Falcon-118]

OK, the cookbook still has "Note You MUST add a preferred server or PPS doesn’t work"

[philrandal]

That's in the refclock line

On Sun, 22 Oct 2023, 20:09 Falcon-118, @.***> wrote:

OK, the cookbook still has "Note You MUST add a preferred server or PPS doesn’t work"

— Reply to this email directly, view it on GitHub https://github.com/philrandal/gpsctl/issues/21#issuecomment-1774174672, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADRPDKAKLTX7STEF4G6KZ3YAVVPXAVCNFSM6AAAAAA5AJ5ENWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZUGE3TINRXGI . You are receiving this because you modified the open/close state.Message ID: @.***>

[Falcon-118]

OK, thanks... now NMEA is preferred. (you also still show the prefer in the section above on the first server stated)

Now that you are using refclock, is it still necessary to process the instructions in your June 21, 2020 postscript? re: rv3028 and hwclock, I ask because when I run timedatectl, RTC time shows n/a.

[philrandal]

If you're using a Uputronics HAT with built-in RTC, then my instructions should still apply.

[Falcon-118]

Thanks, Phil. I did do some research and reading on the RTC_UIE_ON error when you run the hwclock read. Surprised it hasn't been fixed yet in the OS.

ioctl(4, RTC_UIE_ON, 0): Invalid argument

Anyway, with your changes and updates, the system builds fine under bookworm. I'll play with the timing a bit then put it into production!

[Falcon-118]

Phil, I've let things run a day or more to stabilize with the antenna mounted outdoors. Starting in on the tuning.

Is there a slash missing on the command line between the ntpsec service stop/start?

It reads: sudo rm –f /var/log/ntpsec Should it be: sudo rm –f /var/log/ntpsec/

[philrandal]

Well spotted.

Tuning isn't that complicated - it's only for the pedantic who want to get as close as possible to perfection. The NMEA offset seems to vary depending on how many GPS satellites are in view at the time, probably due to processing overheads in the ublox chipset.

Also, you can point your browser at http://<your pi's IP address>/ntpviz for graphical stats.

[Falcon-118]

Well spotted.

I guess that's a nice way of saying "a bit anal"... and yeah, I've was accused of that most of my career, but it served me well. Agreed on the pedantic part, too... but not so intense. I'll run a couple of sessions and do some coarse tweeking. Maybe run through it again in a few months.

But, that said. Looks like you've now removed the lines referencing the 2 lines for stats 1 for filegen. So is there no edit needed of /etc/ntpsec/ntp.conf anymore?

You previously stated you replaced the server and fudge statements with refclock. But the cookbook still calls for "placing a noselect in the ntp.conf GPS line." (which is now the NMEA line) So do we add a noselect to the refclock statement before running for offset files to process?

You also still state "When you’re done, remove the noselect from the server 127.127.20.0 line in ntp.conf." But there is no longer a 127.127.20.0 line in the ntp.conf file. Confusing. Can you revisit the tuning section? it seems to be a mix of old an new.

I hope you don't look at this as complaining, it's not intended that way. I'd just like to get it right and I still think yours is the optimum approach for using the uputronics hat for a GPS/PPS/NTP server at this time and I'd like to steer others your way... to working roadmap.

And thanks for the access link to the graphical stats. That'll be very helpful the longer I run this.

[philrandal]

Some people say using gpsd as the clock source (using SHM) is better as its NMEA handling is allegedly better than ntpd's. I prefer to avoid middlemen where possible.

The NMEA clock offset calculation is a rough averaging exercise. I just guessed, ran for a while, adjusted, and so on iteratively without any noselect lines.

I've added linux-cpupower and a systemd unit for setting the "performance" cpu governor. This should give optimum stability.

[Falcon-118]

I'm new to all this GPS/NPT stuff... though I learned a fair bit about GPS and flew (Navy) with it's systems in the 80s before Reagan released it for public/commercial concerns. I had built several systems using GPSD prior to finding yours. While GPSD has some interesting aspects (like being able to monitor the live data via GPSMON). It just seemed to have too much overhead for a system that will go largely unmonitored. Not really analyzing if from an operational standpoint, but seeing the memory usage and the CPU usage by the heat load on the CPU... The previous build used almost all the onboard memory and using the High Pi Pro case with a PWM fan, the fan ran constantly. Your build is just the opposite, 2/3 of the memory is free and I've never seen a CPU temp over 45° C (and the minimum PWM control temp on the RPi is 60° C). Not worrying about where it is, what direction or how fast it is moving just seems like the best way to run a system with an antenna that is bolted to the side of my back deck on a custom built arm.

What really sucks is pfSense doesn't keep an accurate time display on it's NPT Status Dashboard widget even though it is now referencing a local Stratum 1 PPS instance. It has something to do with Nginx web code they use...

I'll look into your new stuff. Is it in the Occasional Blog?

[philrandal]

I've updated my blog. It would be interesting to see what your PPS jitter settles down as.

[Falcon-118]

Hey Phil... I did some more reading, asked a few folks I know in the business and gleaned a little bit of all... I tried to get my refids spread across the types but just couldn't get a IRIG that would run less than 3 digits in the integer side of the decimal point under delay. I also decided to attack the offset in small steps and work at it over time. It all seems to be working well under 64bit bookworm. The only thing I can't get working is getting "ntpsec.service" to auto start after a reboot?? Any Ideas?

But, again, a big thanks for your putting this all together, I'm happy with the end product... and it's just kinda cool. I posted it on the pfSense forum and I think a few more have built or are building systems based on your blog now as well.

[philrandal]

sudo systemctl enable ntpsec.service

should do it.

You, like me, are using time.google.com.

If there are every any more leap seconds announced this won't be wise, as Google do gradual adjustment of their time to deal with leap seconds, instead of leaping.

[Falcon-118]

Phil Eventually, the "systemctl" itself was the culprit... somehow it got compromised and was truncating input. I didn't find it but I stopped by the local JC maker space and asked for some help and was steered to a young lady who was their go-to for Raspberry Pi. She found the problem and once she got systemctl back to normal (removed/installed), we enabled ntpsec.service and it starts on boot now. She thought it was a cool project and wants to build one. So as thanks, I gave her my backup GPS hat and pointed her to your blog post. Now I need to order another backup hat.

Google thing: Are you talking about "leap smear" or something like that? If so, I read about that, but wasn't sure its impact...? Are all their time servers running in that mode? Or do you think it may become a standard across all REFIDs?

Do you have/know an IRIG server that has good returns? Every one I tried had 3 digit returns.