Update to Astronomy/Weather clock

[kshetline]

This is an update to a project I've posted about before: viewtopic.php?t=283134

Available here on Github: https://github.com/kshetline/aw-clock/



Browser-based demo: https://weather.shetline.com/

This is a clock that provides both astronomical and weather data, that can use wired and wireless temperature/humidity sensors for indoor/outdoor conditions, works with GPS for location and accurate time, can display leap seconds when they occur, etc. There's also a 3D printer file for creating a combo Pi mount/monitor stand.

What's new:

• I've added the option for a new weather service, Visual Crossing, to make up for the now-discontinued Dark Sky weather API. (Dark Sky isn't actually gone now – it was acquired by Apple, but you can't get API keys to use the service anymore.)
• You can now select from among available weather services with the UI, without having to edit a config file and reboot.
• I've added support for using a pool of multiple NTP servers, either a default pool or your own custom pool.
• The 3D stand has a number of improvements from the first version I created.

[K2PI]

Hi:

I've spent the better part of 4 days trying to install AW-Clock. I have used a Pi Zero 2W, Pi-3B+, and originally a Pi4 based on the example you showed. Unless I log in as root there are many errors in the build. Even then, I have yet to have AW-Clock execute after completing, even after reboots. I am using 32-Bit Raspbian Buster. Tried with and without my GPS Hat and sensor, and using the --ddev switch to try for basic functionality and defaults, but it never works.

I have tried all I can to make this work, assuming it was me, but have to ask if something is broken in the repository for the current Rpi OS? Help!

Thank you.

Bob

[kshetline]

I've spent the better part of 4 days trying to install AW-Clock...

I'm sorry to hear this has been giving you so much grief. I'm going to be publishing an up pretty soon (if not tonight, probably tomorrow) that strips a few things out of the installation procedure that might help it go more smoothly for you.

I'm usually working with my 2GB Pi 4, but just today I was trying to make sure my latest updates work on my old 1GB 3b+. I definitely had some problems with that myself, not with my own installer, but just getting my Pi to boot up without hanging after a fresh install of Bullseye. I know plenty of people are using Bullseye successfully on older hardware, but I'm beginning to have my doubts about that.

At this very moment I'm putting Buster back on my SD card to see if that goes more smoothly. I'll reply back when that's done.

[K2PI]

Thanks - I had the same issues on a Pi4 8GB, so it doesn't appear to be a resource issue. I didn't even try Buster 64, not wanting to compound my troubles. I'll look for the update, and thank you for the reply!

Bob

[kshetline]

I have tried all I can to make this work, assuming it was me, but have to ask if something is broken in the repository for the current Rpi OS? Help!

I've just released the new 3.0.0 version of the clock, and I was able to install it on my old Pi 3b+ without a problem.

Since I'm just doing this as a hobby project, and only have my own two Raspberry Pi(s) to play with, not a whole compatibility lab, I'm as baffled as anyone else why the installation works smoothly for some people, and not for others. I do what I can when people report errors that I can track down, but I imagine most people who have problems just move on to something else to work on.

It's great when people like you give me some feedback. If 3.0.0 still doesn't work for you, I'll try to get to the bottom of it if you can give me enough info to go on about what's different between your Pi and mine.

[K2PI]

Thanks, and I very much appreciate the volunteer work you put into a project like this. It is absolutely not lost on me. I look forward to getting this working and having a beautiful and useful display. I'll let you know how it goes.

Regards,

Bob

[K2PI]

Hi: Happy to report it's working beautifully - that build worked just fine on a Pi3B+ here. Doesn't appear to need a 4. Wonder if it'll work on a Pi Zero2W?

Can you kindly advise the best way to make sure that the clock is using it's internal pps source from the attached GPS? I see two icons on the screen to the left of the time. Once looks like a little satellite dish with some signal radiating upward from it, and the other looks like a typical cellphone rssi signal bar. The cellphone signal bar has a line through it, so not sure what that means. The GPS is synced, and ppstest shows good pps data coming in.

Thanks again!

Bob

[kshetline]

Hi: Happy to report it's working beautifully - that build worked just fine on a Pi3B+ here.

Glad to hear it's finally working. It's reassuring to have at least one data point that my recent installer changes helped.

Can you kindly advise the best way to make sure that the clock is using it's internal pps source from the attached GPS?

In the screenshots at the start of this post, you can see what those icons you describe look like when GPS sync is detected - lit up in bright green, with no slash through the signal bars. What the software is looking for, in part, is this:

Code: Select all

pi@clock:~ $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000   +0.000   0.001
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000   +0.000   0.001
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000   +0.000   0.001
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000   +0.000   0.001
*SHM(2)          .PPS.            0 l    9   64  377    0.000   -0.007   0.001
xSHM(0)          .GPS.            0 l   10   64  377    0.000  -586.75  58.377
-eterna.binary.n 128.138.140.44   2 u   79  128  377   62.565   +2.244   4.420
+t2.time.bf1.yah 98.139.133.62    2 u   53   64  377   28.750   +3.667  10.354
-65-100-46-164.d .SOCK.           1 u    3   64  377   88.300   +3.213   9.568
+time-ewr.0xt.ca 17.253.14.251    2 u   11   64  377   19.489   +2.813  12.572

The *SHM followed by the .PPS. is the key detail. More technically, my code looks for a line in the output of ntpq -p command that matches this regex:

Code: Select all

/^\*SHM\b.+\.PPS\.\s+0\s+l\s+.+?\s([-+]?[.\d]+)\s+[.\d]+\s*$/

...which is possibly stricter than it needs to be.

The output from gpspipe -w is also continuously monitored, tracking the TPV, SKY, and PPS items to check for location and location fix, signal-to-noise ratio, number of satellites being received, date/time, and time sync. This goes into determining how many signal bars to show.

Do the above commands work for you? Did the start of your installation look like this?

Code: Select all

pi@clock:~/aw-clock $ sudo ./build.sh -i
Checking installation pre-requisites...
Starting main installer...
- GPS test -
GPS time and location services found ✔
- Configuration -
Perform initial update/upgrade? (Y/n): 

...or more like this?

Code: Select all

pi@raspberrypi:~/aw-clock $ sudo ./build.sh -i
Checking installation pre-requisites...
Starting main installer...
- GPS test -
GPS time and/or location services not found
The following updates/changes are suggested if GPS support is desired:
  • Install gpsd and gpspipe
  • Install ntpd and ntpq
  • Install ppstest
- Configuration -
Perform initial update/upgrade? (Y/n):

[K2PI]

I don't remember the prompts on GPS during install; I let it run and came back to find it finished after I had answered the prompts. I did have pps working and had checked with GPSMON prior to building, so I had all that working fine.

I made the mistake of putting my local (GPS based) ntp server (also on a pi) in the NTP config, so it appeared to default to there. I removed it and rebooted after setting the config as you do at the end of the install page:
# GPS PPS reference
server 127.127.28.2 prefer
fudge 127.127.28.2 refid PPS

# get time from SHM from gpsd
server 127.127.28.0
fudge 127.127.28.0 refid GPS

When I do, and then look at ntpq -p I get:
pi@raspberrypi:~ $ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
0.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001
oPPS(0) .PPS. 0 l 7 16 377 0.000 -290.00 0.321
*SHM(0) .GPS. 1 l 4 16 377 0.000 +4.782 4.952
SHM(2) .SHM2. 0 l - 16 0 0.000 +0.000 0.000
time.skylineser 130.207.244.240 2 u 50 64 1 37.196 -285.61 0.322
+ntp1.ring-u.net 130.207.244.240 2 u 49 64 1 28.878 -280.98 1.622
+50-205-244-108- 50.205.244.27 2 u 47 64 1 27.833 -287.90 3.220
sonic.boom.net 128.9.176.30 2 u 57 64 1 71.871 -284.30 0.001

It appears to be locking on to SHM(0) which seems to be NMEA level gps, but maybe I am reading this wrong?

Also - how do you restart the display once you quit out without rebooting?

Thanks,

Bob

[kshetline]

When I do, and then look at ntpq -p I get:

I don't understand the ntpq output well enough to know whether this indicates proper PPS sync, just in a different way than I'm getting PPS sync, or if you're syncing with GPS without any better accuracy than you'd get from a USB GPS with no PPS signal. The documentation I've found online for ntpq so far hasn't been detailed enough to clear up my understanding of the output. I've just posted a question on StackOverflow, so hopefully I'll get some feedback there.

In the meantime, does your /boot/config.txt file contain this line?

dtoverlay=pps-gpio,gpiopin=4

[kshetline]

According to this documentation:

The first character displayed in the table (Select Field tally code) is a state flag (see Peer Status Word) that follows the sequence ” “, “x”, “-“, “#”, “+”, “*”, “o”:

” ” – No state indicated for:
non-communicating remote machines,
“LOCAL” for this local host,
(unutilised) high stratum servers,
remote machines that are themselves using this host as their synchronisation reference;
“x” – Out of tolerance, do not use (discarded by intersection algorithm);
“–” – Out of tolerance, do not use (discarded by the cluster algorithm);
“#” – Good remote peer or server but not utilised (not among the first six peers sorted by synchronization distance, ready as a backup source);
“+” – Good and a preferred remote peer or server (included by the combine algorithm);
“*” – The remote peer or server presently used as the primary reference;
“o” – PPS peer (when the prefer peer is valid). The actual system synchronization is derived from a pulse-per-second (PPS) signal, either indirectly via the PPS reference clock driver or directly via kernel interface.

...the "oPPS" says the "The actual system synchronization" is coming from PPS, so I'm leaning toward thinking this is simply a different way that valid PPS sync can be indicated.

Would you be up for trying to make a code change in the project if I post some suggested code changes for you?

[kshetline]

Also - how do you restart the display once you quit out without rebooting?

I take it you mean if you quit the web browser. If so, just open Chrome again, go to "http://localhost:8080/", and switch to full screen mode.

[K2PI]

Thanks for the notes. I completely uninstalled the GPS tools and NTP and reinstalled, and cleaned up the configs. I am now showing the right indications. I think I had played around with too many configs based on two separate chains of how to get pps working found here:
https://katron.org/blog/2021/10/raspberry-pi-gps/
https://n4bfr.com/2021/11/raspberry-pi- ... -bullseye/

All is well now, and I see a good signal strength (assume that is sat strength?) and a green antenna. My view with ntpq is also showing the same as your earlier example.

I'd be happy to help test code. It's the least I can do to help pay you back for the development and your recent support.

Bob

[kshetline]

I'd be happy to help test code. It's the least I can do to help pay you back for the development and your recent support.

Great news. No need to try out any code changes, however. I was only proposing changes in case your previous ntpq output was an alternate valid result. I suspect now that it wasn't valid. The -290ms offset value was pretty suspicious anyway.

My ad hoc rules for what I'm calling signal quality (that's not something directly reported by the GPS hardware), which determines how many bars you get, can be seen in the file gps.ts, in the method monitorGps(). It's a combination factors like whether or not there's signal fix (quality goes straight down to 0 if you can't get a fix), whether or not PPS is available, average signal-to-noise ratio, and position error.

[K2PI]

Great. I have all but one bar, so I must be in pretty good shape. Very impressive application, and now has a place in our kitchen. Thanks for producing this and all the time you spent helping me troubleshoot.

[K2PI]

I notice that when there is a weather alert (chiron on bottom of screen) the clock second hand pauses then skips ahead randomly. Is this the code holding it back, or the Pi? I am running on a Pi4.

Thanks.

[K2PI]

KShetline,

I have managed to successfully update to the new version, but the autostart is broken. The lock attempts it, but fails after timing out, then clicking past that I receive an error code 5 from Chromium, and an option to restart, which then works. Any advice on where to look to see what it happening much appreciated.

Thanks.

[kshetline]

I have managed to successfully update to the new version, but the autostart is broken. The lock attempts it, but fails after timing out, then clicking past that I receive an error code 5 from Chromium, and an option to restart, which then works. Any advice on where to look to see what it happening much appreciated.

I'm sorry I've been away from this forum for a while and hadn't noticed this message until just now. Do you still have this problem?

One of the issues I had to solve for the autostart was one where Chromium didn't shut down cleanly, and I needed to repair the /home/pi/.config/chromium/Default/Preferences file to make Chromium cleanly start up. You could try quitting Chromium and deleting this file to see if that solves the problem.

[kshetline]

I notice that when there is a weather alert (chiron on bottom of screen) the clock second hand pauses then skips ahead randomly. Is this the code holding it back, or the Pi? I am running on a Pi4.

A Raspberry Pi certainly isn't a graphics powerhouse, and it does take a bit of extra computational effort to scroll the chyron, but the worst I've seen is a bit of jumpiness of the second hand on a Pi 3, not on my 4.

There's code to make the animation smoother, which turns off the animation of the second hand when the chyron is scrolling. (Normally the second hand sweeps through the space from one second to the next, with a bit of a mechanical bounce. When the chyron is scrolling, the second hand simply skips directly from second to second.) That logic depends on detecting that the code is running on a Raspberry Pi, however, so that the second hand animation can be maintained on faster computers.

For a little while the Raspbian test was broken because the Chrome browser stopped clearing identifying itself as running on Raspbian, and instead merely declared "Linux armv" in its user agent. I fixed that test back in March, however, so an update to the latest clock code should fix your problem unless something else is bogging down the speed of your Pi.