I haven't written that much about amateur radio here, but that's going to change. My callsign is AI4UC and I've been licensed since 1993.

I was introduced to a new HF digital mode called FT8 at WWV's 100th anniversary special event station in 2019. To make a long story short I had good intentions for getting on the air with FT8 for a couple of years, but then got motivated by my friend Brett who pointed me at a small and inexpensive CAT and audio interface all-in-one box, which promised to be far less fiddly than the Signalink USB which i used for PSK31 back when I lived in the apartment.

This left me with a question - what computer to use to dedicate to the whole affair? I wanted to be able to remotely drive the radio via the GUI in flrig, fldigi, and wsjt-x while sitting upstairs with a laptop or iPad. It might be nice to just leave out the video monitor from the shack computer altogether; run it with VNC from the laptop when I was sitting down in the basement!

I settled on a 4gb Raspberry Pi 4b that I had on hand as a good choice. Right at the moment, they're way too expensive due to supply chain problems, but that will right itself in time. I've been running this configuration for a month; in that time I've managed to log 736 QSOs, 470 QSLs, and 42 DXCC entities, all with the Pi and the aforementioned Digirig. For the first half of the month I was only running 6 watts into a bit of a makeshift mounted QRP antenna, so these numbers would have likely been a lot higher if I'd had a setup that was at parity with the stations I was trying to work.

If you try this on a Raspberry Pi 3 of some flavor, I'd be interested in hearing your results particularly if you do a side by side bakeoff against a Pi 4. The Pi 4 seems adequate, but gets a little slow on decodes when the band is busy. The Pi3 seems to come out at about 2/3 the speed of the Pi 4.

Here are my notes for setting up the Pi to run headless and control it over VNC, without ever hooking up a monitor to it. Note that there's a bunch of command line work here, and there's an assumption that you know how, or can figure out from elsewhere, how to write an image on a card, using ssh, apt install, your favorite *nix text editor, or any of that sort of thing. This is a command-line-centric howto.

Note that adequate power is an absolute must. I run the Pi 4 off the officially approved power supply and it seems to do fine - remember that the Digirig does in fact draw power itself too.

Start with a freshly installed raspberry pi with 32 bit Raspbian Buster as the base OS. If you're used to Intel you might be inclined to reach for the 64 bit variant but that is ill advised. RaspiOS 64 bit is considered beta as of February 2022 (and will only run on a Pi 3 or later). Bullseye (latest version) is also shady to some extent for this application; you'll have the least frustration if you stick to the script. You want the full install with desktop and everything, not "lite".

Starting point for these notes is 2022-01-28-raspios-buster-armhf.zip

Unzip, use dd or etcher or whatever you like to write the image in the usual way. Turn on sshd (touch /boot/ssh on the mounted FAT /boot) after you do the image as this is how we will be getting in to configure it sans screen. Note that if you don't mind cabling it all up, you shouldn't have any trouble following the rest of this how-to in a terminal window in the GUI either.

Plug it into ethernet and power. Find the IP address with arp, switch tcam table examination, nmap, or whatever you like. ssh pi@192.0.2.33 (password raspberry) using, of course, the address you just discovered on your LAN.

First, get everything up to date:

sudo apt-get update -y
sudo apt-get upgrade -y
sudo apt dist-upgrade -y

Next, we convince the Pi that it has HDMI plugged in so that the GUI starts. The aforementioned /boot FAT partition is now mounted under /boot on the running pi. There's vim(1) and nano(1) here, even ed(1). Pick your poison. Put this in /boot/config.txt - position not critical:

framebuffer_width=1920
framebuffer_height=1080
hdmi_force_hotplug=1
hdmi_group=1
hdmi_mode=16
hdmi_drive=2

and sudo reboot. You can do some other resolution if the mood strikes you but I've found 1920x1080 to be a good resolution for doing remote ham radio on a modern laptop.

ssh back in after the reboot, it'll be convenient to be root for the next several commands

sudo bash

You'll read stuff about using raspi-config to set up vnc-server but that's not useful anymore as things have changed in recent releases.

RealVNC has a fairly well developed and performant VNC server that talks to the same user session as the physical screen rather than setting up its own. The Raspberry Pi version is free.

apt-get install realvnc-vnc-server

should tell you that realvnc-vnc-server is already installed. If you want to play with other VNC servers for the Pi, that's fine, but you're on your own there.

vncpasswd -service

You'll be prompted to set the screen access password for VNC. It's only significant to 8 characters, need not be the password you use to ssh in, but it is the password you use to connect to the VNC server.

Now, add: Authentication=VncAuth just above the "Password" line in /root/.vnc/config.d/vncserver-x11

If you don't do this, you'll get a vnc server version that is more secure/advanced than the Mac's built in screen sharing client (more on that in a minute).

systemctl enable vncserver-x11-serviced.service
systemctl start vncserver-x11-serviced.service

Might have to reboot for good measure here, but at this point you should be able to connect from the screen sharing client on your laptop as there is a VNC server running on the Pi on port tcp/5900.

Once logged in from your VNC, you should be able to "drive" the GUI as if you were sitting in front of the computer. Or put your laptop to sleep, take it somewhere else, reconnect, and find things exactly as you left them.

Assuming you're a Mac user, you might be surprised to learn there's a Mac VNC client built in. It hasn't changed in years. I've had good luck with Screens ($19.95 from the app store on my iPad). The RealVNC free client is not bad either,

This might be useful for applications other than ham radio - say for instance, working on Pi-based digital signage without dedicating a monitor to the task.

Security lecture time: DON'T BE THAT GUY. Depending on the negotiation, this VNC server will probably be unencrypted. Don't port forward to it so your friends can use it. Don't expose it naked to the Internet in any other way (it's a bad neighborhood out there). For remote access, it's ssh-tunnel or VPN time, not "poke a hole in the firewall". You've been warned.