SvxLink turns a transceiver and a Linux box into a radio operating system

From an EchoLink client to a radio operating system

SvxLink is a project that develops software targeting the ham radio community, and the origin story is given in one sentence. It started out as an EchoLink application for Linux back in 2003 but has now evolved to be something much more advanced.

That history explains a lot about the shape of the project. EchoLink is a service that carries amateur radio audio over the internet, so a client for it is a program that captures audio from a radio, encodes it, sends it across the internet, and plays back the audio it receives. That is already a voice service, and it is already a full-stack problem: audio handling, network transport, a signalling channel and a way for an operator to control it.

What grew out of that is described as the SvxLink Server, often just called SvxLink, and it is a general purpose voice services system. Connected to a transceiver, it can act as an advanced repeater system and it can also operate on a simplex channel.

A repeater is the classic amateur radio arrangement where a station receives on one frequency and retransmits on another, so that anyone in range can talk through it as if they were in the same room. A simplex channel is the simpler arrangement where one frequency is used for both directions, and the station keys up to talk and releases to listen.

The phrase the documentation offers for the whole thing is worth repeating because it is the clearest description of the ambition: one could call it a radio operating system.

That is a fair description rather than a flourish. A repeater controller has to do a surprising amount: manage the timing of a push-to-talk with the right delays so that stations do not talk over each other, generate the identifying tones, record and replay a voice mail message, answer DTMF key presses, monitor for activity, and expose all of that to an operator over a local link. That is an operating system for a radio, with the hardware being a transceiver.

The project is C++, the homepage is svxlink.org, the default branch is master and the last push was on 2026-10-20.

Modules in C++ or TCL, and why that matters

The architecture claim is that SvxLink is very extensible and modular, and that voice services are implemented as modules which are isolated from each other. Modules can be implemented in either C++ or TCL.

Two things follow from that, and the second one is the interesting one.

The first is that the core of the system, which is the audio path, the radio control and the transport, does not change when you add a service. A service is added alongside rather than woven in. For a system that has been running in ham radio shacks for two decades, that matters, because those shacks get upgraded rarely and by people whose main job is not software.

The second is that TCL modules can be written without touching C++. TCL is the language used by the EchoLink and APRS-adjacent amateur software world, and it is interpreted, so a module can be edited on the radio itself with a text editor over a terminal connection and reloaded without recompiling anything. For an amateur operator, being able to change the behaviour of their station from a laptop in the shack, without a build toolchain, is a considerable practical advantage.

The isolation is what makes the two-language approach safe. A TCL module cannot corrupt the core, and the core does not need to know what a TCL module is doing beyond a defined interface.

The module list in the documentation shows the range, and several of them are things you would not expect a repeater controller to do.

Help is a help system. Parrot plays back everything that is received, which is the classic way to check that a station is working. EchoLink connects to other EchoLink stations. DtmfRepeater repeats DTMF digits received on the repeater, so that a keypad press is heard by everyone on the channel rather than only acted on locally. TclVoiceMail sends a voice mail to other local users, which is how a controller records a message for someone on the frequency. PropagationMonitor announces propagation warnings from dxmaps.com. SelCall sends selective calling sequences by entering DTMF codes. MetarInformation plays airport weather information. Frn connects to Free Radio Network servers. And Trx does remote control of transceivers using DTMF.

Read as a set, those modules describe a station that is a radio, a telephone, a weather station and an announcement system, and that can be driven from a keypad.

Qtel and the EchoLink network

The second product in the repository is Qtel, the Qt EchoLink client, described as a graphical application used to access the EchoLink network.

That is a shorter description than the SvxLink Server section gets, and the reason is that Qtel is the older half of the project. EchoLink was the original purpose, so Qtel is where the lineage is, and the server grew around it.

The split is still sensible in the current arrangement. The server is the thing that sits next to the transceiver and runs the station. The client is the thing that sits next to you, or on a different machine entirely, and lets you talk to a station somewhere else. The server is what a club operates; the client is what a member installs.

The Qtel application is also where the Qt dependency comes from, and the project is otherwise built in C++, so the GUI is a separate piece of the tree with its own build requirements.

The EchoLink network is worth understanding as a service, because it explains a lot about why the project has survived since 2003. EchoLink connects amateur radio stations over the internet, so a ham in one country can talk to a station in another, and an operator with a home station and a portable radio can link them. The key constraint of the network is that it is designed for amateur radio operation, which means it enforces the rules of the service: no commercial use, identification requirements, and a connection model built around the idea that a station is a physical place with a transmitter.

That constraint is exactly why a dedicated client exists. A general VoIP application cannot connect to an EchoLink node, because an EchoLink node is not an internet telephony endpoint in the ordinary sense; it is a radio station with a very specific authentication and status model. Qtel speaks that model, and it is why the module in the server that connects to other EchoLink stations is called simply EchoLink.

The project also maintains a separate repository for sound clips, the English sound clip files for the server, at svxlink-sounds-en_US-heather. That is a small example of the pattern this project follows: the core software stays in one place and the assets and the user-facing tools live beside it.

Resources, releases and the shape of the repository

The resource list is a good guide to how the project is maintained, and it covers the standard channels plus a couple that are unusual.

There is the project home page at svxlink.org, which is where the documentation wiki lives, along with the issue tracker and the releases page for downloading source code releases.

The mailing list is on groups.io rather than the old mailing list software, and the chat is on Gitter. Both are the older corners of the open source world, and they are consistent with a project whose community is amateur radio operators rather than professional developers.

The release naming is distinctive and worth understanding. The recent releases are 26.05.2, dated 09 October 2026, 26.05.1 from 26 July 2026, and 26.05 from 2026-05-24. The version number is the year and month of the release, followed by a sequence number.

That convention has a practical effect. An amateur radio club operating a station needs to know whether the software it is running is current, and a date-based version answers that question directly. It also makes it obvious when a security fix or a bug fix has landed, since the sequence number increments on the same version line.

The build badges are a mix of generations too. The CodeQL analysis workflow is active, which is the security scanning that matters most in a project that runs on machines exposed to the internet. The Travis CI badge is present but commented out in the markup, which is a small sign of a project that moved its continuous integration along without clearing the old references.

The repository layout is distinctive for the same reason. There is src/ for the code, distributions/ for packaging files, and then docker/, gnuradio/ and matlab/ directories. The last two are integrations rather than parts of the product: a GNU Radio block for using SvxLink from a radio software workflow, and a MATLAB interface for driving it from a simulation. Both point at the same design intent, which is that SvxLink is a component you build on rather than an application you run alone.

There is a docker/ directory as well, which has become the usual way to deploy a service that is fiddly to install, and an INSTALL.adoc and a README.adoc in AsciiDoc rather than Markdown, which is a long-standing convention in this part of the open source world.

The project also carries a COPYRIGHT file at the root, alongside the licence, which is the pattern used by software that started as a collection of contributions from several people.

Where this fits, and what to check first

The comparison worth making is with the other two common ways to run an amateur radio station with internet connectivity.

The first is a hardware controller. Many commercial transceivers include a built-in repeater controller and an internet interface. That is simpler, and for a station whose only requirement is to be a repeater, it is usually the right answer. What it does not give you is a programmable environment, and it does not give you the ability to add a service that the manufacturer did not anticipate.

The second is Asterisk or FreeSWITCH with a SIP channel to the radio. That gets you a very large telephony platform and a lot of configuration, and it treats the radio as one channel among many, which is the wrong way round if the radio is the point.

SvxLink is the middle case, and the middle case is a real niche: a Linux box, a transceiver, and a programming environment where the voice services are small programs you can change.

The trade-offs follow from that. You need a Linux machine alongside the radio, and somebody has to keep it running and patched. The documentation, wiki and mailing list are the support channel for that. The module interface means a service you want that is not in the list has to be written, in C++ or in TCL, against the interface.

What to check first is the module list, because that is the actual feature set. The ten modules named are the ones the documentation highlights, and there are likely others, but the ones named cover the interesting ground: EchoLink connectivity, DTMF handling, voice mail, propagation and weather announcements, selective calling, and remote transceiver control.

The second thing to check is the release you pick. A system that talks to the internet, runs for years unattended in a shack, and handles audio in real time is exactly the kind of software where the version matters, and the date-based naming makes it easy to see whether you are current.

The third is the codec and audio path, since that is where the hard real-time constraints live and where the documentation's emphasis on the modular design pays off. If your requirement is a station that answers phones and plays a message, this is more machinery than you need. If it is a station with a personality, running its own services, reachable over the internet, this is the thing.

Editorial conclusion

Adopt SvxLink if you run an amateur radio station and want a repeater, simplex operation and internet-connected voice services from a Linux box, since the module architecture lets you add a service without touching the core. Skip it if you need a general-purpose telephony platform or a commercial base station, because this targets amateur radio and the ecosystem around it. Verify first which modules you need and whether the ones you want are built in or have to be written, and that the release you install matches your distribution, since the version line is dated and namespaced by year and month.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. sm0svx/svxlink on GitHub