GB7EAT gains 9600 BPS access

Since my last post, there has been a period of settling in for GB7EAT and now some updates.

When I started, I was using the Direwolf sound card modem as the interface to the radio. However, I was getting some issues relating to packet corruption, so I replaced this with a NinoTNC that I built up from a kit and put in a 3D printed case.

It’s been running nicely with this, but the NinoTNC does not support FX.25: the upgrade to AX.25 that adds Forward Error Correction – (FEC) to improve throughput. Also, it only supports one mode at a time.

I wanted to add high speed access on the same frequency, so I switched back to using Direwolf and implemented a hack I found on The Modern Ham’s website that allows you to run multiple modems on the same sound card. In the hack shown on the website, the purpose is to run Direwolf and VARA on the same sound card, but the principle applies equally to Direwolf.

What I did was as follows:

Allow the sound card to be shared

The output from cat /proc/asound/cards showed:

0 [vc4hdmi0       ]: vc4-hdmi - vc4-hdmi-0
                      vc4-hdmi-0
 1 [vc4hdmi1       ]: vc4-hdmi - vc4-hdmi-1
                      vc4-hdmi-1
 2 [Headphones     ]: bcm2835_headpho - bcm2835 Headphones
                      bcm2835 Headphones
 3 [Device         ]: USB-Audio - USB Audio Device
                      C-Media Electronics Inc. USB Audio Device at usb-0000:01:00.0-1.3.2, full speed

Thus my DigiRig sound card is device 3

I created the file /etc/asound.conf (because it didn’t already exist)

pcm_slave.digirig {
   pcm {
      type hw
      card Device
   }
   period_time 0
   buffer_size 8192
}

pcm.digirig-dmix {
   type dmix
   ipc_key 2023041901
   slave "digirig"
   bindings.0 0
}

pcm.digirig-dsnoop {
   type dsnoop
   ipc_key 2023041902
   slave "digirig"
   bindings.0 0
}

pcm.digirig-rx {
   type plug
   slave.pcm "digirig-dsnoop"
   hint.description "digirig RX audio plug"
}

pcm.digirig-tx {
   type plug
   slave.pcm "digirig-dmix"
   hint.description "digirig TX audio plug"
}

This creates two ‘virtual’ sound devices digirig-rx and digirig-tx

Modifying direwolf.conf

After rebooting, I could then modify my direwolf.conf to read (partially)

ADEVICE digirig-rx digirig-tx
#
CHANNEL 0
MYCALL GB7EAT-5
MODEM 1200
PTT /dev/ttyUSB0 RTS

i.e. changed the name of the audio device.

Changed how I used direwolf

The Direwolf sound card modem can be used in two modes: AGW Packet Engine (AGPWE) emulation and KISS. Previously, I was using AGWPE mode as follows (in XROUTER.CFG)

INTERFACE=2
  TYPE=AGW
  MTU=256
ENDINTERFACE

Investigation of the problem I was experiencing where other stations were rejecting my AX.25 frames with an FRMR or “Frame Reject” response, prompted me to change to using KISS mode. The appropriate stanza now looks like:

INTERFACE=2
  TYPE=TCP
  PROTOCOL=KISS
  IOADDR=127.0.0.1
  INTNUM=8001
  MTU=256
ENDINTERFACE

The Port definition hasn’t changed:

PORT=2
  ID=(FSK) 144.950MHz 1200BPS Direwolf
  INTERFACENUM=2
  ;CHANNEL=A
  MHEARD=50
  IDPATH=APXR00
  IDTEXT=!5213.72N/00016.79W XRPi EATON (GB7EAT-5), Chat=GB7EAT-8/EATCHT
ENDPORT

Adding a second port on the same frequency

After checking that this all worked, I was able to add a second direwolf instance fairly easily.

  1. Edit start_direwolf.sh
#!/usr/bin/bash
#
/usr/bin/tmux new -d -s direwolf
/usr/bin/tmux send-keys -t direwolf:0 '/usr/local/bin/direwolf -c \              /home/pi/direwolf/direwolf1.conf' ENTER
/usr/bin/tmux new-window -t direwolf
/usr/bin/tmux send-keys -t direwolf:1 '/usr/local/bin/direwolf -c \   /home/pi/direwolf/direwolf2.conf' ENTER
  1. rename the original direwolf.conf file
mv direwolf.conf direwolf1.conf
  1. Copy and amend the second direwolf.2.conf file
cp direwolf1.conf direwolf2.conf
vi direwolf2.conf

The relevant changes are:

MODEM 9600
#
AGWPORT 8002
KISSPORT 8003

Everything else stayed the same.

Now, when I reboot, tmux opens two windows and launches two distinct copies of direwolf.

  1. Amend XROUTER.CFG to add the additional Interface and Port
INTERFACE=2
  TYPE=TCP
  PROTOCOL=KISS
  IOADDR=127.0.0.1
  INTNUM=8001
  MTU=256
ENDINTERFACE
INTERFACE=7
  TYPE=TCP
  PROTOCOL=KISS
  IOADDR=127.0.0.1
  INTNUM=8003
  MTU=256
ENDINTERFACE

PORT=2
  ID=(FSK) 144.950MHz 1200BPS Direwolf
  INTERFACENUM=2
  ;CHANNEL=A
  MHEARD=50
  IDPATH=APXR00
  IDTEXT=!5213.72N/00016.79W XRPi EATON (GB7EAT-5), Chat=GB7EAT-8/EATCHT
ENDPORT
PORT=3
  ID = (G3RUH) 144.950MHz 9600BPS Direwolf
  INTERFACENUM=7
  MHEARD=50
  IDPATH=APXR00
  IDTEXT=!5213.72N/00016.79W XRPi EATON (GB7EAT-5), Chat=GB7EAT-8/EATCHT
ENDPORT

GB7EAT – first light

The plan is to start small and build up from there, so this is the starting position:

Hardware

  • Raspberry Pi 4 (I could have used a 3B but I had a Pi 4 sitting doing nothing).
  • Digirig Mobile audio adapter.
  • Tait 8115 25W Mobile Radio.
  • Antenna – initially just my shack 2m/70cm co-linear in the back garden.
  • PSU, cables, etc.

This is pretty much as simple as you can get; a computer to run the software; an audio adapter to convert digital signals to audio; and a radio+antenna.

Software

Again, as simple as I can get to begin with. I’m using the Direwolf sound card modem to start off with.

Configuration

I started by installing the stock bookworm-lite edition of the Raspberry Pi OS – which is a slightly adapted version of Debian. I don’t need the graphical desktop as I’m more used to interacting with Linux via the console.

As with the Remote Shack, I created a dedicated Zerotier network to which the node and my home Mac are connected. The Zerotier “SNOPAC” network uses the address space 192.168.192.0/24 and m5kvk-5 has the address 192.168.192.3. It is this network that I use for all remote access rather than the local VLAN address. That way, if the node is moved to a different location – and LAN – it will still have the same IP address.

The second step was to bootstrap the node using debops so that it had a known configuration. I then re-ran debops to install XRPi and Direwolf and configure them to run as systemd services under tmux.

The reason for this is that neither XRPi nor Direwolf are daemons, so they need to be run from a console. By running them in tmux windows, I can run them simultaneously and access them remotely.

The code for doing this was fairly simple: A systemd service unit that runs a script

[Unit]
StartLimitIntervalSec=5
Description=XRpi service
After=network.target
StartLimitIntervalSec=0

[Service]
Type=forking
Restart=unless-stopped
RestartSec=5
User=pi
WorkingDirectory=/home/pi/xrpi
ExecStart=/home/pi/xrpi/start_xrpi.sh

[Install]
WantedBy=multi-user.target

And the script /home/pi/xrpi/start_xrpi.sh

#!/usr/bin/bash
#
/usr/bin/tmux new -d -s xrpi
/usr/bin/tmux send-keys -t xrpi:0 '/home/pi/xrpi/xrpi64v504m-bullseye' ENTER

The pair of files for Direwolf are similar.

direwolf.conf

This file configures direwolf. Mine is pretty simple:

ADEVICE plughw:3,0
#
CHANNEL 0
MYCALL GB7EAT-5
MODEM 1200
PTT /dev/ttyUSB0 RTS
#
AGWPORT 8000
KISSPORT 8001
#
# Transmit FX25 instead of AX25
#
FX25TX 1
#
# How likely are we to Tx?
#
PERSIST 63
# 
# How often do we check?
#
SLOTTIME 12
#
# How many tries do we try to send a frame before giving up?
#
RETRY 5
#
# How long do we wait for a reply?
#
FRACK 3
#
# How many frames will we send before we wait for an acknowledgement
#
MAXFRAME 4
#
# How long should packets be?
#
PACLEN 128
#
# How long do we allow for PTT to take effect
#
DWAIT 0
#
# How long (10ms) to let the Tx stabilise
#
TXDELAY 30
#
# How do we wait at the end before dropping Tx
#
TXTAIL 15

The line ADEVICE plughw:3,0 tells direwolf the address of the digirig mobile, and comes from running the command: aplay -l To get the card (3) and device (0) of the dgirig.

XROUTER.CFG

This is the main config file for XRPi. This is the version after I applied for and was allocated GB7EAT:

# XROUTER.CFG - Main Configuration file for XRPi / XRLin
#
# This file is read only when the program boots.
#
#===================================================================
#
#       Primary Identity for AX25 & NetRom.
#
NODECALL=GB7EAT-5
NODEALIAS=EATON1
#
#       QTH
#
QTH=St Neots, Cambs, UK, IO92uf
LOCATOR=IO92uf
#
#       Console operations.
#
CONSOLECALL=M5KVK
#
#       Chat server.
#
CHATCALL=GB7EAT-8
CHATALIAS=EATCHT
CHATQUAL=100
#
#        PMS
#
PMSTYPE=4
PMSCALL=GB7EAT-2
PMSALIAS=EATBBS
PMSQUAL=120
PMSHADDR=.#22.GBR.EU
#
#       "Connection text", sent to anyone connecting to the alias
#
CTEXT
M5KVK Test Node chat server
Type '?' for list of commands.
***
#
# This text is the response to the 'I' command
#
INFOTEXT
XRPi Packet Router, St Neots, Cambs, UK, IO92uf
Sysop: Gareth M5KVK (M5KVK@GB7EAT.#22.GBR.EU)
To connect to the BBS, use the command: BBS
Comments/reports.queries to: M5KVK
Website: https://m5kvk.org/packet/gb7eat
***
#
#
#       This ID message is sent every IDINTERVAL.
#
IDTEXT
!5213.72N/00016.79W XRPi EATON (GB7EAT-5), 44.33.3.152, Chat=GB7EAT-8/EATCHT
***
#
# Port used to access Telnet
#
TELNETPORT=8023
# =====================================================================
# Interface definitions - These MUST precede any port definitions
# =====================================================================
#
INTERFACE=1
  TYPE=AGW
  MTU=256
ENDINTERFACE
#
# =====================================================================
# Port definitions. Each one begins with PORT and ends with ENDPORT
# =====================================================================
#
PORT=1
  ID=(FSK) 144.950MHz 1200Bd TESTING
  INTERFACENUM=2
  CHANNEL=A
  MHEARD=50
ENDPORT

Note that I am using the direwolf modem in AGW emulation. This appears to be the most stable method.

Conclusion

So, I have GB7EAT operational on 144.950MHz.

On the To-DO list are connections to the rest of the network, replacement of the direwolf modem with a NinoTNC, connection to AMPRnet and addition of a high speed 70cms link.

Also on the list for longer term exploration are a move of the node to a better physical location, and addition of higher speed links.