Been playing around with SvxLink for a while. For those who don't know, SvxLink is a "voice services system" that started out as an Echolink client, but has evolved over the yars to become a pretty full featured repeater controller with powerful RoIP link capabilities, voting, multi Tx operation and more. SvxLink still includes an Echolink module, and it also has its own svxreflector linking system, which allows a single reflector to host many talkgroups, much like DMR.

One of the neat features of SvxLink is the ability to use RTL-SDR dongles as receivers. One dongle can support multiple receivers, provided all receivers fall within the dongle's bandwidth, which is determined by the sample rate (either 960 kHz or 2.4 MHz). However, what was missing was a low cost software define transmitter, which I needed for my next addition to the system - an IP linked receiver and transmitter. Looking around, I didn't find any suitable low powered options, and the cheapest SDR hardware I found was the HackRF, which was still a few hundred dollars (with cheaper Cinese clones).

Then I discovered rpitx, which is a sofware defined transmitter that outputs on one of the Pi's GPIO pins. Power is in the order of 10mW, which is perfect for my application, with the only drawback being that the transmitters output is rich in harmonics, because it is basically a square wave carrier. However, that is easily fixed by a low pass filter, which can be easily homebrewed, and for 70cm, eBay sells a suitable LPF at a dirt cheap price, ready to go.

The next stage was to work out how to interface rpitx to SvxLink. This was a multi step process:

First, look at the script which tests FM transmission, and find out how it works. The script simply piped a mono .WAV file tp rpitx.

Next, replace the .WAV playback with using arecord to record from an ALSA loopback device and output to standard output. The format required was 48 kHz, 16 bit, mono. To test this, I used aplay to play .WAV into the other side of the loopback device, and the audio came through rpitx as expected.

With the loopback device working, I then sonfigured the remotetrx part of SvxLink to send its audio to the input side of the loopback device. remotetrx then talks to the main system. I also had to configure the main SvxLink server to send audio to the new trmote transmitter, when there was activity on the systemm. Again, once the configuration was sorted, all worked well.

Now came the hard part - getting PTT signalling. A bit of Googling came up with a solution that uses a Perl script, some Python and GNU Radio, alongside rpitx. This seemed a bit "heavy" to me, and as I'm not running a GUI, it was impractical. A closer examination shows that GNU Radio is really only acting as a receiver for audio sent via USB, and the actual PTT handling doesn't involve GNU Radio. I didn't need the UDP audio path anyway, because I already had ALSA loopback working to pass audio between SvxLink (remotetrx) and rpitx. I could simplify the system considerably.

I kept the Perl script, because remotetrx outputs PTT state via a pty that the Perl script reads. The Perl script calls a start_tx.sh script when PTT is pressed. This script starts rpitx with the correct parameters to enable the transmitter. When PTT is released, the Perl script calls stop_tx.sh, which simply kills arecord and rpitx.

It took a couple of goes to get the scripts right, but now I have a self contained Pi SDR transceiver. The receiver is a standard RTL-SDR dongle, which SvxLink can use directly, while the transmitter uses the above rpitx setup.

What's left is to package the system into a suitable enclosure and add a low pass filter (on order from eBay), so my portable link can travel with me. I have it configured for wifi access to my 4G mobile hotspot. For both security and accessibility, I use ZeroTier to put the Pi on the same virtual LAN as the main SvxLink server. This makes the system work the same, regardless of the connection used.

The next test, maybe tomorrow, is to test the system running on 4G (I've been using Ethernet on the home LAN for setup).

Homebrew isn't dead, but it often involves tinkering with software, instead of solfering parts. :)


... Jesus Saves -- passes to Moses - he shoots! HE SCORES!!!
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
# Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (432:1/101)
* Origin: Ham Inter-network Echomail Gateway. (21:1/143.0)