Packet Radio celebrates its first 40 years in 2022. In 1982, the American Radio Research and Development Corporation (AMRAD) published a study proposing the use of an adapted version for amateur radio purposes of the CCITT X25 standard, a packet network protocol. It was something revolutionary compared to other amateur radio digital communication technologies of that time. AX25 in fact allows simultaneous connections between multiple stations (nodes) active on the same frequency, and therefore the possibility of sharing a single radio channel among multiple users. As in X25, the ‘store and forward’ mechanism allows error-free transfers even between two nodes that are not directly connectable. A totally different world from the one typical of amateur digital communications, which are generally point-to-point links. The downside was that its implementation requires that each node has to be equipped with a TNC (terminal node controller), a small, dedicated microcomputer that performs all the processing necessary to manage the data exchange. It was technology developed entirely by radio amateurs, in those years driven by the Tucson Amateur Packet Radio (TAPR) group: their TNC-1 kit appeared in the July and August 1983 issues of Ham Radio Magazine and was the first of a long series of amateur and commercial products.
Although it in those years considerable investments were required to be active in packet – it was essential to have a computer or a terminal in addition to the TNC – Packet Radio initially gained quickly a considerable group of enthusiasts for its characteristics, mainly due its ability to distribute and make globally available amateur radio news and documentation. Its golden period lasted over 10 years. Then, parallel to the development of the internet which has obviously progressively obscured this peculiarity, it has almost fallen into disuse, to the point that today it is basically used only to support APRS.
The fact remains that packet radio remains an excellent teaching and experimentation tool in networks and digital communications – especially today which, thanks to the technological advances of these decades, can be carried out at negligible costs.

An example is the packet node that I have assembled these days, and which operates from my shack on 144.875 MHz.

It is based on an old Raspberry Pi (1) B,  which does not have an audio input channel. To be active in packet mode, I’ve added an USB audio dongle. The transceiver is an old Icom IC-02E.

operating system

Linux has native support for ax-25 and is therefore the most suitable operating system for this kind of applications. As distribution I used devuan , a debian version cleaned up by systemd : the Rpi-1 resources are quite limited, and it is therefore more useful to fully follow the KISS philosophy. I specifically used version 2 (named ascii) , which uses 4.14 kernel. For packet radio use it is generally preferable to use older kernels, as the latter have known and unsolved problems with the ax-25 stack. In particular, on raspberry there is also another known bug to be kept in count, which could compromise smooth work of the system.
The functions of TNC are implemented via software. On Linux there are two usable products: soundmodem and direworlf . The latter is newer, and has better functionality, but requires too many resources on the Rpi-1. Therefore I have installed the older soundmodem (which is a completely autonomous project compared to the UZ7HO one for Windows), which still works very well, and with a drastically lower resource commitment.
The packages to be installed via apt-get are therefore soundmodem, libax25, libax25-dev, ax25-tools, ax25-apps, libax25-dev . It is advisable to disable the on-board audio by editing the /boot/config.txt file and inserting the entry dtparam = audio = off .

transceiver

The project is designed for a continuous operation 24/7, therefore it requires a dedicated transceiver. The most suitable type for this purpose is an HT, or walkie talkie. It is likely to have one in disuse in our shack, and in any case nowadays there are some extremely cheap available. I have used an old Icom IC-02E, but I also tested other devices, such as the Baofeng UV-5R. HTs require a small interface to be coupled to the computer.

interface

I’ve designed this simple interface that can be easily adapted to different RTX models: the ones that ground the hot pole of microphone lead with a resistor to transmit (Icom, Yaesu), and those that instead ground the microphone shield  (Baofeng).

Two trimmers are used to adjust the levels of the RPi and HT outputs, which are both destined for a headphone / speaker, to the microphone inputs of the counterpart, decoupling them continuously. I did not find the need to interpose isolation transformers.
A third line is used for transmission switching (PTT). I have seen that someone uses HT VOX, if available, for this purpose, but it is not a good solution, since VOX is designed to operate on voice patterns and induces unwanted delays in digital modes, even when Vox Delay is adjustable. That delay increases the latency of the channel. The optimal solution for Rpi0 is to use one of the available GPIO lines: I’ve used GPIO4 which is not assigned to other interfaces.
Both soundmodem and direwolf allow you to use the GPIO as a PTT directly, as well as hamlib for all the transceivers equipped with a CAT interface, or the classic interfaces based on serial port control lines.
The decoupling of the GPIO (which works at 3.3V, noticeably quite critical) is done using an optocoupler. This is a picture of my version, assembled on a stripboard and connected to an Rpi Zero

Ax25

The next step is to configure and activate the ax25 stack, for this purpose it is sufficient to modify some files. The first is to define the ax25 ports active in the system. In our case the port is only one, the one on which we will configure the soundmodem , which must be identified with a name: I used ax0 . The file to edit is / etc / ax25 / axports

# /etc/ax25/axports
#
# The format of this file is:
#
# name callsign speed paclen window description
#
ax0 I8ZSE-3 1200 255 2 144.875 (1200 bps)

Fields are: name, name of the port, must be unique in system network interfaces; callsign, associated with the port complete with SSID; speed, port speed in bps; paclen, maximum length of a packet in bytes; window , the number of packets that can be transmitted before waiting for confirmation; description, a free description field.

Now that ax25 port is defined, it’s time to configure soundmodem by editing /etc/ax25/soundmodem.conf, which is an xml file. This is the content of mine:

<?xml version="1.0"?>
<modem>
<configuration name="SNDMDM">
<chaccess txdelay="250" slottime="100" ppersist="40" fulldup="0" txtail="100" />
<audio type="alsa" device="plughw:1,0" halfdup="1" capturechannelmode="Mono" />
<ptt file="/sys/class/gpio/gpio4" hamlib_model="" hamlib_params="" gpio="" />
<channel name="ax0">
<mod mode="afsk" bps="1200" f0="1200" f1="2200" diffenc="1" inlv="8" fec="1" tunelen="32" synclen="32" />
<demod mode="afsk" bps="1200" f0="1200" f1="2200" diffdec="1" inlv="8" fec="3" mintune="16" minsync="16" />
<pkt mode="MKISS" ifname="ax0" hwaddr="I8ZSE-3" ip="192.168.254.1" netmask="255.255.255.0" broadcast="192.168.254.255" file="/dev/soundmodem0" unlink="1" />
</channel>
</configuration>
</modem>

A few notes about the parameters: chaccess define the parameters of physical access to the radio channel. Txdelay is the time between the activation of the PTT and the beginning of the data packet transmission, the value (expressed as ms) must be slightly greater than the transceiver transmission switching time. Slottime and ppersist are two parameters of the collision reduction mechanism (CSMA / CR) that can be kept unmodified. Txtail is the ‘tail’ that is added after the end of packet. A more detailed description is available in the KISS protocol document here .
The audio line defined the parameters of the audio chain. The parameter to be configured is device, which must be configured depending on the usb device used. All Usb devices can be listed with lsusb command, while audio devices detected can be listed with aplay -l command. An example:

root @ packet: / etc / ax25 # lsusb: / etc / ax25 # lsusb
Bus 001 Device 006: ID 0d8c: 013c C-Media Electronics, Inc. CM108 Audio ControllerBus 001 Device 006 : ID 0d8c : 013c C - Media Electronics , Inc. _ CM108 Audio Controller      
Bus 001 Device 005: ID 148f: 3070 Ralink Technology, Corp. RT2870 / RT3070 Wireless AdapterBus 001 Device 005 : ID 148f : 3070 Ralink Technology , Corp. _ RT2870 / RT3070 Wireless Adapter       
Bus 001 Device 004: ID 0a05: 7211 Unknown Manufacturer hubBus 001 Device 004 : ID 0a05 : 7211 Unknown Manufacturer hub     
Bus 001 Device 003: ID 0424: ec00 Standard Microsystems Corp. SMSC9512 / 9514 Fast Ethernet AdapterBus 001 Device 003 : ID 0424 : ec00 Standard Microsystems Corp. _ SMSC9512 / 9514 Fast Ethernet Adapter        
Bus 001 Device 002: ID 0424: 9512 Standard Microsystems Corp. SMC9512 / 9514 USB HubBus 001 Device 002 : ID 0424 : 9512 Standard Microsystems Corp. _ SMC9512 / 9514 USB Hub      
Bus 001 Device 001: ID 1d6b: 0002 Linux Foundation 2.0 root hubBus 001 Device 001 : ID 1d6b : 0002 Linux Foundation 2.0 root hub      
root @ packet: / etc / ax25 # aplay -l: / etc / ax25 # aplay -l
**** List of PLAYBACK Hardware Devices ******** List of PLAYBACK Hardware Devices ****    
card 1: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio]1 : Device [ USB PnP Sound Device ], device 0 : USB Audio [ USB Audio ]     
Subdevices: 0/1Subdevices : 0/1 _ _ 
Subdevice # 0: subdevice # 0Subdevice # 0: subdevice # 0

Ptt line configure the device used to set RTX in transmit mode. In the example, file /sys/class/gpio/gpio4  is not a real file, but a reference to syfs, the subsystem used by linux to manage gpio lines on raspberry. There are no configurations to do on OS level, soundmodem takes care of exporting the GPIO line and configuring it as outgoing. Note that to restart soundmodem it is necessary to before deactivate the line sending the command echo 4 >/sys/class/gpio/unexport .
The last line that needs attention is pkt. Mode can assume two values: MKISS and KISS. MKISS creates an ax25 interface with associated TCP/IP network interface, so that ax0 is associated to network address, that allow internet protocols to be used via radio. KISS, on the other hand, creates an interface just on the ax25 stack.

Hamlib

If the transceiver used has a CAT interface, it is possible to control transmission through the hamlib library. If it is not already installed, it can be downloaded with the command apt-get install libhamlib-utils libhamlib2. Hamlib is enable using a different pkt line, which must have this form:

<ptt file="/dev/ttyUSB0" hamlib_model="1023" hamlib_params="serial_speed=38400"/>

file is the serial port used to connect the transceiver, hamlib_model the RTX model id, in hamlib_params it is possible to specify options of the CAT connection. In this example 1023 corresponds to Yaesu FT-897, in this case configured to use 38400 bps as the connection speed, instead of the default 9600. The list of supported transceivers can be listed using rigctl –list command.

Soundmodem must be always running in the background, and the best way to do it is to launch it together with the system, writing a small script like

# start ax25
soundmodem &&
sleep 33

and starting it with an @reboot line in crontab.

After a reboot ax25 stack should be configured and active

Part 2

Link utili