I’ve followed a number of different directions, and each time I get results that differ. However, in the past 24 hours I’ve been using an ntp.conf file that I found here. This one has proved more reliable than the one that I got from frillip.com’s site. There’s little difference that I can see, but something made enough difference that I’ve been able to let the box reboot (pull power, or sudo reboot) several times and each time it comes back up properly. gpsd, ntpd, dire wolf, and the HP ADDC example.py all start running orderly and without mysteriosities.

I did discover that the fudge value for ntp seemed to be important – the link above used a time fudge of 0.5 seconds, and it was not reliably syncing on that. I moved time fudge to 0.3 seconds, and suddenly reliable. So I figure the offset between the GPS reported time and the pps from the GPS was tighter than the author at the above link was using (he was at 4800 baud, my GPS is at 9600 baud). I tried a time fudge of 0.0 and that seemed to work, but not all the time.

Figure 2 is the results of the top command for the setup running all those processes.

The unit is an RPiB3+, with USB sound card, GPS wired in on serial0, and the High-Precision AD/DA board as a hat. 15% CPU usage is pretty decent. dire wolf is definitely the most power hungry. I still haven’t connected a transceiver to this, so I’m just processing inbound received packets from a scanner’s audio output.

I have a Baofeng UV5 transceiver, and just liberated the mic cable from one of the $5 speaker-mics available on Amazon, so I’ll breadboard up a PTT interface now. The important thing with the PPT is that the RPi is 3.3 V logic level, and I need to pull down the Baofeng PTT line. I will use a 2N3904 NPN transistor as an open collector switch to do the job. I’ve also ordered some CMOS 555 timers in order to build a PTT timeout circuit, so that if the RPi hangs for some reason the radio won’t transmit indefinitely. Maybe 2 seconds for a PTT timeout?