Ook de aanpassingen aan de configuratie van het Draytek Vigor 130 modem gaven niet het gewenste resultaat: zondag was er weer uitval. Dus het is niet een conflict tussen de pppoe client op mijn router en die in het Draytek Vigor 130 modem.

Om nu meer richting een ondersteunde configuratie te komen heb ik de nieuwste firmware er op gezet maar dan met de 'modem5' vectored VDSL driver. Ik hoop dat dat een betere situatie oplevert. De 'modem5' driver is volgens Draytek documentatie 'optimized for KPN'. Die levert wel wat meer vertraging op, maar dat is in de orde van milliseconden.

En als extra aanpak van het probleem heb ik een script geschreven wat het modem vraagt om een vdsl herstart. Dit script roep ik aan als het er alle tekenen van heeft dat de verbinding naar buiten weg is.

Again and again systemd annoys me. This time in the GPS Pi configured for timing.

Since I want it to work perfectly at start I added the systemd rules as suggested by A Raspberry Pi Stratum 1 NTP Server - Phil's Occasional Blog with /etc/systemd/system/ublox-init.service containing:

[Unit]
Description=u-blox initialisation
Before=gpsd.service
Before=ntp.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/gpsctl -q -a -B 115200 --configure_for_timing

[Install]
WantedBy=multi-user.target

After reboot ntp was running, but no data at all from the gps unit, and gpsctl was unable to revive it. The solution was to disable the above unit and ntpd, powerdown and restart the whole system and try again. After that doing the changes by hand and starting ntpd worked fine.

It's probably some sort of race condition, but any time I try to make a system with systemd do something reliably I run into things like this.

De vervelende lange onderbrekingen van de Internet verbinding bleven aanhouden en ik zocht hulp in de xs4all.adsl nieuwsgroep.

Ik kreeg een suggestie om de configuratie van het Draytek Vigor 130 modem aan te passen. Ondanks dat deze in PPPoE passthrough staat blijft de interne PPPoE client toch proberen om een verbinding op te bouwen. En dat geeft een probleem als het proberen op te bouwen van een nieuwe sessie een conflict geeft met een oude sessie wat alleen op te lossen is door een tijdje te wachten.

De suggestie was ook om logging van het Draytek Vigor 130 modem aan te zetten naar een syslog server zodat het zichtbaar werd wat er gebeurde. En dat gaf meer informatie wat inderdaad aangaf dat de PPPoE client op de Draytek Vigor 130 modem storing gaf.

Based on A Raspberry Pi Stratum 1 NTP Server - Phil's Occasional Blog I switched the gps to a configuration optimized for timing. The default settings are optimized for location services, but I want an NTP server.

I used gpsctl to configure the ublox chip in the GPS/RTC Hat:

$ gpsctl -a -B 115200 --configure_for_timing -vv
Serial port ("/dev/ttyAMA0") open...
Serial port open and configured...
Automatically determining baud rate...
Trying 230400 baud...
Trying 115200 baud...
Trying 57600 baud...
Trying 38400 baud...
Trying 19200 baud...
Trying 9600 baud...
Synchronized on 9600 baud...
Changing baud rate to 115200...
Successfully changed baud rate to 115200...

After that I got location data at a high speed. I changed the /etc/ntp.conf parameters to use the GPS_NMEA and PPS drivers, with:

# PPS reference
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 refid PPS

# GPS NMEA driver
server 127.127.20.0 mode 89 minpoll 4 maxpoll 4 iburst prefer
fudge 127.127.20.0 flag1 0 flag2 0 flag3 0 time2 0.043 refid GPS

And now I get much better numbers:

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l   14   16  377    0.000   -1.656   0.134
*GPS_NMEA(0)     .GPS.            2 l   13   16  377    0.000  -11.730   0.517
+ntpritchie.idef 131.211.8.244    3 u   44   64  377    4.263    1.436  62.373
+metronoom.dmz.c 192.87.106.3     2 u   44   64  377   12.141   -2.250  49.247
koos@henkp:~ $ ntpdc -c kern
pll offset:           -0.00142676 s
pll frequency:        7.468 ppm
maximum error:        4.934e-06 s
estimated error:      3.372e-06 s
status:               2001  pll nano
pll time constant:    4
precision:            1e-09 s
frequency tolerance:  500 ppm

The time offset factors still need work, but I'm getting close!

I remembered the junkbox contains an active GPS antenna which I bought together with the gpskit gps unit in 2003(!). And some other bits and pieces included a SMA to BNC adapter so I put the little GPS antenna outside and connected it to the GPS/RTC Hat.

Before I was back behind a computer it was showing a location and within a few minutes it had a PPS pulse. I was used to cold start taking at least 15 minutes with the gpskit!

So I tested with ntpd talking to gpsd via shared memory. This gave an interesting offset between local gps time and a nearby ntp server.

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*SHM(2)          .PPS.            0 l    6   64  377    0.000   -0.149   1.672
xSHM(0)          .GPS.            0 l    5   64  377    0.000  -104.51   1.943
+ntpritchie.idef 131.211.8.244    3 u  101   64  376    2.774    0.950  13.948
+metronoom.dmz.c 131.211.8.252    2 u   99   64  376   10.482   -0.844  10.638
$ ntpdc -c kern
pll offset:           -0.000136461 s
pll frequency:        -11.054 ppm
maximum error:        1.3748e-05 s
estimated error:      1.7071e-05 s
status:               2001  pll nano
pll time constant:    6
precision:            1e-09 s
frequency tolerance:  500 ppm

I'm not too happy about the fact that the GPS NMEA messages are seen as wrong, so I'm going to stop using gpsd and go for a setup optimized for timing.

With most of the hardware in, it is time to configure the Raspberry Pi to allow the GPS/RTC board to be installed. One tip was to do this before installing the board to avoid serial conflicts.

First steps based on Building a GPS Time Server with the Raspberry Pi 3 which uses a different GPS board.

Disabling tty service on the UART:

# systemctl stop serial-getty@ttyAMA0.service
# systemctl disable serial-getty@ttyAMA0.service

And make changes to /boot/cmdline.txt to disable serial console, removing the console=serial0,115200 part.

Also needed is to disable the use of the hardware uart for bluetooth. This device does not need to do bluetooth at all, so I disable the software.

sudo systemctl disable hciuart

And add the lines to disable the bluetooth uart to /boot/config.txt:

dtoverlay=pi3-disable-bt

And with that the UART is completely free to use for GPS and PPS messages. I made all these changes and only added the GPS/RTC hat to the Pi after these changes were done.

Next steps were to add the i2c settings according to the GPS/RTC manual. For this I added

dtoverlay=i2c-rtc,rv3028
dtoverlay=pps-gpio

And indeed the i2c bus appears as the manual says:

# apt-get install python-smbus i2c-tools
[..]
# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- 42 -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

I removed the fake-hwclock package and tested operation. On the commandline it works, but in a reboot I still see weird times in the log.

After that I did the changes to /lib/udev/hwclock-set, now it looks like:

dev=$1

#if [ -e /run/systemd/system ] ; then
#    exit 0
#fi
if [ -e /run/udev/hwclock-set ]; then
    exit 0
fi

if [ -f /etc/default/rcS ] ; then
    . /etc/default/rcS
fi

# These defaults are user-overridable in /etc/default/hwclock
BADYEAR=no
HWCLOCKACCESS=yes
HWCLOCKPARS=
HCTOSYS_DEVICE=rtc0
if [ -f /etc/default/hwclock ] ; then
    . /etc/default/hwclock
fi

if [ yes = "$BADYEAR" ] ; then
#    /sbin/hwclock --rtc=$dev --systz --badyear
    /sbin/hwclock --rtc=$dev --hctosys --badyear
else
#    /sbin/hwclock --rtc=$dev --systz
    /sbin/hwclock --rtc=$dev --hctosys
fi

# Note 'touch' may not be available in initramfs
> /run/udev/hwclock-set

The rtc has to be configured correctly, I used information from A Raspberry Pi Stratum 1 NTP Server - Phil's Occasional Blog to configure the rv3028 chip. Get the gpsctl tool and use configure-rv3208.sh to set up the chip. Now the rtc is correct and used at boot time.

I'm seeing NMEA messages when I run gpsd or ask the serial port for data. The NMEA messages are very limited because there is no GPS antenna connected yet.

Social media is a nice and easy way to interact with people. There was and is a lot of choice in social media. Ages ago I started with fidonet echomail groups, later with usenet and recently with web-based social media.

But that's also a development from volunteer-run systems to commercially run systems. Companies like twitter, google and facebook are in the world to make a profit. With echomail and usenet the protocols and software were not linked to the operator of the service, someone else was able to run the same service and allow access to the network again. When google+ stopped the ties to people I knew were broken and I had to find them again on other networks.

I am somewhat active on twitter. My 'main' twitter account is twitter.com/khoos but I was getting a lot of negative messages about world politics which got depressing. Since twitter has made it a lot easier to manage more than one twitter account from the twitter web interface I decided to add a specific account for amateur radio with the predictable name twitter.com/PE4KH. Amateur radio twitter is not completely free of politics, but it's a lot more sane view of twitter.

The Raspberry Pi GPS/RTC Expansion Board from uputronics came in today (thanks mailman!).

Next part needed: a gps antenna. But that's on backorder with another supplier.

Also needed: time to install raspbian on the Pi and start testing.

Some time ago I saw announcements of an igate build project from PI4RAZ, the amateur radio club in Zoetermeer. An igate is a system that receives APRS messages and forwards them to the Internet aprs servers.

There is a distinct lack of APRS coverage here in Utrecht, so more places that receive those messages and pass them to the Internet are a good idea. A specialized repeater to repeat them on the air would be even better, but that needs a special radio license which is one step too far and expensive at the moment for me.

The electronics came in months ago, but time to pick up the soldering iron and start with the hard part wasn't available. I started this monday with that hard part: soldering a VHF module on top using something close to surface mounting. Just with a lot more space between the soldering islands than real surface mount. Still needed good light and a magnifying glass to check my work constantly. I only had to desolder one small blob of solder which went in the wrong direction.

After that I soldered the resistors. That went fine. After that my eyes were too tired, but the first step has been made.

As I mentioned before I have some future cycling goals which include some form of long-distance cycling journey, with serious influences from the book Computing Across America. Naturally amateur radio will play a part in such a cycling journey, just as Steven K. Roberts had on his trips.

Via the german amateur radio club DARC I found this bit in the "Deutschland-Rundspruch 24/2020":

DK3JB erreicht erstes Ziel auf seiner Funk-Fahrrad-Reise

Hans-Gerhard Maiwald, DK3JB, hat nach mühsamer und beschwerlicher Fahrt, teilweise auch wegen schlechter Radwege, am 15. Juni gegen 21 Uhr sein erstes Ziel, Kappel im Hochschwarzwald, erreicht. Dabei legte er ohne E-Unterstützung 580 km mit seinem 40 kg schweren Radanhänger zurück. Dem 72-jährigen OM geht es gesundheitlich gut. Hans-Gerhard gelang es, den weitaus größten Teil der Strecke permanent mit seinem TH-D74 in APRS aufzuzeichnen. Dabei hat sich der 1200 g schwere 12 V/20-Ah-Lithium-Ionen-Akku sehr bewährt. DK3JB hat zahlreiche Verbindungen in FM und D-Star vom Fahrrad aus getätigt. Durch Ludwigshafen wurde er von mehreren Funkamateuren gelotst und seine Route mitverfolgt. Hans-Gerhard bleibt bis Sonntag in Kappel und radelt danach vorerst an den Bodensee weiter.

And I found out more about the cycling tours between Siegen and Friedrichshafen in Germany via Funk-Fahrradtouren of DK3JB and it is very inspiring to me. There is also an article DK3JB wieder mit dem Fahrrad unterwegs nach Friedrichshafen - funkamateur.de with information about this tour in 2020 (all in German, which I can read but not really write). He has done this tour several years already, I found an article from the June 2008 trip: Mit Fahrrad, Zelft und FTM-10SE durch Süddeutschland (pdf).

After having read a book about cycling through Europe with the Rhine as one possible route, this confirms my earlier thoughts. Combining recumbent cycling, amateur radio and a nice ride through Europe is the direction I'm thinking.

I wanted to do some things in the shed with cabling, some things were not ideal after the solar power installation.

One of the things was that I had a temperature sensor to measure the temperature above the roof, but with all things that happened with cables it ended up hanging below the roof. I moved it back up in the ventilation pipe and with the current temperatures it started measuring 4 degrees Celcius higher immediately.

And yet another Raspberry Pi is showing up for my home network. This will become the GPS-based timeserver. I may add it to the NTP Pool when I'm satisfied enough with it.

It will probably also replace the 'shed' weather station computer in the long run, to save on power use.

I added an extra USB-based wifi adapter to the Pi. The shed has no wired network and my experience with the other computer there is that dual-band (2.4 GHz and 5 GHz) wifi support is the best way to have a chance to get working network.

I also ordered the Raspberry Pi GPS/RTC Expansion Board directly from uputronics.

After earlier tries to have a nice GPS-based timeserver for my home network I noticed a simple but very effective GPS 'hat' for the Raspberry Pi, the Raspberry Pi GPS Hat from Uputronix. While the Pi's are already taking over the home network just one more could be a nice addition. In the longer run this will probably replace the shed computer.

So I ordered a Pi with an added dual-band WiFi adapter, a case, the GPS hat and a GPS antenna. The GPS hat has PPS support so I will get the time correct. With the instructions from 5 minute guide to making a GPS Locked Stratum 1 NTP Server with a Raspberry Pi it should be easy. If this all works I may even add the resulting Pi to the IPv6 NTP Pool.

Update 2020-06-16: SOS Solutions came back with some bad news: the uputronix Pi GPS Hat isn't available anymore. I'm now looking at the comparable adafruit hardware which is somewhat more expensive, but offers the same options.

Update 2020-06-18: And the adafruit hardware is also not available soon. I cancelled the GPS unit part of the order and I'm looking at sourcing a GPS module for the Pi from another source. The GPS hat which sossolutions no longer sells is originally from uputronics where a newer version of the Raspberry Pi GPS/RTC Expansion Board is listed as available on the site. Based on a ublox chipset which allows me access to a lot of the GPS data.