“LMT” BPQ Node Notes

One of the projects I am working on is expanding the local Packet radio infrastructure and its capabilities. Part of that is looking at changing from a hardware based packet solution to a software based solution.

Hardware or Software

Generally speaking, hardware solutions have traditionally had an advantage in being a more plug-and-play than software solutions. This carries with it the disadvantage of being more limited in expansion and having a higher cost for the equipment. Also, there are the limitations of the hardware in audio fidelity. On the software side we have the advantage of open source lending to continued development, updates, and improvements, both in operations and capabilities. Additionally software “soundcard” TNCs tend to have better audio quality allowing for faster, more accurate encoding and decoding, including better week signal capabilities. The main disadvantage is the complexity of software TNCs and the accompanying mode functions. Taking all of this into consideration, a software option is the route this project will take.


The plan is to utilize the BPQ software which provides for BBS, Winlink, and chat modes over various channels, RF (HF/VHF/UHF), intranet, and internet on a Raspberry Pi 3/4 with home brew audio interfaces* connected to Alinco transceivers; 2m DR-135MkIII, 70cm DR-435MkIII, and 6m DR-06T.

* The AF/key interface is a separate project of its own.


The Alincos are a good choice for packet because they have a DB-9 on the back of the radio that connects to the raw audio ahead of the voice processing on the radio giving you the best digital signal. Many radios these days have a 6-Pin DIN connection on the back but their application is inconsistent, the pinouts vary, even within the same manufacturer, also, for the old farts with lower visual acuity or unsteady hand, or those not familiar with soldering, the DB-9 is much easier to wire up. The DB-9 has the additional advantage of over sized case availability that can also hold the USB audio devise leaving only a USB cable to connect to the computer. (more on the Audio Interface project page)


There are numerous out-of-the-box interfaces often incorrectly referred to as TNCs as they do not do any processing, the software does all of the heavy lifting. If the “TNC” works for all digital modes, it’s not a TNC, it is an interface. There are some hybrids that do only specific modes but these are not what I am talking about here. One of the most common interfaces these days is the Signalink USB produced by Tigertronics.

I’m not going to get into the issues with the Signalink, suffice to say, it is essentially a USB sound device with a VOX circuit built in. For older rigs, like 20 years or more, it provides good audio isolation but at the cost of audio quality. A newer radio with a modern computer does not need 1:1 audio transformers. Don’t take this as gospel, there are always exceptions. If you blow up your radio or computer, it’s on you. Do your due diligence.


Now that BPQ has been installed on the Pi I am going over the configuration file bpq32.cfg. The file has a number of sections beginning with the basic system configuration followed by Port configurations.

The Ports are how you connect to the node and it connects to the utside world. Some of the Port options include; KISS, CMS, Winmor, ARDOP, VARA, URONode, Telnet, AX.25/IP Gateway, Ethernet, VHF radio, UHF radio, HF radio, APRS radio, APRS Digi, and more.

Part of the configuration is advanced planning on how to engage a network to make the most convenient use of the node(s), this includes naming conventions. LMT is the FAA airport code for Crater Lake-Klamath Regional Airport. Since this is a a unique identifier across the US it is a good prefix option for the node.

14 NOV 2020

The node has been up and running the better part of a week now with only the AXIP port connected. I am connecting to other nodes via an internet link. My node can now access 199 other nodes, world wide.

I can hear it now, “amateur radio…” where’s the radio‽ Most of these nodes have radio ports that can be accessed much like using Echolink for voice transmissions or linking repeaters. What is important to remember is you are building pathways, initially my node is AXIP only, it will not remain this way. Once my node’s RF ports are up and running I will be converting other PBBS and Winlink access points at fixed cites to nodes as well and they will also be able to access the networks, plural, RF and AXIP.

The Kantronics PBBSs we have now connect about 25% of Klamath county by VHF. The digipeater on Hamaker mountain extends that to parts of Jackson county and northern most California. The services they provide however are limited. When the LMT node’s VHF port goes live that will expand the service level significantly, allowing access to services and local or distant nodes.

One of the biggest obstacles in building a wide-area packet network is interest. I have been maintaining the local packet infrastructure for three years now, and pushing for its use. There are a handful of folks capable of accessing the assets we have, and only two actually using doing so, me being one of them. Why? there isn’t much to do. It is hard to recruit folks when there isn’t much to do or explore. Expanding interest will inherently help expand the networks, both RF and AXIP.

Enough soapbox. What I am working on now is the AF/key interface. An audio frequency interface between the node computer and a radio, AND a way to key that radio when it needs to transmit. There are a lot of options here. I have built a discrete component audio interfaces before that used GPIO pins from the Pi to key the radio but that is a messy option.

I was hoping to find a reliable supply of inexpensive USB soundcard modules with a serial port built in. There is a chipset that does this, but finding a devices that has that chipset, and that the manufacturer hasn’t disabled the I/O or potted the chip, has been difficult. I am looking for a solution that will age well and be easy enough to teach to others without constantly trying to replace suppliers for components.

Enter the compromise. I do not like VOX circuits. Especially for data modes. My dislike is mainly towards the switching capabilities of radios built-in VOX circuits, but does extend to external devices. The proliferation of the Signalink has proven that a VOX circuit will work. Combining the lack of reliable sources for a preferred option and the wide-spread use of VOX circuits, I acquiesce. This project will have its own page.

18 NOV 2020

Nothing technical today but I did post about the project and my realization that I wasn’t documenting the the process well enough. I will have to backfill some of the build details.


The challenge I wanted to resolve today was to make sure I have the ability to create and update an image of the entire OS and all files as a backup and so I can take a working node and and duplicate it with minor modifications.

I started with updating Samba so I can run the image utilities and save, update, and share the image stored on my Windows computer.

pi@node:~/$  apt install samba samba-common-bin smbclient cifs-utils

The next thing on the list is to download the image tools from a Git Repository and make them executable

pi@node:~/$ git clone https://github.com/seamusdemora/RonR-RPi-image-utils.git
pi@node:~/$ cd RonR-RPi-image-utils/
pi@node:~/$ chmod +x ./RonR-RPi-image-utils/image*

Next it’s time to make an image directory and mount the Windows shared directory. To create the Windows shared directory right-click it and select share. When the share opens up share to all and make sure you click the advanced button and allow connection without a password. This is intended for your internal network, if you plan on using this over a HamNet you will want to be more secure. Also, it will be easier to share to/from a another Linux system.

pi@node:~/$ sudo mkdir /mnt/pi-image
pi@node:~/$ sudo mount.cifs // /mnt/pi-img

With the share set up and mounted its time to run the image backup.

pi@node:~/$ sudo ./RonR-RPi-image-utils/image-backup

Make sure you read the README.text file in the RonR-RPi-image-utils directory. This will give you everything you need to know about using the utilities.

Still to resolve on this task: This is not currently set up as an automated task. I plan on setting this up as a maintenance scrip that will run on startup and weekly to do a series of maintenance tasks and updating the image is one of the weekly tasks.

Amateur Radio, Emergency Communications, Traffic Handling and more