Had a bit of fun on the radio yesterday. 145 Alive is an event that's run every so often for a couple of years now to encourage Amateur Radio activity on the 145Mhz, or 2 meter, frequency band.
For a couple of hours on a set date operators are encouraged to make contact with each other, with volunteers coordinating operations in various areas across the country. It's a fairly relaxed event, rather than a contest with strict rules of operation, but some folks do get into the spirit of it, heading for high-ground with masts and efficient antennas to maximize their range.
I wasn't so organized, having basically forgot which weekend it was happening on, so my preparation involved charging a handheld radio for an hour and grabbing a bottle of water before going out.
Fortunately we're well placed at the base of the Ochils, and after an hour's walk I was half-way up Dumyat, on a ridge with a good view of the horizon. I'd turned my radio on before I started walking and it had chattered a couple of times on the way up - good sign. Once I sat down, it only took a minute or two to hear a couple of stations talking, and to respond myself. Remarkaly the station that called back was to the south-west of Carlisle - around 100 miles away! Sadly the other stations he was able to reach could not hear me, but it was fun nontheless.
Sometime over the summer I'd like to get up to the summit again, and hopefully do some operation within the rules of the Summits On The Air scheme.
Introduction
As mentioned in my post on AX.25 over Ethernet, it can frequenly be useful to transport AX.25 traffic over other networks. In the modern era the obvious candidate is the Internet.
There are two common ways of transporting AX.25 frames over Internet Protocol (IP) networks, both often referred to collectively as AXIP.
Packets can be directly encapsulated in IP frames using the protocol type 93, or inside UDP frames. The latter method is sometimes referred to as AXUDP.
AXIP has less overhead than AXUDP but can be harder to handle, particularly with domestic network equipment due to the unusual protocol number.
AXUDP comes with a little more overhead but the advantage of being the more common UDP protocol type, and using a UDP port number allows for several AXUDP connections to be handled by a single IP address.
The Linux implemenation of AX.25 over IP - ax25ipd can handle both types of encapsulation, but I'll be using AXUDP for this example.
I have also created an AXIP Ansible Role to automate this process.
Concept
ax25ipd can be seen as a bridge with the IP network on one side and KISS-encapsulated AX.25 frames on the other.
Rather than interacting directly with the Linux AX.25 stack, ax25ipd connects to a serial port or pseudo terminal. This could be used to connect a hardware KISS TNC at a remote location.
In order to connect it to a Linux system, it is necessary to use an additional peice of software to simulate a serial cable, with ax25ipd on one end and kissattach on the other.
The ax25-tools package provides kissnetd for this purpose, but it is awkward to use on modern linux systems with dynamic (Unix98) pseudo terminals as it requires its output to be parsed to determine which pseudo terminal has been allocated, and ax25ipd reconfigured to use this. A more convienent solution is to use socat, which will manage the pseudo terminal and provide symbolic links in a fixed location for ax25ipd and kissattach to use.
socat
The first thing we need to do is set up the systemd service to manage socat.
Create a file at /etc/systemd/system/kiss-socat-axip.service containing the following:
# /etc/systemd/system/kiss-socat-axip.service
[Unit]
Description=Socat interconnect for AX25 AXIP
After=network-online.target
Wants=network-online.target
[Service]
WorkingDirectory=/var/ax25
ExecStart=socat -d -d -ly pty,raw,echo=0,link=/var/ax25/pty/axip1 pty,raw,echo=0,link=/var/ax25/pty/axip2
ExecStartPost=/usr/bin/bash -c 'while ! [ -h /var/ax25/pty/axip2 ]; do sleep 1 ; done'
ExecStopPost=rm /var/ax25/pty/axip1 /var/ax25/pty/axip2
[Install]
WantedBy=multi-user.target
Create the /var/ax25/pty directory, then enable and start the service:
$ sudo mkdir -p /var/ax25/pty
$ sudo systemctl daemon-reload
$ sudo systemctl enable kiss-socat-axip
$ sudo systemctl start kiss-socat-axip
axports
we need an entry in /etc/ax25/axports - use your callign and a suitable SSID:
axip N0CALL-11 115200 255 7 AXIP
This defines the ax.25 port 'tnc' with its callsign, serial port speed, packet size, window size, and finally a comment describing the port.
kissattach
The kissattach program is used to set up communication between Linux's AX.25 stack and ax25ipd, via the socat process.
Create a file at /etc/systemd/system/kiss-tnc@.service containing the following:
# /etc/systemd/system/kiss-tnc@.service
[Unit]
Description=AX25 KISS TNC %I
[Service]
ExecStart=/usr/sbin/kissattach $TNC_TTY %i
ExecStop=pkill -f "kissattach $TNC_TTY %i"
ExecStartPost=/usr/bin/bash -c 'while ! /usr/sbin/kissparms -c 1 -p %i; do sleep 1; done'
TimeoutStopSec=5
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
This is a template unit file that can be used for several TNCs or AXIP tunnels.
To configure an instance for our AXIP tunnel, first enable it:
$ sudo systemctl enable kiss-tnc@axip
Then edit it:
$ sudo systemctl edit kiss-tnc@axip
Add the following to the top of the file and then save it:
[Unit]
After=kiss-socat-axip.service
After=network-online.target
[Service]
Environment=TNC_TTY=/var/ax25/pty/axip2
This tells kissattach where to fine the pseudo terminal, and systemd to wait until socat is running before trying to run kissattach.
As we've already started socat, we can bring up this service now:
$ sudo systemctl start kiss-tnc@axip
ax25ipd
Next we need to configure ax25ipd. Create /etc/ax25/ax25ipd.conf with the following contents:
# /etc/ax25/ax25ipd.conf
socket udp 10095
mode tnc
device /var/ax25/pty/axip1
speed 115200
loglevel 2
broadcast NODES-0
route N1CALL axip.example.net b
The exact contents of this file will depend on the software you are running and your AXIP peer.
The socket line dictates with UDP port will be used for this connection, and will need to match what is being sent by your peer.
The broadcast line is a list of destinations that will be treated as broadcast traffic. NET/ROM operation requires NODES-0. If you are running the fbb bulletin board software you may need to add FBB-0.
The route line defines your peer, and should include their callsign and internet host name or IP address. The final 'b' on the line indicates that they should receive broadcast traffic.
Finally, we need to create a systemd service for ax25ipd. Create /etc/systemd/system/ax25ipd.service containing the following:
# /etc/systemd/system/ax25ipd.service
[Unit]
Description=AX.25 over IP (AXIP) daemon
After=network.target
StartLimitInterval=0
[Service]
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/sbin/ax25ipd
[Install]
WantedBy=multi-user.target
$ sudo systemctl daemon-reload
$ sudo systemctl enable ax25ipd
$ sudo systemctl start ax25ipd
If everything has worked, you should now be able to use axcall axip N1CALL to connect to your peer.
Having made some changes to how my email is handled recently I wanted to tidy things up by having my FreeBSD systems submit mail via my mail provider's authenticated SMTP submission service.
Googling for how to do this turned up a lot of advice, much of it dated and often more complicated than is currently required, so I thought I'd document where I got to for the benefit of others trying to do this.
I'm assuming this is being done on a system where sendmail has already been configured generally. See the FreeBSD handbook if this isn't the case.
Firstly, the Sendmail shipped with FreeBSD 13 doesn't include the SASL features required to do authentication. The easist way to fix this is to install a more complete version from pkg using pkg install sendmail.
Once this is done, installing the supplied mailer.conf file will tell the system to use this version of sendmail.
cd /usr/local/etc/mail
cp mailer.conf.sendmail mailer.conf
To tell sendmail to use a smarthost, and to authenticate to it requires a couple of changes.
Firstly in /etc/mail/${HOST}.mc, add
define(`SMART_HOST', `smtp.example.com')
define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl
FEATURE(`authinfo', `hash -o /etc/mail/authinfo')dnl
Then create /etc/mail/authinfo containing
AuthInfo:smtp.example.com "U:me@example.com" "I:me@example.com" "P:passw0rd" "M:LOGIN"
For my provider the U: (username) and I: (identity) values are the same, for others they may be different, e.g. to send from a different mailbox to the one being used to authenticate.
Build the authinfo database, and install the modified sendmail configuration:
cd /etc/mail
makemap hash authinfo < authinfo
make all
make install
service sendmail restart
Back in 2022 after I discovered letterboxd I decided to try working my way through the Academy of Motion Picture Arts and Sciences "Best Picture" Oscar winners that I'd not already seen.
First off, this isn't something I'd recommend doing unless you're keen on ticking off a list - they're some well documented utter stinkers that really aren't worth spending the time to watch, and many good films that whatever reason were passed over by the awards.
At the time I started I'd seen 19 out of the then 94 winning films, and I watched the 95th - Everything Everywhere All at Once (2022) - before the 2023 awards.
I was able to watch a few of the remaining films through streaming subscriptions we have or from having previously recorded them from television broadcasts. Most of the remainder I watched as digital rentals from Microsoft, Amazon, or Sky.
The final few: The Broadway Melody (1929), The Life of Emile Zola (1937), Gigi (1958), One Flew Over the Cuckoo’s Nest (1975), and Million Dollar Baby (2004) were not available to stream anywhere at the time but I was able to obtain them on DVD. A couple of those titles were available to 'buy' - essentially perpetual rentals - but I'm skepical of the longevity of those. If I'm going to spend more than I would for a rental I'd rather get a disk I can actually keep.
Before watching The Return of the King (2003), I also watched The Fellowship of the Ring (2001), and The Two Towers (2002), the first of which I'd already seen.
I won't try to review every film I've watched, but I do want to mention a few that I particularly enjoyed.
Wings (1927)
A remarkable film, both the first winner of the prize and, until The Artist in 2011, the only Silent Film to do so. Predating the development of model photography, all the flight sequences were performed with real aircraft and assistance from the Air Corps.
Grand Hotel (1932)
A simple plot weaved between a cast of characters in a Berlin hotel, elevated by fantastic performances by some big stars of the day including Greta Garbo and Joan Crawford.
An American in Paris (1951)
The story feels dated now but it's more than made up for by the great song and dance sequences.
The Godfather (1972)
One of those films I feel that I ought to have seen already and a bit of an odd experience as I'd seen many of the notable sceenes clipped out in documentaries or parodied in other media.
The King’s Speech (2010)
As a stammerer, this was a stressful watch. Firth manages to convey perfectly just how frustrating it is when the words you have to say just won't come out no matter how hard you try.
CODA (2021)
On one level a run of the mill coming of age story, but the centering of Deafness in the story adds an interesting angle to it.
Saw some great films over the last few days that were screening as part of the Bo'ness Hippodrome's "Hippfest" silent film festival.
The Blue Bird (1918) A children's fantasy based on a stage play, with what I assume were at the time innovative filming tecniques.
The Man Who Laughs (1928), based on a Victor Hugo novel with great performances and a main character who's appearance would go on to influence other creative works including DC Comics' Joker.
Shooting Stars (1928) A drama set itself in and around the British film industry of the time, offering as well as a gripping story a glimse into the practicalies of the silent era studio systems.
I've watched silent films at home before but it's a much richer experience to see them in a theatre, especially with the live music performances which had been arranged to accompany the films.
I really like the Hippodrome as a cinema venue, and I'll certainly try to catch the festival again next year.
While AX.25 is typically used over radio links, there are circumstances where it is useful to transport it by other means, such as wired or wireless ethernet, or over established wide area networks.
As with many other protocols, it is fairly simple to encapsulate AX.25 in another network layer, and dencapsulate it when it reaches its destination. For long-distance links it is common to us AX.25 over Internet Protocol, either on the Internet itself or over private networks such as AMPRNet.
In the situation where it is desirable to connect AX.25 systems on a local network, AX.25 over ethernet offers a less complicated solution.
Both Linux and BPQ32 implement AX.25 over Ethernet as 'BPQEther', and it can be used to interoperate between those systems.
On my local network I have a couple of systems running Linux's AX.25 implementation, one of which is connected a radio using a NinoTNC.
On Linux, making use of BPQEther is a simple matter or loading the 'bpqether' module.
One this is loaded, it will create a number of 'bpq' network interfaces, corressponding to the number of ethernet devices on the system. The mappings can be found in /proc/net/bpqether.
dev ether destination accept from
bpq0 eth0 ff:ff:ff:ff:ff:ff *
To make use of a device, it first needs to be assigned a callsign:
axparms --setcall bpq0 MYCALL-7
optionally, a specific ethernet destiation can be set using bpqparms -d, otherwise packets will be sent to the network broadcast address, which is adaquate for simple setups with only a small number of systems.
On my Debian based systems I use a the normal network interfaces files to manage bpqether interfaces:
# /etc/network/interfaces.d/bpq0
auto bpq0
iface bpq0 inet manual
up bpqparms bpq0 -d broadcast
up axparms --setcall bpq0 MYCALL-15
up ip link set dev bpq0 up
down ip link set dev bpq0 down
For AX.25 applications to make use of the port, it should also be listed in the axports file.
#name callsign speed paclen window description
bpq0 MYCALL-15 1000000000 255 7 BPQETHER for eth0
Introduction
The socat mechanism described in my AX25 over IP post can also be used to connect other AX.25 systems that use KISS together.
A practical use of this is to connect a LinBPQ instance to the Linux AX.25 stack on the system that it's running on. This can be helpful to share a TNC between the two systems, and to allow systems to reach NET/ROM systems via the other system.
socat
The first thing we need to do is set up the systemd service to manage socat.
I'm assuming BPQ will be running as the linbpq user as is the case for the packaged
version of LimBPQ distributed by OARC. You may need to adjust the ownership of the /var/ax25/pty/bpq directory if this is not the case on your system.
Create a file at /etc/systemd/system/kiss-socat-local.service containing the following:
# /etc/systemd/system/kiss-socat-local.service
[Unit]
Description=Socat interconnect for BPQ
After=network-online.target
Wants=network-online.target
[Service]
WorkingDirectory=/var/ax25
ExecStart=socat -d -d -ly pty,raw,echo=0,link=/var/ax25/pty/bpq/bpq1 pty,raw,echo=0,link=/var/ax25/pty/bpq/bpq2
ExecStartPost=/usr/bin/bash -c 'while ! [ -h /var/ax25/pty/bpq/bpq2 ]; do sleep 1 ; done'
ExecStopPost=rm /var/ax25/pty/bpq/bpq1 /var/ax25/pty/bpq/bpq2
User=linbpq
[Install]
WantedBy=multi-user.target
Create the /var/ax25/pty/bpq directory, then enable and start the service:
$ sudo mkdir -p /var/ax25/pty/bpq
$ sudo chown linbpq /var/ax25/pty/bpq
$ sudo systemctl daemon-reload
$ sudo systemctl enable kiss-socat-local
$ sudo systemctl start kiss-socat-local
axports
we need an entry in /etc/ax25/axports - use your callign and a suitable SSID:
local N0CALL-12 115200 255 7 Local connection to LinBPQ
kissattach
The kissattach program is used to set up communication between Linux's AX.25 stack and LinBPQ, via the socat process.
Create a file at /etc/systemd/system/kiss-tnc@.service containing the following:
# /etc/systemd/system/kiss-tnc@.service
[Unit]
Description=AX25 KISS TNC %I
[Service]
ExecStart=/usr/sbin/kissattach $TNC_TTY %i
ExecStop=pkill -f "kissattach $TNC_TTY %i"
ExecStartPost=/usr/bin/bash -c 'while ! /usr/sbin/kissparms -c 1 -p %i; do sleep 1; done'
TimeoutStopSec=5
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
This is a template unit file that can be used for several TNCs or AXIP tunnels.
To configure an instance for our AXIP tunnel, first enable it:
$ sudo systemctl enable kiss-tnc@local
Then edit it:
$ sudo systemctl edit kiss-tnc@local
Add the following to the top of the file and then save it:
[Unit]
After=kiss-socat-local.service
[Service]
Environment=TNC_TTY=/var/ax25/pty/bpq/bpq2
Restart=on-failure
RestartSec=5s
And then start the service:
$ sudo systemctl start kiss-tnc@local
LinBPQ
To configure the LinBPQ side of the connection, add the following to your bpq32.cfg file. Adjust the port number to fit with the numbering scheme you are using.
PORT
PORTNUM=2
ID=local
PROTOCOL=KISS
COMPORT=/var/ax25/pty/bpq/bpq1
SPEED=115200
QUALITY=0
MINQUAL=128
MAXFRAME=2
FRACK=4000
RESPTIME=1000
RETRIES=10
PACLEN=236
ENDPORT
The restart LinBPQ:
$ sudo systemctl restart linbpq
After a few moments you should find you can connect to your LinBPQ instance from Linux with axcall local and the callsign BPQ is using.
By increasing the QUALITY setting and configuring netromd on the Linux side, NET/ROM routing information can be exchanged between the two systems.
Introduction
This post aims to explain how to set up a basic Linux NET/ROM node for participation in Amateur Packet Radio.
Lines starting with $ are commands to be typed.
I'll be using a Raspberry Pi 3 running the current Raspberry Pi OS at the time of writing (bullseye), and a NinoTNC USB KISS TNC. These instructions will likely work for Debian and other debian-dervied systems, and other KISS TNCs including soundmodem and direwolf, but they will require their own configuration be done first.
I've also written an ansible role to perform the same steps described here.
SSIDs and aliases
AX.25 identifies ports using Amateur Radio callsigns. As it is often necessary to have more than one port or station, Secondary Station Identifiers (SSIDs) are used. These take the form of CALLSIGN-NUMBER.
The number can be from 0 to 15. When 0 is used it is typically ommited when the SSID is displayed and just CALLSIGN is shown.
While SSIDs can be used for anything there are some conventions associating particular numbers with particular types of service.
In general, low numbers are reserved for services that users will interact with and high numbers used for things like backbone ports which will not normally be seen.
NET/ROM aliases are used to provide convenient names for services, and are frequently used to provide geographic names for nodes. They should be 6 characters or less.
Software packages
Starting with a fresh, updated Raspberry Pi OS. we need to install ax25-tools and ax25-apps.
$ sudo apt-get install ax25-tools ax25-apps
Kernel modules
AX.25 and NET/ROM is included in the Linux kernel packages. AX.25 will load automatically when we configure the TNC, but we need to ensure netrom is loaded.
Add netrom to /etc/modules. To load it right away, run:
$ modprobe netrom
TNC
Before we can use the TNC we need to define an AX.25 port for it, and run kissattach to enable it.
Add the following to /etc/ax25/axports, replacing N0CALL with the callsign being used:
tnc N0CALL-15 57600 255 7 NinoTNC
This defines the ax.25 port 'tnc' with its callsign, serial port speed, packet size, window size, and finally a comment describing the port.
The kissattach program is used to set up communication between a Linux AX.25 interface and a KISS TNC.
In order to assure it runs automatically when the system boots, I'm going to use a systemd unit.
Create a file at /etc/systemd/system/kiss-tnc@.service containing the following:
# /etc/systemd/system/kiss-tnc@.service
[Unit]
Description=AX25 KISS TNC %I
[Service]
ExecStart=/usr/sbin/kissattach $TNC_TTY %i
ExecStop=pkill -f "kissattach $TNC_TTY %i"
ExecStartPost=/usr/bin/bash -c 'while ! /usr/sbin/kissparms -c 1 -p %i; do sleep 1; done'
TimeoutStopSec=5
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
This is a template unit file that can be used for several TNCs or AXIP tunnels.
To configure an instance for our TNC, first enable it:
$ sudo systemctl enable kiss-tnc@tnc
Then edit it:
$ sudo systemctl edit kiss-tnc@axip
Add the following to the top of the file and then save it:
[Service]
Environment=TNC_TTY=/dev/ttyACM0
$ sudo systemctl start kiss-tnc@tnc
At this point, ip link show should list an AX.25 port - ax0 as well as four netrom ports - nr0 - nr3.
We can test that the interface and TNC are working with the 'beacon' command:
$ beacon -s tnc 'This is a test'
If everything is working this will key the radio and send a short message.
If you don't have a radio attached to the TNC you can also check the operation of the beacon command by running axlisten -cra in a second terminal window - this will monitor all AX.25 activity on the machine.
NET/ROM port
There are two configuration files for netrom - nrports and nrbroadcast.
Much like axports, nrports assosicates a netrom port name with a callsign, as well as aliases, link quality and a descriptive comment.
Add the folllowing to /etc/ax25/nrports, again substituting the callsign, and replacing NCALL with a suitable alias for this port.
netrom N0CALL-14 NCALL 236 Linux Switch Port
nrbroadcast defines a list of AX.25 ports that we're going to run NET/ROM over and that we will use to broadcast routing information.
It also defines parameters which affect descisions about what routes we will accept, and information for other stations about our routes.
I'm not going to describe these in detail just now. If you're joining a NET/ROM network your link partner should be able to advise on the best settings for this file.
Comment out the default lines in /etc/ax25/nrbroadcast with # characters and add the following:
tnc 5 203 129 1
As with the TNC, we also need to run a command - nrattach - to enable our NET/ROM interface, and again I'll be using a unit file to make sure this happens on boot.
Create /etc/systemd/system/nrattach@.service with the following:
[Unit]
Description=AX.25 NET/ROM interface %I
After=network.target
StartLimitInterval=0
[Service]
Type=oneshot
ExecStart=/usr/sbin/nrattach %i
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
This is a template unit so we can use it for more than one netrom port if needed. Specify the netrom port name after an @ when issuing systemctl commands.
$ sudo systemctl daemon-reload
$ sudo systemctl enable nrattach@netrom
$ sudo systmectl start nrattach@netrom
Note: nrattach can be unpredictable if run in parallel. If you're going to use this unit for mutiple NET/ROM ports it will be necessary to ensure the ports are brought up in sequence. This r/systemd post explains how to do this.
netromd
We need to run netromd which will manage the exchange of NET/ROM routing information with other nodes on the network.
It doesn't require any configuration, just another unit file:
Create /etc/systemd/system/netromd.service:
[Unit]
Description=NET/ROM routing daemon
After=network.target
StartLimitInterval=0
[Service]
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/sbin/netromd -i
[Install]
WantedBy=multi-user.target
$ sudo systemctl daemon-reload
$ sudo systemctl enable netromd
$ sudo systemctl start netromd
Retaining routing information
To preserve bandwith, NET/ROM nodes tend to broadcast their routing information slowly, typically with intervals between 15 and 60 minutes. Because of this it can take a while for a rebooted node to obtain a working routing table.
To help with this, ax25-tools provides a nodesave command that can be used to save and reload the NET/ROM routing table when the system is rebooted.
The commands generated by nodesave will fail if the AX.25 interfaces aren't up, so it's necessary to include After= lines in the .service file to ensure nodesave.sh is run after relevant services have started.
Create /etc/systemd/system/nodesave.service:
[Unit]
Description=Persist NET/ROM routing information
After=network.target
After=kiss-tnc@tnc.service
StartLimitInterval=0
[Service]
Type=oneshot
ExecStart=bash -c '[ -x /etc/ax25/nodesave.sh ] && /etc/ax25/nodesave.sh; exit 0'
ExecStop=bash -c '/usr/sbin/nodesave > /etc/ax25/nodesave.sh && chmod 755 /etc/ax25/nodesave.sh'
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
$ sudo systemctl daemon-reload
$ sudo systemctl enable nodesave
As mentioned in my post about Digital Voice, the various technologies available all have their quirks and differences along with the many things they have in common.
A common feature between most of these systems is the notion of Talk Groups, to use DMR terminology. In simplex operation or on a standalone repeater system, Talk Groups allow separate groups of radio users to operate on the same frequency or frequency pair without hearing messages from other groups, and without their messages being heard by those other groups.
On an internet-linked repeater system, a Talk Group can made available on different repeaters or gateways anywhere in the world, creating a wide-area virtual channel.
It's common on DMR systems to have a handful of Talk Groups configured on a repeater or gateway, meaning that it will transmit when traffic for that Talk Group arrives from the internet. End radio users can select which talk group they wish to listen to on their radio.
During a recent conversation on OARC's #digital-voice
text chat I noted my experience that Yaesu's System Fusion lacked the ability
to have multiple Talk Groups ('Rooms' in Yaesu's terminology, Reflectors in
general amateur parlance) presented in this way, it only appearing to have the
ability to switch which single Room was available using the Wires-X interface
on the radio, or the "YSF Link Manager" feature in the Pi-Star DV Dashboard.
Jonathan Naylor (G4KLX), developer of MMDVMHost and many amateur radio digital voice tools, interjected that it was in fact possible do this, using DG-IDs.
DG-IDs are, I found, a bit of an underdocumented feature. The operating manual for my FT-991a includes the following description:
By matching the transmit DG-ID number to the uplink DG-ID number set in the DR-2X/XE System Fusion II digital repeater club, you can access the DR-2X/XE digital repeater used in the club. For communication only between transceivers in a group of friends, you can all match the same DG-ID number; then only your friend's voices will be heard.
The latter part of that is fairly understandable, and is similar to how Talk Groups can be used in DMR Simplex operation to separate groups of users, as described earlier. The first part is less clear to me.
A bit of internet searching led me to a description of a linked repeater system making use of the DG-ID system to allow users to choose whether their transmissions would be repeated by the repeater they were communicating with, or by every linked repeater in the group.
I also found discussion of part of the
YSFClients suite that I had not looked
at before - DGIdGateway. This work by Jonathan provides what I would
describe as a routing service between a given DG-ID and various System
Fusion services.
The sample DGIdGatway.ini
offers an insight into what it can do - associating DG-IDs with YSFGateway,
YSFParrot instances, various YSF2XXX bridges, and specific individual
reflectors.
From the example, I set up my own hotspot and radio with these DG-IDs
YSFGatewayYSFParrot- DV Scotland YSF Reflector (Static)
- Online Amateur Radio Club YSF Reflector (Static)
- FreeStar UK YSF Reflector (Dynamic)
- CQ-UK YSF Reflector (Dynamic)
- SDF ARC Talk Group (Static)
- Scotland Chat Talk Group (Static)
With the DG-ID set to 0, my radio operates as I have come to expect and I can either use the Wires-X menu or the Pi-Star DV Dashboard to change Reflectors.
By setting it to 1 through 7, my radio receives messages for the Reflector or Talkgroup selected, ignoring other traffic. The Static entries will always receive traffic from the internet, while the Dynamic ones require an initial local transmission to activate, and will remain active for a few minutes after the last local or internet transmission has been received. FreeStar and CQ-UK can busy at times so I'd prefer not to have them enabled all the time.
Usefully, the Pi-Star DV Dashboard will show DG-IDs associated with transmissions, so it is possible to observe where activity is taking place on DG-IDs other than the one selected on the radio.
DG-IDs 6 and 7 make use of the YSF2DMR bridge software to connect to
talkgroups on the BrandMeister DMR network. It would also be possible to have
additional DG-IDs configured to link to talkgroups on other DMR networks, or
indeed networks for other protocols for which a YSF2XXX bridge is available.
I have a post in the works about how my MMDVM hotspot is configured which will include more detail on how I went about setting up DGIdGateway.
Over the last couple of days I've been experimenting with the digital voice setup that I use at home.
Digital Voice technologies have been being explored by radio amateurs since the early 2000s following the introduction of DSTAR from ICOM and System Fusion from Yaesu on equipment specifically for amateur radio use, along with repurposed Digital Mobile Radio, NXDN, and P25 equipment originally designed and sold for the commercial two-way radio market.
While each of these have their own characteristics they share the same aim of making efficient use of radio spectrum while providing high quality audio along with data features such as location reporting and text messaging.
Many parts of the UK are well served by digital repeaters, and I am fortunate to have two within workable range, GB7FE on 70cm and GB7LV on 2m. Both of these are multi-mode with support for DMR, DSTAR and System Fusion. As a new user the learning curve, particularly for DMR, can be a little steep so being able to use existing infrastructure and obtain assistance from other amateurs is helpful.
My first experiences were on DMR using a relatively inexpensive TYT MD-390 handheld, a ruggedized version of the popular MD-380.
More recently, an upgrade of my main shack radio to a Yaseu FT-991a has brought me System Fusion capability.
In addition to the local repeaters, I also have a Raspberry Pi based device with a digital voice modem that acts as a 'hotspot' - a low-powered gateway to various digital voice networks.
For experimentation the hotspot is useful as it gives the amateur total control of what is going on, and visibility into both the RF and network sides of the system.
Up until now I've been using the Pi-Star linux distribution on my hotspot. Pi-Star is a great tool that works almost out of the box with an easy to use web front end, supports
As I wanted to learn more about how the underlying system works and explore some features not yet presented to the user by Pi-Star, I've been working on my own hotspot setup based on the Raspberry Pi OS Lite distribution and the same application software that Pi-Star uses. I'll write a separate post on how I went about that and how I got on.
This blog is powered by ikiwiki.