This is largely derived from the first post N6CTA wrote in a series detailing how to get on HF with packet radio using John Wiseman, G8BPQ’s suite of PBBS software, and John Langner, WB2OSZ’s software TNC, Direwolf using the Linux operating system. Much of the series was geared towards meeting the goal of setting up a well functioning, always-on, reboot safe, packet bulletin board system. When possible, we've have tried to denote what is optional and what is not depending on the goal of being either a casual K2K OP with maybe an account on someone else’s machine or being the sysop of a full service HF BBS.

This is likely a weekend project at minimum if you have minimal Linux experience, but those with linux chops and BBS experience can likely get it all sorted in just a few hours. There’s no sugar coating the config files – but taken as-is on a clean system, they should work well.

N6CTA choose to use Direwolf as the software modem in this series as it appeared to the most performant and stable 300Bd FX.25 soft modem available for Linux. We've also investigated QtSoundModem and found it to be a little more challenging to use. This is still an imperfect solution as Direwolf doesn’t integrate as cleanly as it could with BPQ’s AGW driver. BPQ treats Direwolf (and all AGW ports) like a KISS TNC instead of allowing the TNC to handle some of the AX.25 stuff it’s good at. WB2OSZ’s OSI comments on why L1 and L2 need to be tightly coupled make a lot of sense and the AGW protocol allows for this kind of behavior but it does not appear to be implemented properly in BPQ.

Note: I am listing Debian package names for the libraries throughout the series. If you’re on some other flavor, you’ll likely need to sort out the exact package names from your distribution’s repository. No exotic libraries are being used though and if you can live with using your distribution’s versions of some of this software, by all means, use your repository’s packages. In the case of using a Raspberry Pi, it makes more sense to me to use Raspberry Pi OS (Debian Bookworm fork as of this writing) and compile the new software from source. We're recommending compiling from source for these components in order to get the latest and greatest, although this requires a little extra work to get set up and chance for new bugs.

Boilerplate yadda yadda, YMMV. Let’s get on with it.

Don’t overthink this part. You can likely use any machine built in the last 15-20 years.

As long as it has the ports you need to connect it to your gear, it should be fine. The software isn’t particularly resource intensive. We're using a Raspberry Pi 4B because they are fairly common and easily available, while also aware there is ongoing discourse around very poor behavior and a scandalous staffing decision by the Raspberry Pi Foundation – so we're not suggesting to go out and buy a Raspberry Pi just for this. Start with looking for a suitable candidate sitting in a closet or can score one at an e-waste roundup or surplus store.

Reasons to choose a Raspberry Pi for N6CTA's original project: * Already have a bunch for prototyping work from before the pandemic chip shortage * Were relatively inexpensive when I bought them * Raspberry Pi OS is fairly stable now with a vast repository of working software * Other SBC's have varying level of update support for their OS, Raspberry Pi is consistently good about theirs * The SBC can easily be powered by my portable radio battery * Eventually solar power the whole shebang so managing power consumption is important to me