#!/bin/bash
#
# Script to control Direwolf state based on physical switch status
#
# Control switch input is a BCD thumb wheel connected as follows:
# - IO22 - WiringPi: 3 - BCD 8 complement - HD15 pin 12
# - IO24 - WiringPi: 5 - BCD 4 complement - HD15 pin 11
# - IO27 - WiringPi: 2 - BCD 2 complement - HD15 pin 14
# - IO6 - WiringPi: 22 - BCD 1 complement - HD15 pin 1
#
# Modes are as follows:
# 0 - Off
# 1 - Beacon VHF+iGate
# 2 - Beacon VHF+HF+iGate
# 3 - Private digipeat VHF (+iGate)
# 4 - Private digipeat VHF+HF
# 5 - Public digipeat VHF
# 6 - Public iGate VHF
# 7 - Receive only (+iGate)
# 8 - Spare (off)
# 9 - Spare (off)
#
#
# First make sure that the PTT lines are set as output and set to 0 (off)
# Seems to be a problem with a reboot leaving them configured as inputs and drifting high...

/usr/bin/gpio -g mode 12 out
/usr/bin/gpio -g mode 23 out
/usr/bin/gpio -g write 12 0
/usr/bin/gpio -g write 23 0

# Variable 'mode' contains the current state of direwolf
#
# Config files are of the form: /usr/local/bin/direwolf-modeX-config

# First set dummy config file
/bin/echo "# Waiting for GPSD" > /tmp/direwolf.conf

declare -i mode=0
declare -i new_mode

/usr/bin/gpio mode 3 in # BCD 8 complement
/usr/bin/gpio mode 3 up # Enable weak pull-up
/usr/bin/gpio mode 5 in # BCD 4 complement
/usr/bin/gpio mode 5 up # Enable weak pull-up
/usr/bin/gpio mode 2 in # BCD 2 complement 
/usr/bin/gpio mode 2 up # Enable weak pull-up
/usr/bin/gpio mode 22 in # BCD 1 complement 
/usr/bin/gpio mode 22 up # Enable weak pull-up

# Wait here until gpsd is running as Direwolf won't work properly for tracking unless gpsd is running

while [ ! -e /run/gpsd/gpsd.pid ]; do
 /bin/sleep 5
done

# gpsd started OK, now set a dummy config file

/bin/echo "# Direwolf not started" > /tmp/direwolf.conf

while true; do 
 /bin/sleep 5 

 # Get the current thumb wheel switch value 
 let "new_mode = $(/usr/bin/gpio read 3)" 
 let "new_mode = new_mode << 1" 
 let "new_mode += $(/usr/bin/gpio read 5)" 
 let "new_mode = new_mode << 1" 
 let "new_mode += $(/usr/bin/gpio read 2)" 
 let "new_mode = new_mode << 1" 
 let "new_mode += $(/usr/bin/gpio read 22)" 

 if [ $new_mode = $mode ] 
 then 
 # No change to mode, so just loop 
     continue
 fi 
 case $new_mode in 

 0|8|9|10|11|12|13|14|15) 
     # New mode is off or undefined, so change to off mode 
     if [ $mode != 0 ]
     then
         systemctl stop direwolf.service 
         /bin/echo "# Direwolf stopped" > /tmp/direwolf.conf
         mode=0 
     fi
     ;; 

 *) 
     # Change to new mode by replacing the configuration file and 
     # restarting Direwolf 
     cp /usr/local/bin/direwolf-mode${new_mode}-config /tmp/direwolf.conf 
     systemctl restart direwolf.service 
     mode=$new_mode 
     ;; 

 esac 

done

direwolf-mode1-config

$sudo systemctl enable direwolf-mode.service

As noted in the script above, there seems to be a problem with the PTT lines defaulting to transmit on power up. The script resets them as soon as it starts, but there is still a period while the OS boots where the PTT is active that can result in a carrier being transmitted for a few seconds. Haven’t found a work-around as yet. [Update April 2017: NWDR has come up with a hardware work around for this problem. See this app note.]

Setting up the GPS and providing time to the Raspberry Pi

One of the challenges of running a RPi in a mobile setting where it doesn’t have access to the Internet is maintaining the system time. The Rapberry Pi doesn’t have a battery backup on the clock and relies on syncing to Internet time servers on power up. If there is no Internet connection, the time continues on from  a saved value (by fake-hwclock) at the last power down. We have, however, a very accurate time source in the form of GPS and it is not hard to make the Raspberry Pi use this for syncing the system time.

The default version of gpsd in the Raspian distribution (and Compass) seems to be a bit unreliable in updating the shared memory segments. I found I needed to manually install the most recent version of gpsd for reliability. In my case this is v3.16 and it can be downloaded from here: https://download-mirror.savannah.gnu.org/releases/gpsd/

Once gpsd is installed, you can configure NTP to use it as a time source by changing the /etc/ntp.conf file to the following:

 pool au.pool.ntp.org minpoll 8 iburst    # change the pool for your appropriate region

 driftfile /var/log/persistent/ntp.drift
 logfile /var/log/ntp.log

 restrict default kod nomodify notrap nopeer noquery
 restrict 127.0.0.1 mask 255.255.255.0

 # GPS Serial data reference - access via shared memory inter-process communication
 server 127.127.28.0 prefer true
 fudge 127.127.28.0 time1 +0.075 refid GPSD stratum 1

 # time1 +0.075 adjusts for delays through the USB interface (needs to 
 # be adjusted for the specific hardware for best accuracy, but not 
 # essential for this application)

A complication is that gpsd is by default configured to start only when a client application connects to it and so won’t provide timing information to NTP through the shared memory interface until something like Direwolf connects to it. This can be fixed through the initialisation scripts as follows:

$sudo cp /lib/systemd/system/gpsd.service /etc/systemd/system

Add the following line to /etc/systemd/system/gps.service [Unit] section:

Before=direwolf-mode.service

This makes sure gpsd is started before direwolf-mode service.

Add the following line to /etc/systemd/system/gps.service [Install] section:

WantedBy=multi-user.target

This tells SystemD to start gpsd as part of bringing up the multi-user target (which represent the system up and running in multi-user mode).

Finally tell SystemD that something has changed (rebooting also works) and enable gpsd for automatic start:

$sudo systemctl daemon-reload
$sudo systemctl enable gpsd

You can check that NTP is getting the time from the gps with the following command:

$ntpq -p

The output should look something like this:

  remote refid st t when poll reach delay offset jitter
==============================================================================
+ns2.unico.com.a 27.124.125.252 3 u 81 256 1 0.471 76.026 0.943
+a.pool.ntp.uq.e 27.124.125.252 3 u 80 256 1 0.209 73.916 1.696
+ntp.2000cn.com. 27.124.125.252 3 u 79 256 1 0.466 73.684 1.806
+ntp3.syrahost.c 27.124.125.252 3 u 78 256 1 0.269 73.917 1.426
*SHM(0) .GPSD. 1 l 23 64 3 0.000 69.758 8.381

The asterisk next to the GPS shows that it is the primary source of time. Other lines will only appear if the Raspberry Pi is connected to the Internet.

The final tweak for gpsd is to pass it the -n option which forces the daemon to start querying the gps even before a client connects. This is needed to make sure it is populating the shared memory for ntp when nothing else is using it. This is a simple change to /etc/default/gpsd – just add the -n to the GPSD_OPTIONS variable:

GPSD_OPTIONS="-n"

Hardening the Raspberry Pi

One of the limitations of the Raspberry Pi for embedded applications is that it uses a micro-SD card as its primary storage. The issue is that SD cards have a finite service life based on the number of writes to them. In an application like Linux, there are many writes made to the card as various parameters are updated and this can lead to a relatively short life with random errors and failures appearing over time. A second issue for embedded systems is that Linux is not designed to be arbitrarily stopped with a power switch. This can lead to file corruption and consequent instability.

Overlay filesystem

One of the best ways to mitigate both these issues is to change the root file system to read-only. This would be fine except for all those files that actually need to be written and modified during the normal execution! There is however a neat solution to this problem – Overlay Filesystem – which is now built into the Linux kernel. This is a slightly complex, but very useful capability which creates essentially a merged filesystem with an “upper” and “lower” layer. In our case, we can set the “lower” layer to be the read-only root filesystem and the “upper” layer to be a RAM-based temporary filesystem to store those files that are changed during operation. When the power is cycled, the system will come up in the state of the “lower” file system which is in a clean state.

The final component needed is somewhere to store persistent data that needs to remain across reboots (such as log files and a small number of other variables).

Fortunately, there are a number of scripts around that simplify the creation of such an environment. For this project, I’ve used one created by Pavel Pisa from Czech Technical University, Prague. Here’s a presentation describing it: init-overlay. Setting this up is fairly straight forward:

$cd /sbin
$sudo wget https://github.com/ppisa/rpi-utils/raw/master/init-overlay/sbin/init-overlay
$sudo wget https://github.com/ppisa/rpi-utils/raw/master/init-overlay/sbin/overlayctl
$sudo chmod +x init-overlay overlayctl
$sudo mkdir /overlay 
$sudo overlayctl install 
$sudo reboot

This is all that’s needed! Read the contents of the two scripts to understand what they are doing if you are interested.

Once the overlay filesystem is active, you can’t update the underlying base system (as it’s read-only). So when you need to make changes, you need to deactivate the overlay filesystem. This is simply accomplished using the ‘overlayctl’ script:

$ sudo overlayctl disable
$ sudo reboot

Similarly, it can be re-enabled:

$ sudo overlayctl enable
$ sudo reboot

Persistent storage

Finally, we need persistent storage for log files etc. Create a directory for other persistent data:

$sudo mkdir /var/log/persistent
$sudo chmod go+wt /var/log/persistent

Key data that needs to be persistent is:

• Saved clock time (fake-hwclock)
• NTP drift file

Fix up fake-hwclock by adding the following to /etc/default/fake-hwclock:

FILE=/var/log/persistent/fake-hwclock.data

We also need to make sure fake-hwclock doesn’t start until the filesystems are mounted. This is achieved by adding to the fake-hwclock.service scripts as follows:

$cd /etc/systemd/system
$sudo cp /lib/systemd/system/fake-hwclock.service .

We then edit the .service file and add the following line to the [Unit] section and comment out the Before= line:

After=local-fs.target
#Before=sysinit.target

The NTP drift file is solved using the line in the ntp.conf file earlier in this article.

Watchdog

Finally we need to harden the pi against random lockups and problems using the hardware watchdog built into the Raspberry Pi. This is a piece of hardware built into the processor that continually counts down a counter – if it ever reaches zero, a hard reset is generated. There is a watchdog daemon that “feeds” the watchdog by reseting the counter periodically. The following commands will enable the watchdog:

$sudo apt-get install watchdog

Modify /etc/watchdog to set the device line as follows:

watchdog-device = /dev/watchdog

Edit the /etc/systemd/system/watchdog.service file to include autostart by copying as follows:

$sudo cp /lib/systemd/system/watchdog.service .

Then edit the file to add this line:

[Install]
WantedBy=multi-user.target

 kernel.panic = 10

At this point it would be prudent to take a backup of your SD card in case anything goes wrong in the future. I use the built-in SD Copier command on the accessories menu of the latest release of Raspbian.

That should be all that you need for a high reliability tracker/digipeater/iGate!

Here’s an image from aprs.fi of a recent SOTA expedition to Mt Howitt in the Victorian high country. You will see tracking of the car (orange line) and tracking of my HT (blue line) which was digipeated from the car. Looking at the raw packets, the digipeating of the HT used at least 2 VHF digis and a few HF gateways to provide fairly continuous coverage of the hike.