APRS Telemetry Watcher is a simple, slick interface that connects (in my case) via a network connection to an RPi in my shack running dire wolf APRS software. APRS-TW looks for telemetry packets, then displays them in a nice graphical format.

Figure 1 – APRS-TW GUI showing two of my APRS stations’ telemetry values

It’s a simple piece of software, runs in a Windows environment, and the individual telemetry values, names, units, etc., can all be filled in the GUI so that the data that appears is already in engineering units. (i.e., instead of a telemetry value of “491”, it’s actually 12.73 Vdc.

This is handy. Is a nice complement to aprs.fi.

how not to be seen

With apologies to Monty Python.

While I’m not Mr. B. J. Smegma, I want to build another Desert Machine that I can place somewhere in the local desert.

Ok, so what’s a Desert Machine?

A long time ago, the original Desert Machine was conceived of, designed, built, tested, and placed out in the Mojave Desert by a group of us, some place in the Mid Hills / New York mountains area, next to an abandoned mine.

A simple box, consisting of a crystal-controlled 40-m transmitter producing maybe 1 W, connected to a “found” abandoned phone line wire strung along multiple decayed telephone poles, aligned in a row more or less allowing the transmitter to feed the NE end of the wire and the SW end of the wire pointing toward LA. A really simple telemetry circuit made of a pair of 555 timers, with one using a thermistor in the timing RC circuit, created a device that would wake up every ~30 minutes, send 10 dahs at a 5 wpm (or so) rate, and then return to sleep.

The timing between the dahs was based upon the ambient temperature; a little math at the receiving end would allow us monitoring the channel (something like 7043.0 MHz) to calculate the temperature at the box. It was loads of fun. Of course, this is completely against Part 97 rules, no ID, no person at the controls, etc., but it was super-cool to be able to tune in on the frequency back in LA, and if conditions were decent, be able to hear the transmission.

It turned out to be about 27 minutes between transmissions, and that drifted slowly over temperature. The crystal transmitter didn’t control the frequency too well; each dah was more of a doo-weep as the transmit frequency shifted a hundred Hz or so during the dah.

The whole thing was powered from a pair of 6 V lantern batteries (the carbon-zinc kind) and housed in some kind of plastic box that was reasonably closed.

Most surprisingly, the whole shebang lasted for about 6 months, growing steadily fainter and chirping worse and worse, until it was no longer hearable.

The device, in a pretty remote and obscure location, was not tampered with. The device was recovered eventually. Some kind of field mouse had built a home inside one of the compartments. The wire was left in place.

Now, how to do something similar but using a solar panel so that the battery lifetime issue is minimized?

Mysterious GPSD

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 1 – ntpq -pn output showing ntp using my local GPS pps (“little o” at the beginning of the line)

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

Figure 2 – top command output

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?

raspberry pi – GPSD won’t reliably start

It appears that after all my toying around I still haven’t the *nix-fu chops to get everything to be stable. Every reboot sees gpsd not restart, but ntpd starts fine.

Found this note on satsignal.eu re challenges with gpsd. Tried the

$ sudo ln -s /lib/systemd/system/gpsd.service /etc/systemd/system/multi-user.target.wants/

command. Did a reboot. Now it starts automatically at reboot. Unfortunately, ntpd didn’t start this time. Thinking about “Whack-A-Mole”…