A number of folk are exploring the latest versions of SVXLink and the possibility of linking together numbers of repeaters/nodes.

I will attempt in the article to illustrate the simplicity of this application.

I will explain the installation of svxreflector, and its configuration, and set-up.

I will then explain how the system of nodes can interface with the reflector.

I will then attempt to explain the svxportal, which is not the simplest of tools, but provides a pictorial view of the network as a whole.

A small warning. If there is already an svxreflector/svxportal within your domain, seek to connect to it rather than create your own, as the more networks there are, the less activity ensues as it gets watered down. A national network perhaps is optimal, but regional networks limit connectivity. Read on for further information.


My earlier articles introduce the SVXLink package that can be install on a Raspberry Pi and interfaced simply with an existing transceiver or transceiver pair, to create a Simplex or Duplex Node. My script available on builds such a node for you. Read the instructions. The resulting build, designed for the UK Amateur market, is easily adaptable if you are bash-savvy, for other devices. In the final compilation, there are settings for the already set but lack the final connection requiring a password to join the network.

Building an SvxReflector.

Assuming that you are not in the UK and wish to make a Reflector to which to attach a number of repeaters or simplex node, you will need a linux capable machine or virtual machine on a hypervisor on which to build an operating system. I recommend Debian 11 or Debian 12 server. There is no requirement for a Graphical User Interface. Note: I did not use GUI, as many folk do not understand acronyms.

With your Debian installed, you may enter the terminal and install a number of packages. These are required to both facilitate installation and compilation of the svxreflector package. Unlike the raspberry pi, we can use root to install and run everything. If using Debian 11 follow this example. If using Debian 12 however, change the PHP8.0 to PHP8.2 before running the line.

apt-get update
apt-get install -y ca-certificates curl gnupg
mkdir -p /etc/apt/keyrings
curl -fsSL | sudo gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg
echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg]$NODE_MAJOR.x nodistro main" | tee /etc/apt/sources.list.d/nodesource.list
apt update
apt upgrade -y
apt install build-essential g++ make cmake libsigc++-2.0-dev php8.0 nodejs libgsm1-dev libudev-dev libpopt-dev tcl-dev libgcrypt20-dev libspeex-dev libasound2-dev alsa-utils libjsoncpp-dev libopus-dev rtl-sdr libcurl4-openssl-dev libogg-dev librtlsdr-dev groff doxygen graphviz python3-serial

You will later be required to install mariadb-server and possible phpmyadmin to run svxportal.

In any doubt the wiki pages are a good source of material.

The next lines are important too, for permissions to run correctly in the svxreflector.

mkdir /etc/svxlink
groupadd svxlink
useradd -g svxlink -d /etc/svxlink svxlink
usermod -aG audio,nogroup,svxlink,plugdev svxlink
usermod -aG gpio svxlink

Install and compilation.

You should already be in the root directory, but in case of any doubt simply type cd and enter.

git clone (although the .git can be omitted).mkdir svxlink/src/build
cd svxlink/src/build
Yes this is a single line, and do not forget the dots or the correct case when typing.
make doc
make install

We have to correctly set our logging and configuration mechanism as follows.

nano /etc/default/svxreflector
# The user to run the SvxReflector server as
# Specify which configuration file to use
# Where to place the log file
# Where to place the PID file
I recommend a change to the LOGFILE adding .log to the /var/log/svxreflector part to satisfy convention.
Your first task is to determine the callsigns of the Repeaters or Node to which you are granting access. These have to be configured in the following file.
nano /etc/svxlink/svxreflector.conf
# Configuration file for the SvxReflector SvxLink conference node


#MyNodes="Change this key now!"
#SM3XYZ="A strong password"


Once you have configured these, it remains for you to disemminate the passwords to the repeaters to set up in the [ReflectorLogic] in their svxlink,conf files.

To set the svxreflector to run we have two commands, with a further 2 command to stop and restart.

systemctl enable svxreflector.service
systemctl start svxreflector | tail -f /var/log/svxreflector.log 

(this part is to view that it is working – cntrl-c to exit this)
To Stop the svxreflector:
systemctl stop svxreflector

To Restart the svxreflector – (there is no need to stop the svxreflector to edit the svxreflector.conf)
systemctl restart svxreflector

For further information always look at the man svxreflector page in the terminal.


Necessarily your svxreflector has to have a public IP address to share with the repeaters and node that need to connect to it. How you do this is beyond the scope of the article, but there is plenty of help available. This IP address has to appear in HOSTS in the svxlink.conf files in [ReflectorLogic] of those repeaters, together with the CALLSIGN and AUTH_KEY before they will correctly connect. The Port number at HOSTS_PORT=5300 must correspond between the node and the svxreflector.

Before the Repeater or Simplex node can be connected, the following conditions must be met.

In the Repeater or Simplex Node these line must exist in [GLOBAL] within the svxlink.conf


And [LinkToReflector]


and finally

FMNET=URLof svxreflector
AUTH_KEY="Ask your SvxReflector Manager"
# to be added added on connection to svxportal-uk

The rest of the installation is up to you. What TalkGroups you set is up to you, but the DMR SYSTEM internationally has already formatted such talkgroups using the MobileCountryCode system in place. To deviate from this is your choice, but to be ultimately compatible with future integration, consideration of this existing system is important. For the UK TalkGroup (TG) 235 is considered as a source National Talkgroup, as is 204 for the Netherlands and 208 for France. Look around before making a decision. Be different if you have to be, but if there is an existing pattern why not use it?

In this scenario, we can have a National Talkgroup 235 on all the nodes, with QSY channels for a chat, or Regional Talkgroups such as 23590 for the UK Midlands nodes, and an Extra Special **TG23561 for emergencies or technical queries.

TalkGroups and How To Call Them

Existing repeater keepers may be concerned on how their repeaters may be ‘usurped’ by the network, but this does not have to be the case.

Every node or repeater connected to the svxreflector is connected passively, that is to say each repeater is a stand-alone device, though with potential for extramural contacts.

Within each repeater [ReflectorLogic] is a DEFAULT_TG=0, this is to say it will always default to passive connection after set time-out values. There is also a MONITOR_TGS= list of possible TalkGroups that may be available. So as an example MONITOR_TGS=**235,*2350,23590   indicates that 235 has high priority, 2350 medium priority, and 23590 has no priority. This is to say that if someone on the network activates one of these talkgroups, every repeater or node that has the talkgroup in its MONITOR_TGS list, will connect Dynamically, so a wider QSO can take place. The time limits are set by each repeater, and not by the network, as are the Talkgroups in the list. So the Repeater Sysop has complete control.

Users on a repeater can use the repeater purely as a local system without using DTMF. As explained it is a passive connection to the network and therefore a stand-alone repeater. To activate a talk group from a repeater, the user sends DTMF code 91 + the TalkGroup number + # in one transmission. His second transmission will activate that talkgroup on the whole network, waking any node or repeater with the same talkgroup in the MONITOR_TGS list. Again the length of QSO is determined by the lack of use, and will drop out after the programmed time in the repeater. However a user can disconnect by sending 910# by DTMF in his last transmission. Should anyone transmit on any other woken repeater, there is a change the TG will be reactivated, and this is due to perhaps the other repeater having different Time-Out settings. It’s a matter of coordination.

The interesting thing however, is that if two users, each make a mutual change to an unlisted talkgroup for example they both send 912356# for example, then this is entirely feasible.

There are a number of Codes Available. Assisted by the settings in the svxreflector at #TG9999 which is currently unset in the example above, a forced QSY can take place to a random talkgroup or a known talkgroup. At the Present 91+TG+# and 91+# connect and disconnect respectively. 9# isolates the repeater from the network, for a club net for example, and 91# restores it to the network. In my unit 92 seems not to work and I am investigating why this should be.

One last advisory to Repeater Keepers. In each of the .conf files for the Modules in /etc/svxlink/svxlink.d/ is a line MUTE_LOGIC_LINKING. I would ask that in every case this is set to =1, to prevent traffic from the Modules such as EchoLink passing inadvertently over the network, avoiding potential looping due to mirroring of traffic.

As usual these are my own opinions, but any questions or potential corrections are welcomed and indeed invited.

Needless to say I have been working with these packages for more than 10 years, and I am still learning.

For the next stage for the svxreflector builder, go to However to build it requires a little knowledge of the git fork changes required to important the up-to-date version svxportal 2.6 beta. In your svxreflector terminal

cd /var/www

If there is a folder html present, rename it as follows.

mv html html.old

Now download the files

git clone html

Note the space between SVXportal and html. We need now to import the correct fork svxportal-2-6-beta, as we are currently in the master.

git branch -a

This will show the branches available.

git checkout svxportal-2-6-beta

git pull origin svxportal-2-6-beta

Now we have all the files we need. If you now go to the instruction page on the github, you will find you should have installed everything you need. You already have PHP, PHPmyAdmin and Mariadb-server. You now need to spend a great deal of time reading and understanding Peter’s work, learning about MySql, and a few other things. All questions relating to this part of the project go directly to Peter SA2BLV.

When it is working, The complete dashboard provides an entry point for Repeater users to register initially and created their own node_info.json files for /etc/svxlink and SvxReflector to use. Be prepared to provide your repeater users with password, and assistance. Just a little advice, unless you wish to go down a rabbit hole of Multiple CTCSS codes, ignore all references to this within the construction.

So we have explained how to install the svxreflector, and how to route it for your repeater community.

We have lightly touched on how your repeater keepers link with the reflector, and how to work with TalkGroups.

Finally we have pointed you in the direction of  how to visually portray the output of your svxreflector for public consumption.

Click here for an example

Best of luck.


Leave a Reply

Your email address will not be published. Required fields are marked *