Starting with SVXLink we have to first acknowledge Tobias Blömberg SM0SVX the author developer of this wholly Amateur Radio produced package, without whom this project would not exist.
Originally a Linux EchoLink package it has now developed into a fully fledged Repeater and Simplex Controller with multiple facets.
In its purest form, it is a construction project for the hobbyist, and a learning curve that has multiple outcomes. In this way it requires a deep understanding…… however : Not everyone likes this approach.
I have taken the software 99.99% as intended, and produced a compiled and almost-ready-to-use image, that introduces a one-size-fits-most package, configurable almost to the users requirements.
Consequently there are some different adjustments dependant on the interface.
One of the most easy interfaces to use are the CM108/CM119 devices, that are manufactured to accept the digital signal requirements of PTT And SQL – Press-to-talk and Squelch/COS. The simplest of these has been the 2E0JJI board, without frills, that was inexpensive, but did exactly what was required.
Since then I have seen a number of similar devices, that work on the same principle, some more sophisticated with LED indicators, such as PTT and SQL. The CM108 has 4 GPIO ports for these purposes and the CM119 has 8 ports.
The TOADS board, DigiRig, F8ASB and many others built-in to the Shari-Node, Aursinc Hotspot and many others are examples of these device uses.
There has been one issue that has caused a little extra work, in that some of these devices failed when svxlink started with systemd, causing an irrevocable error. After extensive research I found a solution that in all cases seems to redress it. This solution will be in the addendum below.
SvxLink-ing with these devices invokes the use of hidraw, a dependency already available in the OS and svxlink. This permits the direct control of the PTT and SQL to be carried out in the svxlink.conf in Tx1 and Rx1 respectively, but using the GPIO Ports on the USB Sound device, and not those on the Raspberry Pi GPIO Bus.
This relies on the operating system detecting the presence and numeration of the hidraw device after detection of the soundcard by alsa. Almost by default this should be hidraw0 and very rarely changes. However this can change if multiple cards are used, for example to control a number of radio systems from the same instance of svxlink.
When inserting the card(s), the OS on boot will detect the USB-Soundcard portion, so that alsa detects it. It will also assign the hidraw characteristic. With a solo card this is never an issue as the Soundcard in the image used, detects the USB-Soundcard as Device 0,0 for the purposes of Alsactl and hidraw0 for the udev control of the PTT and SQL.
Inserting multiple cards is a lottery. I was working on a system where four such cards are inserted in a raspberry pi 4. The layout of the USB Sockets are such that the first to be detected would be top left, followed by bottom left followed by top right then bottom right, but the device detection for the USB Soundcards is not consistent with this arrangement, so we have to resort to udev rules to be interpreted by svxlink in a consistent fashion.
However this experiment has proved too much for the system to handle. Not an SVXLink limitation, not a Raspberry Pi Limitation, but simply an overload of the allocation to handle what are effectively four independent USB Stereo sound card and associated hidraw components, through a single isochronous channel available to USB2.0 devices. Despite having USB3.0 available, such soundcards are relegated to USB2.0 status. This is reported in the the forums of RaspberryPi.com. There is no remedy.
Two Devices are handled within limits, three falter then crash, removing the devices from the configuration, and four killed the hidraw processes immediately.
So to the configuration:
With a single device, the following code lines will need to be applied.
sudo addgroup hidraw
sudo usermod -aG hidraw svxlink
sudo nano /etc/udev/rules.d/cm-108.rules
Add the following line and save the file.
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="hidraw"
now
sudo udevadm control --reload-rules
sudo udevadm trigger
The device is now correctly registered.
Under normal circumstances ls -l /dev/hidraw* produces the following result.
ls -l /dev/hidraw*
crw-rw-r-- 1 root hidraw 244, 0 Apr 4 19:20 /dev/hidraw0
The modification of the svxlink.service is minimal, removing the lines that refer to svxlink_gpio_setup.service.
sudo nano /usr/lib/systemd/system/svxlink.service
Once the lines are removed perform the following
sudo systemctl daemon-reload
sudo systemctl enable --now svxlink
This last line re-emphasises the start of the service even after reboot, as well as restarting the service in its new form.
sudo addgroup hidraw
sudo usermod -aG hidraw svxlink
sudo nano /etc/udev/rules.d/cm-108.rules
Add the following line and save the file.
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="hidraw"
now
sudo udevadm control --reload-rules
sudo udevadm trigger
The device is now correctly registered.
Under normal circumstances ls -l /dev/hidraw* produces the following result.
ls -l /dev/hidraw*
crw-rw-r-- 1 root hidraw 244, 0 Apr 4 19:20 /dev/hidraw0
The modification of the svxlink.service is minimal, removing the lines that refer to svxlink_gpio_setup.service.
sudo nano /usr/lib/systemd/system/svxlink.service
Once the lines are removed perform the following
sudo systemctl daemon-reload
sudo systemctl enable --now svxlink
This last line re-emphasises the start of the service even after reboot, as well as restarting the service in its new form.
If you have installed SvxLink from any other source, then the results should be the same. As I explained, the software source for this package is 99.99% original of Tobias SM0SVX, with just a couple of minor tweaks, to compensate for changes in the ancillary software.
The ownership permissions for the svxlink software and the dashboard are identical, svxlink:svxlink in order for the Dashboard to run some of the editing functions, with special permission granted to some of the bash commands in sudoers.d/svxlink to perform control on the services.