SVXLINK.CONF(5)
💖 SVXLINK.CONF 💖
okay bestie, welcome to the svxlink.conf(5) glow-up 💅 this is the man page from the File Formats corner of the manual, and it's literally all about the configuration file for the SvxLink server. grab a snack, this is part 1 of a whole saga 🍓
🌸 NAME 🌸
svxlink.conf — the configuration file for the SvxLink server 🫶
✨ DESCRIPTION ✨
So svxlink is a general purpose voice service system for ham radio use, periodt. And this man page? It describes the SvxLink server configuration file format. That's it, that's the vibe 🌈
Now, the way SvxLink finds its config files is a whole little journey, no cap. It looks in a bunch of places:
- First it tries to find a user specific configuration file. It looks for that in:
$HOME/.svxlink/svxlink.conf- If no user specific configuration file can be found, SvxLink goes looking for the system wide configuration file:
/etc/svxlink/svxlink.conf- And btw, the
--configcommand line option can be used to specify, like, an arbitrary configuration file. main character energy fr 👑
🦋 FILE FORMAT 🦋
The config file is in the famous INI-file format. Here's a generic example of how such a file might look, iconic:
[SECTION1]
VALUE1=1
VALUE2="TWO "
VAULE3="Multi "
"line"
[SECTION2]
VALUE1=2It's a simple format — name=value pairs that belong to a section. When we're yapping about it in written text, a specific configuration variable can be referred to as SECTION1/VALUE2, which lowkey just means "configuration variable VALUE2 in section SECTION1" 💜
And yes, the same variable name can exist in two different sections, it's giving ✨variety✨. For example, VALUE1 in section SECTION1 has the value 1 and VALUE1 in section SECTION2 has the value 2.
Values that contain spaces at the beginning or the end of the line must be surrounded by citation characters (you know, quotes) — see SECTION1/VALUE2. Same energy for a multi line value, see SECTION1/VALUE3. okay and ngl, notice how VALUE2 ends in TWO with a space, and VAULE3 spelled itself wrong? not me pointing fingers, the example is just like that 🙈
💅 CONFIGURATION VARIABLES 💅
Here's the description of, like, all the configuration variables SvxLink understands. We go section by section, no skipping, no summarising, we read the whole thing bestie 📚
👑 GLOBAL 👑
The GLOBAL section contains application global configuration data. big-picture stuff, iykyk.
MODULE_PATH
Specify where the SvxLink modules can be found. If MODULE_PATH is not specified, the standard search paths for library files will be used. If that also fails, a hard-coded default will be used. What that default is depends on the architecture, but typically on a x86_64 system it is /usr/lib64/svxlink. Leaving this variable unset should work in most cases 🫶
LOGIC_CORE_PATH
Specify where the SvxLink logic core plugins can be found. If not set, a hard-coded default will be used. What that default is depends on the architecture but typically on an x86_64 system it is /usr/lib64/svxlink. Leaving this variable unset should work in most cases.
and if this variable is set to empty, the standard search paths for library files will be used (see man 3 dlopen). subtle difference, okay?? 🙈
LOGICS
Specify a comma separated list of logic cores that should be created. The logic core is the thing that ties the transceiver and the voice services (modules) together — it's giving matchmaker 💘 It contains the rules for how the radio interface should be handled. The specified name of a logic core must have a corresponding section specified in the config file. This is where the behavior of the logic core is specified.
CFG_DIR
Specify the path to a directory that contains additional configuration files. If a relative path is specified, the path will be relative to the directory where the main configuration file is at. All files in the specified directory will be read as additional configuration. Filenames starting with a dot (hidden files) or not ending in .conf are ignored. so rude but okay ✋
TIMESTAMP_FORMAT
This variable specifies the format of the time-stamp that is written in front of each row in the log file. The format string is in the same format as specified in the strftime(3) manual page. The default is "%c" which is described as: "the preferred date and time representation for the current locale". The environment variables LC_TIME, LC_ALL and LANG will affect how this time format will look. For example, setting LC_TIME="sv_SE.UTF8" will give you Swedish time-stamp representation 🇸🇪 (slay). Other examples of format specifiers are:
%d- The day of the month as a decimal number (range 01 to 31)%b- The abbreviated month name according to the current locale%Y- The year as a decimal number including the century%H- The hour as a decimal number using a 24-hour clock (range 00 to 23)%M- The minute as a decimal number (range 00 to 59)%S- The second as a decimal number (range 00 to 60)%f- Fractional seconds in millisecond resolution (000-999)
That last one (%f) is a SvxLink specific formatting specifier, so don't go looking for it in strftime(3), bestie 💀
Example: TIMESTAMP_FORMAT="%d %b %Y %H:%M:%S.%f" would give a time-stamp looking something like: "29 Nov 2005 22:31:59.875". chef's kiss 🧚
CARD_SAMPLE_RATE
This configuration variable determines the sampling rate used for audio input/output. SvxLink always works with a sampling rate of 16kHz internally, but there still are some benefits from using a higher sampling rate. On some sound cards the filters look pretty bad at 16kHz and the amplitude response will not be uniform, which among other things can cause problems for the software DTMF decoder 😭
Some sound cards also sound very bad at 16kHz due to insufficient anti-alias filtering or resampling effects. These, often cheaper, sound cards sound OK at 48kHz. so basically: cheap card? maybe go higher 🌈
The downside of choosing a higher sampling rate is that it puts a little bit more load on the CPU, so if you have a very slow machine (<300MHz), it might not have the computational power to handle it. she's fragile 💀
Supported sampling rates are: 16000 and 48000.
CARD_CHANNELS
Use this configuration variable to specify how many channels to use when opening a sound card. For normal sound cards the only practical values to use are 1 for mono and 2 for stereo. The latter is the default 👑
When using the sound card in stereo mode it is possible to use the left and right channels independently to drive two transceivers. When using the sound card in mono mode, both left and right channels transmit/receive the same audio. two transceivers, one sound card, it's giving multitasking 💅
LOCATION_INFO
Enter the section name that contains information required for transferring positioning data to location servers. Setting this item makes the system visible on the EchoLink link status page and the APRS network. visibility, we love to see it ⭐
LINKS
Enter here a comma separated list of section names that contains the configuration information for linking logics together (see Logic Linking) 🔗
🎀 Common Logic configuration variables 🎀
A logic core is what defines how SvxLink should behave on the RF channel. The SvxLink server can handle more than one logic core, and so can be connected to more than one transceiver. When configured, a logic core is loaded at runtime as a plugin 🧩 See the LOGIC_CORE_PATH configuration variable for more info on how SvxLink finds the logic core plugins.
The configuration variables below are common to all logic types. Configuration variables that are specific to a certain logic core type are described further down in a section of their own.
TYPE
The type of logic core this is. The documentation for the specific logic core type you want to use describes what to write here. (so like, go read that one, bestie 🫶)
RX
Specify the configuration section name of the receiver to use. All configuration for the receiver is done in the specified configuration section.
TX
Specify the configuration section name of the transmitter to use. All configuration for the transmitter is done in the specified configuration section.
MODULES
Specify a comma separated list of configuration sections for the modules to load. This tells SvxLink which modules to actually load on startup. it's the guest list, be picky 💅
CALLSIGN
Specify the callsign that should be announced on the radio interface 📻
SHORT_VOICE_ID_ENABLE
A basic toggle to enable the voice ID announcement during the short ID announcements. Set value to "1" to enable the voice option, and "0" to disable.
SHORT_CW_ID_ENABLE
A basic toggle to enable the CW ID announcement during the short ID announcements. Set value to "1" to enable the CW option, and "0" to disable.
SHORT_ANNOUNCE_ENABLE
A basic toggle to enable the custom announcement during the short ID announcements. Set value to "1" to enable the announcement option, and "0" to disable.
SHORT_ANNOUNCE_FILE
The full path to a file to use for custom announcements broadcasted during a routine short ID 📁
LONG_VOICE_ID_ENABLE
A basic toggle to enable the voice ID announcement during the long ID announcements. Set value to "1" to enable the voice option, and "0" to disable.
LONG_CW_ID_ENABLE
A basic toggle to enable the CW ID announcement during the long ID announcements. Set value to "1" to enable the CW option, and "0" to disable.
LONG_ANNOUNCE_ENABLE
A basic toggle to enable the custom announcement during the long ID announcements. Set value to "1" to enable the announcement option, and "0" to disable.
LONG_ANNOUNCE_FILE
The full path to a file to use for custom announcements broadcasted during a routine short ID 📁
CW_AMP
Specify the amplitude of the CW that should be used during any cw traffic, typically announcements. The amplitude is specified in dB. Default: -6.
CW_PITCH
Specify the pitch (frequency in Hz) of the CW that should be used during any CW traffic, typically announcements. Default: 800.
CW_CPM
Specify the Characters Per Minute of the CW that should be used during any CW traffic, typically announcements. If both CW_WPM and CW_CPM is set, CW_CPM will be used. Default: 100.
CW_WPM
Specify the Words Per Minute of the CW that should be used during any CW traffic, typically announcements. If both CW_WPM and CW_CPM is set, CW_CPM will be used. Default: 20.
read that again bestie — CW_CPM wins the tie every single time 👑
PHONETIC_SPELLING
Specify if the spelling of callsign and other words should be announced on the radio interface using phonetic or non-phonetic spelling. "1" to use phonetic sounds (legacy default), or "0" to use non-phonetic sounds. Note that this option may not be available for all language packs. 😭
okay and that's where part 1 stops, so don't go anywhere — there's more coming 🌸
TIME_FORMAT
So what clock vibe are we announcing the time in? 🕐 Valid options are literally just "12" and "24" — that's the whole menu, bestie. Pick one and move on.
⚠️ NOTE: may not work for all language packs.
SHORT_IDENT_INTERVAL
The number of minutes between short identifications ✨. The whole point of the short ident is just to announce that the station is on the air — typically only the callsign gets transmitted. Nothing fancy. For a repeater, a good value is ten minutes; for a simplex node, one time every 60 minutes is probably enough, honestly.
Here's the tea though: LONG_IDENT_INTERVAL must be an even multiple of SHORT_IDENT_INTERVAL. So if LONG_IDENT_INTERVAL is 60, the legal values for SHORT_IDENT_INTERVAL are: 1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, 60. That's the whole guest list. 💅
If it's unset or set to 0, short identifications are disabled. Periodt.
LONG_IDENT_INTERVAL
The number of minutes between long identifications 🌸. A long ident is the deluxe version — it transmits some more information about the station status (new voice mails etc), and the time of day gets transmitted too. A good value here is 60 minutes.
If unset or set to 0, long identifications are disabled. Bye. 👋
IDENT_ONLY_AFTER_TX
This one controls when identification happens, lowkey the boss of idents.
- By default: identification goes out every single time
SHORT_IDENT_INTERVALexpires. Like clockwork, whether anyone was talking or not. - If this feature is enabled: identification only happens if there's been a recent transmission.
This is chef's kiss for nodes using an RF link to provide echolink to a repeater 🫶. In that situation it's often not desirable for the link to identify unless it's legally necessary, iykyk.
⚠️ Heads up:SHORT_IDENT_INTERVALstill has to be set for this feature to work. It then gets interpreted as the minimum number of seconds between identifications. And nope,LONG_IDENT_INTERVALis not affected by this parameter at all.
EXEC_CMD_ON_SQL_CLOSE
Specify a time, in milliseconds, after squelch close after which entered DTMF digits will be executed as a command without needing to send the # character. Iconic behaviour, honestly. 🔥
To disable this feature, either comment out the configuration row or set it to a value less than or equal to zero. That's it.
EVENT_HANDLER
Point out the TCL event handler script to use 🧚. This script is the one responsible for playing the correct audio clips when an event occurs — it's basically the DJ of your events.
The default location is /usr/share/svxlink/events.tcl.
DEFAULT_LANG
Set the default language to use for announcements 🌈. It should be set to an ISO code — sv_SE for Swedish, for example.
If not set, it defaults to en_US, which is US English. 🇺🇸
RGR_SOUND_DELAY
The number of milliseconds to wait after the squelch has been closed before a roger beep is played 🎀.
The beep can be disabled by specifying a value of -1 or just commenting out this line.
Pro tip from the manpage itself: often it's best to use the SQL_HANGTIME receiver configuration variable to specify a delay instead of specifying a delay here. In that case, this configuration variable should then be set to 0. 💜
REPORT_CTCSS
If set, this will report the specified CTCSS frequency upon manual identification (that's the * press, bestie ✨). It's even possible to specify fractions using "." as the decimal comma.
Disable this feature by commenting out (#) this configuration variable. Easy.
TX_CTCSS
This configuration variable controls if a CTCSS tone should be transmitted 📡. Use a comma separated list (no spaces! I'm serious, no spaces) to specify when to transmit a CTCSS tone.
These are the possible values — SQL_OPEN, LOGIC, MODULE, ANNOUNCEMENT or ALWAYS:
SQL_OPEN— will transmit CTCSS tone when the squelch is open. This is only useful on a repeater. On a simplex node it doesn't make much sense.LOGIC— will transmit CTCSS tone when there is incoming traffic from another logic core.MODULE— will transmit CTCSS tone when there is incoming traffic from a module.ANNOUNCEMENT— will transmit CTCSS tone when an announcement is being played. Repeater idle sounds and roger beeps will not have tone sent with them though, so don't expect it.ALWAYS— will always transmit a CTCSS tone as soon as the transmitter is turned on. No thoughts, just tone. 💅
Commenting out this configuration variable will disable CTCSS transmit entirely. The tone frequency and level are configured in the transmitter configuration section.
MACRO_PREFIX
Zero or more DTMF digits a command must start with to be identified as a macro command ✨. If a prefix is set, macro commands get higher priority in the command hierarchy — main character energy, honestly.
For example: if a module is active, the macro will be handled as usual by the logic core. Whereas if no prefix is set, the command will go to the module. If the user wants the core to handle the macro, the command has to be prefixed with a star (that's the "force core command" move 🌟).
Default prefix is 'D'.
MACROS
Point out a section that contains the macros that should be used by this logic core 🎀. See the section description for macros below for more information — it's all down there, bestie.
FX_GAIN_NORMAL
The gain (dB) to use for audio effects and announcements when there is no other traffic 🌸. This gain is normally set to 0dB, which means no gain or attenuation. Just vibes, untouched.
FX_GAIN_LOW
The gain (dB) to use for audio effects and announcements when there is other traffic 👀. This gain is normally set to something like -12dB so that announcements and audio effects are attenuated when there's other traffic present. Considerate queen behaviour.
QSO_RECORDER
The QSO recorder is used to write all received audio to files on disk 💾.
The format for this configuration variable is:
<command>:<config section>The specified command is used to activate or deactivate the QSO recorder. If the command for example is set to 8, then 81 will activate the recorder and 80 will deactivate it.
The command may also be left out — in that case it will not be possible to control the QSO recorder using DTMF commands. But even if the command is left out, the colon must always be specified. Don't forget the colon. The colon is non-negotiable. 😤
The config section points out a section in the configuration file that holds configuration for the QSO recorder. Have a look at the QSO Recorder Section documentation for more information.
Example: QSO_RECORDER=8:QsoRecorder
SEL5_MACRO_RANGE
Define two comma separated values here to map the Sel5 tone call to your macro area ✨.
E.g. if you have defined:
SEL5_MACRO_RANGE=03400,03499then all incoming Sel5 tone sequences from 03400 to 03499 are mapped to the macros section (refer to Macros Section, next chapter).
Other sequences but the one defined under OPEN_ON_SEL5 are ignored, so it can be used to call other stations via the repeater without a repeater reaction. Sneaky and useful. 🦋
ONLINE_CMD
Define a DTMF command that is used to switch the node between online and offline mode 🔌.
When in the off-state, the transmitter will not be turned on by any event. Not one. If a module is active when the node is brought offline, it will be deactivated and no module activation will be allowed in offline mode. And no other commands than the online command will be accepted in the offline state — it's a whole lockdown.
If the command for example is set to 998877 then 9988771 will set the node online and 9988770 will set it offline.
⚠️ If a module is active, or if the ACTIVATE_MODULE_ON_LONG_CMD is used, the command must be prefixed with a star to work as expected. The star means "force core command". 🌟
ONLINE
Set to 0 to make SvxLink start offline 🛑. Settable at runtime, so you can flip it whenever.
Default is 1 (online). ☀️
STATE_PTY
Using this configuration variable it's possible to specify a path to a UNIX 98 PTY that SvxLink state events are published to 📢.
The published events are in a simple text format using a space separated list of values. SvxLink will create a softlink to the actual slave PTY — and for that reason, SvxLink must have write permissions in the directory where the softlink should be created. No perms, no link, periodt.
Monitoring the PTY output is as simple as doing a cat /path/to/pty after starting SvxLink 👑. See STATE PTY FORMAT for more information on the format of the state messages.
Example: STATE_PTY=/tmp/state_pty
DTMF_CTRL_PTY
Using this configuration variable it's possible to specify a path to a UNIX 98 PTY that allows a dtmf control of each single SvxLink logic 🎛️.
SvxLink will create a softlink to the actual slave PTY. For that reason, SvxLink must have write permissions in the directory where the softlink should be created.
Sending commands to the PTY is as simple as doing:
echo '*1#' > /path/to/pty...after starting SvxLink. The device works bidirectional, so received dtmf characters (from Rf) are output via this interface too. It's giving full duplex slay. 💅
Example: DTMF_CTRL_PTY=/dev/shm/dtmf_ctrl
CTCSS_TO_TG
Use this configuration variable to specify a comma separated list of pairs of tone frequencies and talk groups 💜. When one of the tone frequencies is detected, the corresponding talk group will be associated with the received audio.
This can be used for example by ReflectorLogic to automatically switch to a talk group when one of the specified tone frequencies is received.
⚠️ You also must configureCTCSS_FQfor all receivers to open the squelch on the same tone frequencies. Otherwise it will not work. Also, the CTCSS squelch detector must actually be used in the receiver — it's not enough to just setCTCSS_FQ. Setting the variable and hoping is not a strategy, bestie. 😭
Example: CTCSS_TO_TG=127.3:9993,136.5:9995
CTCSS_TO_TG_DELAY
The delay for reporting detected talkgroup from when a CTCSS tone is detected ⏱️. If the squelch closes before the delay time has expired, no talkgroup will be reported. Ghosted.
Default: 0.
Example: CTCSS_TO_TG_DELAY=1000
COMMAND_PTY
Using this configuration variable it's possible to specify a path to a UNIX 98 PTY that can be used to send commands to a SvxLink logic core 🎀.
SvxLink will create a softlink to the actual slave PTY. For that reason, SvxLink must have write permissions in the directory where the softlink should be created.
Sending commands to the PTY is as simple as doing:
echo 'THE COMMAND TO EXECUTE' > /path/to/pty...after starting SvxLink.
Valid commands:
CFG <section> <tag> <value>— sets a configuration variable. Bestie, listen: only a few configuration variables actually support being set at runtime, so don't go wild. Example:CFG RepeaterLogic ONLINE 0.EVENT <event name> [<arg> ...]— calls an event handler (a TCL function). Okay so this one matters: you have to specify the correct TCL namespace or the function will not be found, periodt. If no namespace is given, the namespace of the current logic core gets added automatically — somanual_identificationis literally the same asRepeaterLogic::manual_identificationwhen the logic core namespace isRepeaterLogic. Wanna reach a function in the root namespace? Then the function name must be prepended with::. Example:EVENT ::playNumber -42.5.
Example: COMMAND_PTY=/dev/shm/repeater_logic_ctrl
🌸 Simplex Logic Section 🌸
This section holds the configuration data for a simplex logic core. The name of the section — which in the example configuration file is SimplexLogic — must have a corresponding list item in the GLOBAL/LOGICS config variable for this logic core to be activated. And no, the name SimplexLogic is not magic, bestie 💅. You could call it literally whatever you like, but it has to match the namespace name in the SimplexLogic.tcl script. The configuration variables below are the ones that are specific to a simplex logic core.
TYPE— the type for a simplex logic core is alwaysSimplex.MUTE_RX_ON_TX— set it to1to mute the receiver when the transmitter is transmitting (that's the default 🫶), or set it to0to make the RX active during transmissions. You might want that0if the link is operating on a split frequency — then the link can accept commands even when it's transmitting. The normal setting is1, to mute the RX when transmitting.MUTE_TX_ON_RX— set it to1to mute the transmitter when the squelch is open (default ✨), or set it to0to make the TX active during squelch open. Again,0is the vibe if the link is operating on a split frequency or if it's connected to some full duplex device. The normal setting is1, to mute the TX when the squelch is open.RGR_SOUND_ALWAYS— set to1to always send the roger sound after squelch close, even when no module is active.
👑 Repeater Logic Section 👑
A Repeater Logic section contains the configuration data for a repeater logic core. The name of the section — RepeaterLogic in the example configuration file — must have a corresponding list item in the GLOBAL/LOGICS config variable for this logic core to be activated. And same deal as before: the name RepeaterLogic is not magic 🌈. Call it whatever you like, but it has to match the namespace name in the RepeaterLogic.tcl script. The variables below are the ones specific to a repeater logic core.
TYPE— the type for a repeater logic core is alwaysRepeater.NO_REPEAT— set this to1if you do NOT want SvxLink to play back the incoming audio. This is the move when the received audio is directly coupled by hardware wiring to the transmitter. What you win: zero delay on the repeated audio (and when audio is routed through SvxLink there is always an amount of delay, fr fr). What you lose: all the audio processing SvxLink does (e.g. filtering, DTMF muting, squelch tail elimination) and the ability to use remote receivers. Trade-offs, bestie 😭.IDLE_TIMEOUT— the number of seconds the repeater should have been idle before turning the transmitter off.OPEN_ON_1750— use this if it should be possible to open the repeater with a 1750Hz tone burst. Specify the number of milliseconds the tone must be asserted before the repeater is opened. Make sure the time you specify is long enough for the squelch to have time to open — otherwise the repeater will open "too soon" and the first thing you'll hear is an ugly 1750Hz beep 🙈. A value of0disables 1750 Hz repeater opening.OPEN_ON_CTCSS— use this if it should be possible to open the repeater using a CTCSS tone (PL). The repeater will activate after the specified number of milliseconds on detection of any of the CTCSS frequencies specified in the receiver configuration. Note 💀: the CTCSS squelch must actually be used as a squelch detector in the receiver. It's not enough to just setCTCSS_FQ.OPEN_ON_DTMF— use this if it should be possible to open the repeater with a DTMF digit. Only one digit can be specified. DTMF digits pressed when the repeater is down will be ignored.OPEN_ON_SEL5— use this if you want to open your repeater by using a selective tone call, the kind often used in commercial radio networks. Example:OPEN_ON_SEL5=03345opens your repeater only if that sequence has been received. You can use sequence lengths from4to25.CLOSE_ON_SEL5— use this if you want to close your repeater by using a selective tone call, again the kind often used in commercial radio networks. Example:CLOSE_ON_SEL5=03345closes your repeater if that sequence has been received. Sequence lengths from4to25work here too.OPEN_ON_SQL— use this if it should be possible to open the repeater just by keeping the squelch open for a while. The value to set is the minimum number of milliseconds the squelch must be open for the repeater to open.OPEN_ON_SQL_AFTER_RPT_CLOSE— activate the repeater on just a squelch opening if there have been no more than the specified number of seconds since the repeater closed.OPEN_SQL_FLANK— determines ifOPEN_ON_SQLandOPEN_ON_CTCSSshould activate the repeater when the squelch opens or closes. If set toOPEN, the repeater will activate and start retransmitting audio immediately — no identification will be sent. If set toCLOSE, the repeater will not activate until the squelch closes, and an identification will be sent in this case.IDLE_SOUND_INTERVAL— when the repeater is idle, a sound is played. Specify the interval in milliseconds between playing the idle sound. An interval of0disables the idle sound.SQL_FLAP_SUP_MIN_TIME— flapping squelch suppression is used to close the repeater down if there is interference on the frequency that opens the squelch by short bursts. This configuration variable specifies the minimum time, in milliseconds, that a transmission must last to be classified as a real transmission. A good value is in between500-2000ms.SQL_FLAP_SUP_MAX_COUNT— flapping squelch suppression is used to close the repeater down if there is interference on the frequency that opens the squelch by short bursts. This configuration variable specifies the maximum number of consecutive short squelch openings allowed before shutting the repeater down. A good value is in between5-10.SQL_TIMEOUT— this is a soft timeout value, in seconds, that can be used to indicate to repeater users that they have exceeded the recommended maximum time for a transmission. When the time is up, a sound will be emitted once every second ⏰. When the squelch closes — or alternatively when the roger sound is sent — a message informing about the timeout will be played back.ACTIVATE_MODULE_ON_LONG_CMD— this activates a feature that might help users who aren't aware of the SvxLink command structure. The idea: activate the specified module when a long enough command has been received. Typical example? An EchoLink user who is used to just typing in the node ID and expecting the connection to be established right away. Using this configuration variable, specify a minimum length and a module name. If no module is active and at least the specified number of digits has been entered, the given module is activated and the command is sent to it. To be really useful, this feature should be used in cooperation withEXEC_CMD_ON_SQL_CLOSE.
For example, if this configuration variable is set to "4:EchoLink" and the user types in 9999, the EchoLink module is first activated and then the command 9999 is sent to it, which will connect to the ECHOTEST server. Ate 🔥.
IDENT_NAG_TIMEOUT— tells repeater users who aren't identifying to identify themselves. The number of seconds to wait for an identification, after the repeater has been activated, is set using this configuration variable. A valid identification is considered to be a transmission longer than the time set by theIDENT_NAG_MIN_TIMEconfiguration variable. We don't know if it's really an identification but it's the best we can do 😭. Setting it to0or commenting it out disables the feature.IDENT_NAG_MIN_TIME— this is the minimum time, in milliseconds, that a transmission must last to be considered as an identification. It's used as described in theIDENT_NAG_TIMEOUTconfiguration variable.DTMF_IGNORE_WHEN_NOT_UP— if set to1(that's the default), all received DTMF will be ignored when the repeater is down (in inactive state). Those using a very shortIDLE_TIMEOUTmay need to set this config variable to0to get the desired behavior.
🦋 ReflectorLogic 🦋
The ReflectorLogic is used to connect to an SvxReflector server. The SvxReflector will distribute all audio to all connected nodes. To actually send audio to the reflector from a logic core, set up a link between the two logics using LogicLinking. And good news — more than one logic core can be connected 💜.
So SvxReflector also does traffic separation using talk groups, meaning multiple QSOs can be going on through the same reflector server at the same time without stepping on each other 💅. The set of talk groups that a node monitors for activity is configurable, so a talk group can be automatically selected when it's active. After a configurable timeout, the node will go back to monitoring all the configured talk groups if nothing is happening on the currently selected one. Which talk group gets selected for outgoing traffic for a node can be set to a default, selected by the CTCSS tone used, and/or selected using DTMF commands. Those DTMF commands are entered through the logic linking definition associated with the reflector. So if a command prefix of 9 has been specified for a link, selecting talk group 888 is achieved by entering the command 91888# ✨.
The reflector connection gets authenticated using X.509 certificates. Both the server and the client require authentication. The AUTH_KEY authentication method that was previously used is deprecated 💀. The certificate generation process is mostly automated. The contents of the certificate can be customized using the configuration variables with the name prefix CERT_. Default values are good in most cases. CERT_EMAIL may be good to specify so that the SvxLink node owner can be contacted 🫶. Ask the reflector sysop what the convention is.
TYPE— the type for a reflector logic core is alwaysReflector.DNS_DOMAIN— the domain of the SvxReflector server to connect to. For this to work, the DNS domain has to be configured with SRV records for all reflector servers serving that domain. Say the domain isexample.org— then there must be one or more SRV entries in the DNS with the name_svxreflector._tcp.example.org. Each SRV record contains info about hostname, port, priority and weight. The priority determines in which order SvxLink will try to connect to the servers. The weight is used to give different servers with the same priority a probability for how often they'll be selected 🎲.HOSTS— a comma separated list ofhostname:portpairs of the reflector servers. IP addresses work too. If port is not specified, the value ofHOST_PORTis used as a default. IfDNS_DOMAINis also specified, the values in theHOSTSlist will be added to the list looked up in the DNS. The order of the entries depends onHOST_PRIO,HOST_PRIO_INCandHOST_WEIGHT.HOST_PRIO— the priority value to use for entries in theHOSTSlist. The priority determines in which order SvxLink will try to connect to the specified servers. See alsoHOST_PRIO_INC. Default:100.HOST_PRIO_INC— the value with which to increase the priority value for each entry in theHOSTSlist. The first value will be the one specified byHOST_PRIO. Default:1.HOST_WEIGHT— the weight value determines how often a server will be selected in comparison to servers with the same priority. This variable is only useful when you want to set the weight in relation to other SRV records looked up in the DNS. The weight values for entries in theHOSTSlist will always be the same.HOST_PORT— the default TCP/UDP port number used by the reflector server. The client does not need to open any ports in the firewall 🧱. Default:5300.CALLSIGN— the callsign of this node. The callsign also serves as the username when authenticating to the SvxReflector server 👑.AUTH_KEY— the authentication key, or password, used when authenticating to the SvxReflector server. When connecting to a modern reflector server, certificates are used instead of anAUTH_KEY. In that case this configuration variable should be left unset.JITTER_BUFFER_DELAY— a jitter buffer is used to prevent gaps in the audio when the network connection doesn't provide a steady flow of data. Set this configuration variable to the number of milliseconds to buffer before starting to process the audio. Default:0.DEFAULT_TG— the node will select this talk group on local incoming traffic if no other talk group is currently selected. Default:0(no talk group).MONITOR_TGS— a comma separated list of talk groups which the node will monitor for activity when no other talk group is selected.
It's also possible to mark talk groups as more prioritized than others by adding one or more plus signs after the talk group number. More plus signs means higher priority. While a talk group is selected, and there is activity on a talk group with higher priority, the higher prio talk group will be selected unless there has been local activity on the node.
Example:
MONITOR_TGS=112++,240,2403+,2403123will monitor the TGs for Sweden, Sweden district 3 and a specific TG #2403123. Traffic on talk group 2403 will be prioritized and 112 will have the highest priority 🔥.
TG_SELECT_TIMEOUT— the number of seconds after which a selected talk group will be unselected. The node will return to talk group0(no talk group) and start monitoring the configured talk groups again. The value must be larger than zero. Default:30seconds.TG_SELECT_INHIBIT_TIMEOUT— talkgroup selection is inhibited when there is activity on the local frequency that does not activate a talkgroup. Only activation due to remote activity (monitoring) is inhibited. A talkgroup can be activated as usual by using any method for local activation. This feature makes it possible to conduct a local QSO without being disturbed by remote reflector traffic 🙈.
Use this configuration variable to set the number of seconds of inactivity before the node will go back to monitoring remote talkgroup activity. The default value is taken from TG_SELECT_TIMEOUT if this variable is not set. Setting a value of 0 will disable the feature entirely.
ANNOUNCE_REMOTE_MIN_INTERVAL— the minimum number of seconds between announcements of the same TG for remote TG activations. If the same TG is remotely activated repeatedly, it will not be announced until at least the number of seconds specified in this configuration variable have passed.NODE_INFO_FILE— the configuration file to use for sending information regarding this client to the reflector server. This is not a required configuration. It's mostly free-form JSON but the general structure should be kept so that SvxLink and the reflector server can fill in dynamic information about the node like signal strengths for receivers 📡. Use the defaultnode_info.jsonas a template. You can add more information rather freely but don't change the overall structure.MUTE_FIRST_TX_LOC— mute the first transmission after selecting a talk group due to local activity. This feature is good to have enabled for a number of reasons. One reason is to suppress short openings of a talk group when someone just makes a single transmission to test the local node. Another reason is to allow someone to submit DTMF commands to the node without disturbing the reflector network. An example is that someone activates a talk group using CTCSS but then immediately selects another talk group using DTMF — in that case no transmission will be made on the first talk group. This feature is enabled by default ✅.MUTE_FIRST_TX_REM— mute the first transmission after selecting a talk group due to remote activity. This feature can be enabled to let local node users enter DTMF commands without disturbing an active talk group. As an example, the local node monitors a talk group that is active. However, no one on the local node participates in the QSO and a local user wants to select another talk group. With this feature enabled it's possible to do that without transmitting into the reflector network while entering DTMF commands.
This feature is not enabled by default since it's a bit unintuitive 😭. If a local user hears a call and wants to answer that call, he must first make a short transmission to "open up" the local node. This is easy to forget.
TMP_MONITOR_TIMEOUT— this configuration variable determines after how many seconds a manually added temporary talk group monitor will time out. Set to0to disable this feature. Default is3600, one hour ⏰.UDP_HEARTBEAT_INTERVAL— the number of seconds between UDP heartbeat messages sent to the reflector server. This configuration variable can normally be left at the default value, but if you get frequent disconnects due to UDP heartbeat timeout it may help to lower this value. Default:15.QSY_PENDING_TIMEOUT— set to the number of seconds to enable following a QSY request on squelch activity. That is, after a remote QSY request, during the configured number of seconds, it will be possible to follow a QSY request by just pushing the PTT instead of having to use DTMF commands. Note that the timer starts when the QSY request is received, so the time it takes to play the QSY announcement is also included in the timeout time. A good value is within 10 to 15 seconds. Default is-1(disabled).VERBOSE— set to0to suppress reflector leave/join printouts 🤫.CERT_PKI_DIR— the path to the directory where PKI (Public Key Infrastructure) files will be stored.
Example: CERT_PKI_DIR=/var/lib/svxlink/pki
CERT_KEYFILE— the path to the private key for the X.509 client certificate. This file will be auto generated if it does not exist. It must be kept secure since this is what authenticates your node 🔐. It must NOT be sent in the clear over the internet for example. Also, if you lose this file you will have to ask the reflector sysop to issue a new certificate for the new key.
Example: CERT_KEYFILE=/var/lib/svxlink/pki/MYCALL.key
CERT_CSRFILE— bestie this is the path to the certificate signing request for the X.509 client certificate 📜. It's gonna auto-generate itself if it's not there yet, or whenever the config info has changed. Heads up: once a new CSR pops out, your reflector sysop has to sign it before it does literally anything. No signature, no activation, periodt.
Example: CERT_CSRFILE=/var/lib/svxlink/pki/MYCALL.csr
CERT_CRTFILE— path to the X.509 client certificate 🔐. This one is a public file and it's literally your node's whole identity — it gets sent to the reflector during the authentication procedure. It only shows up after the reflector sysop has signed your CSR. And plot twist: the reflector itself will send this file to the client during authentication if it's missing on your node, or if the cert has been updated. Mutual glow-up fr fr.
Example: CERT_CRTFILE=/var/lib/svxlink/pki/MYCALL.crt
CERT_CAFILE— path to the X.509 certificate bundle 🎀. It holds one or more certificates, and its whole job is verifying that the reflector server is actually who it says it is — authenticity check queen.
Example: CERT_CAFILE=/var/lib/svxlink/pki/ca-bundle.pem
CERT_DOWNLOAD_CA_BUNDLE— by default the CA bundle gets downloaded from the reflector server if it's missing or needs updating. Set this variable to0to turn that behaviour off 💅. You'd do that specifically when you want to provide your own CA bundle, like a DIY icon.CERT_SUBJ_GN,CERT_SUBJ_givenName— the name of the person who owns the SvxLink node, the one s/he is normally called by 💖.
Example: CERT_SUBJ_GN=John
CERT_SUBJ_SN,CERT_SUBJ_surname— the family name of the person owning the SvxLink node 🌸.
Example: CERT_SUBJ_SN=Doe
CERT_SUBJ_OU,CERT_SUBJ_organizationalUnitName— the name of the organizational unit the SvxLink node belongs to. Could be a subdivision of a ham radio organization for example 🦋.
Example: CERT_SUBJ_OU="VHF/UHF Unit"
CERT_SUBJ_O,CERT_SUBJ_organizationName— the name of the organization the SvxLink node belongs to. A ham radio club, for example ✨.
Example: CERT_SUBJ_O=SSA
CERT_SUBJ_L,CERT_SUBJ_localityName— the name of the city where the SvxLink node is located 📍.
Example: CERT_SUBJ_L=Stockholm
CERT_SUBJ_ST,CERT_SUBJ_stateOrProvinceName— the name of the state or province where the SvxLink node is located 🗺️.
Example: CERT_SUBJ_ST=Södermanland
CERT_SUBJ_C,CERT_SUBJ_countryName— the ISO 3166 country code for the country where the SvxLink node is located 🌍.
Example: CERT_SUBJ_C=SE
CERT_EMAIL— a comma separated list of email addresses where the SvxLink node owners can be reached 📧.
Example: CERT_EMAIL=mycall1@example.com,mycall2@example.com
Okay so you can also set audio codec parameters using the same configuration variables that are documented for networked receivers and transmitters 👀. For example, to lighten the encoder CPU load for the Opus encoder, set OPUS_ENC_COMPLEXITY to something lower than 9. Your CPU will thank you, lowkey.
🎙️ QSO Recorder Section 💾
The QSO recorder is the friend that records all received audio to files on disk. All audio from receivers, modules and logic links gets recorded. Announcements? Not recorded. They're the exception, and honestly, iconic behaviour.
REC_DIR— use this to specify which directory the audio files get written to 🗂️. A good place is/var/spool/svxlink/qso_recorder.MIN_TIME— if the duration of the recorded content for a file is less thanMIN_TIMEmilliseconds, the file gets deleted when it's closed 🗑️. Default:0(empty files will be deleted).MAX_TIME— setting this puts an upper limit on the file size of a recording. No more thanMAX_TIMEseconds of content will be recorded to a single file 📏. Once the max time is reached, the file closes and another one gets created. And no, it is not the maximum time the recording has been active that we're limiting — it's how much content has been recorded to the file, bestie, read carefully. If nothing is recorded, the file can stay open indefinitely, just vibing. Default:0(no limit).SOFT_TIME— so you don't get abrupt breaks in your recordings, you can set a soft break time 🫶. Let's sayMAX_TIMEis set to3600seconds (one hour). If we setSOFT_TIMEto300seconds (five minutes), the QSO recorder will try to close the file on a squelch close somewhere between 55 and 60 minutes. The whole point is avoiding transmissions getting split up between files. Default:0(no limit).MAX_DIRSIZE— specify the maximum total size in megabytes of the files in the recording directory 📦. If the limit gets exceeded, the oldest files are deleted. The directory size is checked upon file close, so the size may grow temporarily past the limit by at most the size of one recorded file. Only files whose filename starts with"qsorec_"are even considered for deletion. If you're using anENCODING_CMD, make sure the"qsorec_"prefix isn't removed from the target filename — unless you really want theMAX_DIRSIZEfeature to skip them. Default:0(no limit).DEFAULT_ACTIVE— set this to1and the QSO recorder will be activated by default when SvxLink starts ⭐. Default:0(default inactive).TIMEOUT— if a timeout is specified, the activation state of the QSO recorder returns to whatever you set inDEFAULT_ACTIVEonce the node has been idle for that many seconds ⏳. WhenDEFAULT_ACTIVEis unset or0: if the QSO recorder is manually activated, it'll automatically deactivate after the specified amount of inactivity. WhenDEFAULT_ACTIVEis set to1: if the QSO recorder is manually deactivated, it'll automatically activate after that amount of inactivity. Flip-flop queen. Default:0(no timeout).QSO_TIMEOUT— set this if you want to close the currently opened file and open a new one after each QSO 📁. Specify the number of seconds the node should be idle before closing the file. Default:0(no QSO timeout).ENCODER_CMD— specify a command to run after a new wav file has been written to disk 🎛️. This makes it possible to use an external encoder utility to encode the wav file into another format. And even though this variable was added to run an external encoder, it could do more complicated things with the file if needed — like transferring the file to another computer or sending a notification e-mail. If the command line gets too complicated, it may be a good idea to write a script instead, no cap.
The encoder command runs under a shell, so normal shell operators like redirects and pipes are fair game 💅. The shell specified in the SHELL environment variable gets used, and if that's not set, /bin/sh is used. The -c command line option gets added, so the complete command looks something like: $SHELL -c "$ENCODER_CMD". A number of %-codes can be included in the command, and here's what they mean:
%f— the full filename with full path%d— the directory part (whatREC_DIRis set to)%b— the basename, that is, the filename without path and extension%n— the filename without path but with extension
The encoder gets started in the background and it will not be stopped even if SvxLink exits 🚨. It just runs in the background until it's done. As long as SvxLink is running, it monitors the encoding processes — and if a process runs for longer than one hour, it will be killed. Rest in peace, runaway encoder 💀.
Note that SvxLink will never remove the original recording, so that has to be done in the encoder command. Here are a couple of examples:
ENCODER_CMD=/usr/bin/oggenc -Q \"%f\" && rm \"%f\"
ENCODER_CMD=/usr/bin/lame --quiet \"%f\" \"%d/%b.mp3\" && rm \"%f\"
ENCODER_CMD=/usr/bin/speexenc \"%f\" \"%d/%b.spx\" 2>/dev/null && rm \"%f\"
ENCODER_CMD=/usr/bin/opusenc \"%f\" \"%d/%b.opus\" 2>/dev/null && rm \"%f\"✨ Macros Section 🎀
A macros section declares macros that can be used by a logic core 🪄. The logic core points out which macros section to use via the MACROS configuration variable. You can name the MACROS section literally whatever you want, as long as it matches the MACROS configuration variable in the logic core configuration section. So yes, you could absolutely have both a [RepeaterLogicMacros] and a [SimplexLogicMacros] section. Options, bestie. We love options 🌈.
A macro is a kind of shortcut that decreases the number of key presses you gotta do to connect to common EchoLink stations, for example ⚡. On the radio side, macros are activated by pressing "D" "macro number" "#". A macros section can look something like this example below. And note: the module name is case sensitive 👑
[Macros]
1=EchoLink:9999#
2=EchoLink:1234567#
9=Parrot:0123456789#So for example, pressing the DTMF sequence "D1#" activates the EchoLink module and connects to the EchoTest conference node 🎉. One keypress combo, whole conference joined, slay.
🔗 Logic Linking 🔗
A logic linking configuration section specifies information for a link between two or more SvxLink logic cores 💜. Such a link can be used, for example, to connect a local repeater to a remote repeater using a separate link transceiver. The link gets activated/deactivated using DTMF commands and/or automatically, depending on your configuration. And when the link is active, all audio received by one logic gets transmitted by the other logic(s) 📻. Sharing is caring.
The name of the logic linking section can be chosen freely 🦋. In the example configuration file, there are a couple of sections: [ReflectorLink] and [LinkToR4]. To actually use a logic linking section in a logic core, it must be pointed out by the LINKS configuration variable in the GLOBAL section. Multiple links are separated with a comma. Example: GLOBAL/LINKS=ReflectorLink,LinkToR4.
✨ CONNECT_LOGICS ✨
okay bestie this one is the whole point of a link, so pay attention 💅 It's a comma separated list of logic specifications for the logic cores you wanna connect together.
Each logic specification has three parts separated by colons:
<logic name>:<command>:<announcement name>- logic name — the name of the logic to include in the link.
- command — used to manually activate or deactivate the link from the just specified logic.
- announcement name — used when announcing link related activities like activation or deactivation.
Both command and announcement name may be left empty if no manual control is desired. No pressure. 🫶
An example config line may look like this:
RepeaterLogic_2m:99:SK3GW,RepeaterLogic_70cm:94:SK3GKSo what's happening here? It will include two logics in the link, RepeaterLogic_2m and RepeaterLogic_70cm. From the 2m side, the link will be activated when the user sends command 991 and deactivated when the user sends command 990. Upon activation, an announcement like "activating link to SK3GW" will be played back. From the 70cm side the command will be 941 and 940 respectively. The announcement when activating the link from the 70cm side will be something like "activating link to SK3GK". Iconic, honestly. 🌈
✨ DEFAULT_ACTIVE ✨
The link will be connected automatically during startup of SvxLink if this configuration variable is set to 1. 🦋
Also, if a link is manually disconnected by a user it will be automatically reconnected after some time of inactivity. That time is specified by setting the TIMEOUT configuration variable. If the TIMEOUT variable is not set, no automatic reactivation will be done. Periodt.
✨ TIMEOUT ✨
The number of seconds after which the link will be automatically deactivated if there have been no activity. 💤
If 1 have been specified for DEFAULT_ACTIVE, this configuration variable will specify after how many seconds the link will be reactivated after being manually deactivated.
✨ ACTIVATE_ON_ACTIVITY ✨
Enter a comma separated list of logics, which should automatically activate the link if there is activity (e.g. squelch open, announcements etc) in it. 👑
One possible application for this is for example to make the connection of a microphone/speaker combination (without DTMF encoder) for brief announcements but without having to constantly listen in.
Example:
ACTIVATE_ON_ACTIVITY=MicSpkrLogic✨ ACTIVATE_ON_TG ✨
Enter a comma separated list of entries on the form logic:tg_regex, which should automatically activate the link if the specified talkgroup regular expression matches a talkgroup that is activated on the specified logic core. 🔥
Use CTCSS_TO_TG in a SimplexLogic or RepeaterLogic to make it emit a talkgroup for a specific subtone.
Example:
ACTIVATE_ON_TG=SimplexLogic:240.*,RepeaterLogic:2403|2404|123🎀 Local Receiver Section 🎀
A local receiver section is used to specify the configuration for a receiver connected to the sound card. 💖 In the default configuration file there is a Local configuration section called Rx1. The section name could be anything. It should match the RX configuration variable in the logic core where the receiver is to be used. The available configuration variables are described below. Let's go, no skipping, every single one. ⭐
🎧 TYPE
Always "Local" for a local receiver.
🎧 RX_ID
A single character uniquely identifying this receiver. The RX identity can for example be used in the TCL event scripts to get different roger sounds for different receivers when using a receiver voter. Cute, right? 🙈
🎧 AUDIO_DEV
Specify the audio device to use. Normally alsa:plughw:0. Have a look at the AUDIO DEVICE SPECIFICATIONS chapter for more information. 📖
🎧 AUDIO_CHANNEL
Specify the audio channel to use. SvxLink can use the left/right stereo channels as two mono channels. Legal values are 0 or 1.
🎧 AUDIO_DEV_KEEP_OPEN
The normal behaviour for SvxLink is to open an audio device when needed and close it when it does not have to be open anymore. This may cause problems in some applications or with some sound hardware. Set this variable to 1 to force SvxLink to keep the audio device open from application start to exit.
🎧 LIMITER_THRESH
Set the threshold, in dBFS, for the audio limiter. The audio limiter really is a compressor with a very steep compression ratio like 10:1. The limiter is used to help keeping down the audio level for overmodulating stations. 🎚️
For a properly calibrated SvxLink node max FM deviation is -6dBFS. A good value to start with for this parameter is then -6 but try to lower it further (like -9 to -12) if it does not affect audio quality negatively.
🎧 SQL_DET
Specify the type of squelch detector to use. Possible values are: VOX, CTCSS, SERIAL, EVDEV, SIGLEV, PTY, GPIO, GPIOD, HIDRAW or COMBINE. 😤
- The
VOXsquelch detector determines if there is a signal present by calculating a mean value of the sound samples. TheVOXsquelch detector behavior is adjusted withVOX_FILTER_DEPTHandVOX_THRESH.VOXis actually a bit of a misnomer since it's a "Voice Operated Squelch" andVOXactually means "Voice Operated Transmitter". However, the termVOXis widely understood by hams all over the world so we'll stick with it. 💀 - The
CTCSSsquelch detector checks for the presence of a tone with the specified frequency. The tone frequency is specified using theCTCSS_FQconfig variable. The thresholds are specified using theCTCSS_OPEN_THRESHandCTCSS_CLOSE_THRESHconfig variables. Other config variables that effect theCTCSSsquelch is:CTCSS_MODE,CTCSS_SNR_OFFSETS,CTCSS_BPF_LOW,CTCSS_BPF_HIGH,CTCSS_EMIT_TONE_DETECTED. - The
SERIALsquelch detector use a pin in a serial port to detect if the squelch is open. This squelch detector can be used if the receiver have an external hardware indicator of when the squelch is open. Specify which serial port/pin to use withSERIAL_PORTandSERIAL_PIN. - The
EVDEVsquelch detector read squelch events from a/dev/input/eventXdevice. An example where this could be useful is if you have a USB audio device with some buttons on it. Some of these devices generate key press events, much like a keyboard. Specify which/dev/inputdevice node to use using theEVDEV_DEVNAMEconfig variable. Set which events that should open and close the squelch using theEVDEV_OPENandEVDEV_CLOSEconfig variables. - The
GPIOsquelch detector read a pin on the GPIO Port. Depending on the level of the pin, the squelch is switched. AHIGH(3.3V) at the pin set the squelch to open and aLOW(GND) level will set the squelch to closed. Specify which squelch pin to use with theGPIO_SQL_PINconfiguration variable. On some devices, like the Orange Pi, you also need to set theGPIO_PATHconfiguration variable. 🍓 - The
GPIODsquelch detector read a pin in the GPIO subsystem using thegpiodlibrary. Depending on the level of the pin, the squelch is switched. SetGPIODinteraction up using the following configuration variables:SQL_GPIOD_CHIP,SQL_GPIOD_LINE,SQL_GPIOD_BIAS. - The
SIGLEVsquelch detector use signal level measurements to determine if the squelch is open or not. Which signal level detector to use is determined by the setting of theSIGLEV_DETconfiguration variable. The open and close thresholds are set using theSQL_SIGLEV_OPEN_THRESHandSQL_SIGLEV_CLOSE_THRESHconfiguration variables.
If using the NOISE signal level detector note the following. The detector is not perfect (it's affected by speech) so you will also want to setup SQL_HANGTIME to prevent it from closing in the middle of a transmission. A value between 100-300ms is probably what you need. If using this squelch type in cooperation with a voter, you'll also probably need to setup SQL_DELAY to get correct signal level measurements. A value of about 40ms seem to be OK. Also, when using the NOISE signal level detector the input audio must be unsquelched since silence will be interpreted as a high signal strength. 😭
- The
PTYsquelch expects a very simple protocol over a pseudo-tty device, created by SvxLink at runtime. An'O'over this pty device indicate an open squelch, a'Z'is a closed squelch. Define the slave pty usingPTY_PATH(e.g.PTY_PATH=/tmp/sql) and SvxLink will create a link to the specified path from it's pseudotty slave device (/dev/pts/X). This can be used by a script to interface custom devices, modems or other hardware to SvxLink. Look fornhrcx.plortrx_pty_ctrl.pyfor an example. It is possible to specify the samePTYfor multiple functions (e.g. DTMF, ptt etc) in both TX and RX configurations. This may be good if there is one script handling all functions. - The
HIDRAWsquelch supports human interface devices (HID), USB devices likeCM108soundcard e.g. used in the URI Echolink adapter made by DMK. - The
COMBINEsquelch make it possible to combine multiple squelch types using a logical expression. The expression is set up using theSQL_COMBINEconfiguration variable.
🎧 SQL_START_DELAY
The squelch start delay is of most use when using VOX squelch. For example, if the transceiver makes a noise when the transmitter is turned off, that might trigger the VOX and cause an infinite loop of squelch open/close transmitter on/off. 🫠
Specify the number of milliseconds that the squelch should be "deaf" after the transmitter has been turned off.
🎧 SQL_DELAY
Specify a delay in milliseconds that a squelch open indication will be delayed.
This odd feature can be of use when using a fast squelch detector in combination with the signal level detector. A squelch delay will allow the signal level detector to do its work before an indication of squelch open is sent to the logic core. A delay might be needed when using the voter to choose among multiple receivers. A normal value could be somewhere in between 20-100ms.
💖 SQL_HANGTIME 💖
okay so bestie, this one is literally the squelch's lil nap timer 🛌 — how long, in milliseconds, the squelch will stay open after the detector has already said "girl, it's closed." and like, she heard that, but she's refusing to get out of bed yet. This applies to every single squelch detector type, no exceptions. And yes, you can change it while everything's running — settable at runtime ✨.
🦋 SQL_EXTENDED_HANGTIME 🦋
so when the signal is weak (ugh, the worst), it's lowkey smart to give the squelch a longer hangtime so it's less likely to slam shut on you. This variable is unset by default. A value of 1000 milliseconds is a good lil starting point to try. To actually turn the extended hangtime feature on, you gotta set up the SQL_EXTENDED_HANGTIME_THRESH variable. Settable at runtime, periodt 💅.
🌸 SQL_EXTENDED_HANGTIME_THRESH 🌸
same vibe as above — weak signals, longer hangtime, less likely the squelch closes on you. This variable is unset by default. When you set it to a signal level, it activates the extended squelch hangtime feature. So when the signal strength during a transmission drops below the threshold you set, the extended hangtime kicks in. Start out somewhere between 10 to 15. And the SQL_EXTENDED_HANGTIME variable is what sets how long that extended hangtime actually is.
⚠️ bestie, make sure you've calibrated the signal level detector before you turn this on. Otherwise it will not work as expected, fr fr 😭.
Settable at runtime 🫶.
🔥 SQL_TIMEOUT 🔥
this is the vibe check for your squelch's main character energy 💀 — it sets an upper limit, in seconds, for how long the squelch is even allowed to stay open. If the timeout value gets exceeded, the squelch is forced to close. If the squelch closes for real, everything is back to normal. When it opens the next time, a squelch open will be signaled. So like, use this to make sure a faulty receiver can't block the whole system indefinitely, iykyk 👑.
⭐ VOX_FILTER_DEPTH ⭐
The number of milliseconds to create the mean value over. A small value will make the vox react quicker (<200) and larger values will make it a little bit more sluggish. A small value is often better — no cap 🧚.
💜 VOX_THRESH 💜
The threshold that the mean value of the samples must exceed for the squelch to be considered open. ngl it is hard to say what a good value is 😭. Something around 1000 is probably good. Set it as low as possible without getting the vox to false trigger, bestie.
🎀 CTCSS_MODE 🎀
This one picks which CTCSS detection method gets used. Here's the lineup, choose your fighter:
0(Default) — will choose the detection mode that is the default in the software. At the moment this is mode4, "Overlap+Estimated SNR+Frequency estimation".1(Neighbor bins) — this detection mode uses three narrow frequency bands (~8Hz) to do the detection. One band is centered around the tone to be detected, and then there's one band above and one below the tone. These bands are used to estimate the noise floor. This is the detector that's been used in SvxLink for a long time. It is however rather slow, with a detection time of about450ms. There's no good reason to use this detector anymore, but it's kept in case the new detector doesn't work for some hardware setup.2(Estimated SNR) — this is a newer detector implementation with some improvements. The most notable difference is that it's faster. The mean detection time will be around200ms. This is the default detection mode if not specified. This detector uses a larger passband to estimate the noise floor, which makes it more stable. The default config uses the whole CTCSS passband but this can be customized using theCTCSS_BPF_LOWandCTCSS_BPF_HIGHconfig variables.3(Estimated SNR+Phase) — this detector is a bit experimental. It's even faster and more narrow than the other detection modes. The mean detection time will be something like150ms. The detection bandwidth is very narrow and very sharp so that no adjacent tones will trigger the detector. The price to pay for these improvements is that it's a bit less sensitive.4(Overlap+Estimated SNR+Frequency estimation) — this is an improvement of the mode3detector which uses another method for extracting the phase information from the signal. This phase information can be used to calculate an estimation of the tone frequency. The accuracy is like tenths of a Herz. Like the mode3detector, this detector is faster and more selective. With its0.75%frequency tolerance, it will not trigger on adjacent CTCSS tones. However, the "undetect" algorithm does not use the frequency estimation, so the squelch may be held open by an adjacent tone if already in active state. One downside is that it's a bit more CPU hungry due to using75%overlap in the frequency analysis, thus processing each sample three times. The reason to use overlap is that the detector will be faster.
🌈 CTCSS_FQ 🌈
If CTCSS (PL, subtone) squelch is used (SQL_DET is set to CTCSS), this config variable sets the frequency of the tone to use. The tone frequency ranges from 67.0 to 254.1 Hz. There actually is nothing that will stop you from setting the frequency to something outside this range but there is no guarantee that it will work 🫠.
If desired it's possible to specify a comma separated list of tone frequencies, in which case the squelch will open on all the tone frequencies. Note that for this feature to work well, the receiver's frequency response in the CTCSS frequency range (67.0 to 254.1Hz) needs to be reasonably flat. When choosing tones, try to select tones that are close to each other. However, selecting tones too close may cause both to trigger. Also do not select tones that are a multiple of another tone since overtones may trigger the wrong one 👀.
💅 CTCSS_OPEN_THRESH 💅
If CTCSS (PL, subtone) squelch is used (SQL_DET is set to CTCSS), this config variable sets the required tone level to indicate squelch open. The value is some kind of estimated signal to noise dB value. If using CTCSS mode 2, 3 or 4 it's helpful to set up the CTCSS_SNR_OFFSETS config variable. This will make the SNR estimation pretty good. Default threshold is 15dB ✨.
🍓 CTCSS_CLOSE_THRESH 🍓
If CTCSS (PL, subtone) squelch is used (SQL_DET is set to CTCSS), this config variable sets the required tone level to indicate squelch close. The value is some kind of estimated signal to noise dB value. If using CTCSS mode 2, 3 or 4 it's helpful to set up the CTCSS_SNR_OFFSETS config variable. This will make the SNR estimation pretty good. Default threshold is 9dB 💖.
💀 CTCSS_SNR_OFFSET 💀
This configuration variable should not be used unless you know why you use it. Using CTCSS_SNR_OFFSETS is often more appropriate. like, bestie, this is the do not touch unless you're a wizard one 🧙.
👑 CTCSS_SNR_OFFSETS 👑
This config variable is used when CTCSS_MODE is set to 0, 2, 3 or 4. It will adjust the estimated SNR values so that they become very close to a real SNR value. This value will have to be adjusted if CTCSS_FQ, CTCSS_MODE, CTCSS_BPF_LOW or CTCSS_BPF_HIGH changes.
Use the siglevdetcal utility to find out what to set this config variable to. There is no requirement to set this config variable up. The downside is that you will then need to experiment more with the CTCSS_OPEN_THRESH and CTCSS_CLOSE_THRESH config variables to find the correct squelch level. If using multiple CTCSS frequencies it may not be possible to find good threshold values due to uneven frequency characteristics for the receiver 😭.
The format for this config variable is a comma separated list of frequency:offset pairs. The CTCSS_SNR_OFFSET variable may be used as a form of fallback value that is used if a specific tone frequency in use is missing from this list.
💜 CTCSS_BPF_LOW 💜
When CTCSS_MODE is set to 0, 2, 3 or 4, this config variable will set the low cutoff frequency for the passband filter. It normally should not have to be adjusted, but could improve the detector if some interference falls within the passband (e.g. mains hum). Note however that the more narrow you make the passband, the less stable the detector will be. You may need to compensate by increasing the open/close thresholds or by setting up SQL_DELAY and SQL_HANGTIME. Default is 60Hz ✨.
🌸 CTCSS_BPF_HIGH 🌸
When CTCSS_MODE is set to 0, 2, 3 or 4, this config variable will set the high cutoff frequency for the passband filter. It normally should not have to be adjusted, but could improve the detector if some interference falls within the passband. Note however that the more narrow you make the passband, the less stable the detector will be. You may need to compensate by increasing the open/close thresholds or by setting up SQL_DELAY and SQL_HANGTIME. Default is 270Hz 🫶.
🔥 CTCSS_EMIT_TONE_DETECTED 🔥
This configuration variable defaults to 1, which means that a tone detected signal is emitted when a CTCSS tone is detected. This is required for the function of other features in SvxLink like CTCSS_TO_TG and OPEN_ON_CTCSS. In some situations it may be necessary to disable this behavior, like when using advanced squelch configurations where some tones are actively blocked due to nearby interference.
🙈 CTCSS_DEBUG 🙈
Set this to 1 to enable continuously printing SNR values for the CTCSS tone measurements. This is only meant to be activated temporarily while searching for a problem or for initial adjustment, bestie — don't leave it on 👀.
🔌 SERIAL_PORT 🔌
If SQL_DET is set to SERIAL, this config variable determines which serial port should be used for hardware squelch input (COS - Carrier Operated Squelch).
⚠️ Note: If the same serial port is used for the PTT, make sure you specify exactly the same device name. Otherwise the RX and TX will not be able to share the port 💀.
Example:
SQL_PORT=/dev/ttyS0SERIAL_PIN
If SQL_DET is set to SERIAL, this config variable decides which pin in the serial port gets used for hardware squelch input — that's COS, aka Carrier Operated Squelch, bestie, the whole "is someone talking on the radio" signal 💅
Your options are the DCD, CTS, DSR or RI pin. Want inverted operation instead? Just prefix the pin name with an exclamation mark (!) and you're done ✨
Example: SQL_PIN=!CTS
SERIAL_SET_PINS
This one lets you force specific serial port pins into a static state. Super handy when you're using a pin for reference voltage, or when a pin simply has to sit in a certain state so it doesn't mess with some other piece of equipment. There are two pins you can play with: RTS and DTR. Prefix with an exclamation mark (!) and the pin gets cleared; leave it off and the pin gets set 🎀
Example: SERIAL_SET_PINS=RTS!DTR will set RTS and clear DTR.
EVDEV_DEVNAME
Tells SvxLink which /dev/input device node to use for the EVDEV squelch detector 👑
To figure out which device node and which event codes you need, install the evtest utility. Find a candidate device node under /dev/input/ or /dev/input/by-id/ and run evtest on it. Then press some keys on the device you want to read events from. If you're lucky, events will start printing on your screen like confetti 🎉
EVDEV_OPEN
Use the evtest utility (same as described above) to find the type, code and value for the event that should open the squelch. Say type is 1, code is 163 and value is 1 — then you set this config variable to 1,163,1. Easy 💖
EVDEV_CLOSE
Same deal, but for closing the squelch. Using evtest again, find the type, code and value. Example: if type is 1, code is 163 and value is 0, set this config variable to 1,163,0.
Oh and bestie, plot twist: if you set the exact same type,code,value combination for both EVDEV_OPEN and EVDEV_CLOSE, that event will toggle the squelch 🔁
GPIO_PATH
Set the path to the sys control devices for GPIO with this one. Normally that's /sys/class/gpio, but on some hardware — like the Orange Pi — the path is /sys/class/gpio_sw. Hardware is chaotic, we adapt 🦋
GPIO_SQL_PIN
If SQL_DET is set to GPIO, this config variable picks which GPIO pin is used for squelch input. The most common name format is gpio<number>, like gpio4. Some GPIO drivers get fancy with it and use names like gpio33_pe11. Want it inverted? Prefix the pin name with an exclamation mark (!) 💅
Example: GPIO_SQL_PIN=!gpio4
SQL_GPIOD_CHIP
The path to the GPIO chip device node to use for squelch.
Example: SQL_GPIOD_CHIP=/dev/gpiochip0
SQL_GPIOD_LINE
If GPIOD was specified in SQL_DET, set this config variable to the gpiod line of the GPIO pin you want to use. If you give a number, it's assumed to be the GPIO pin offset within the chip. If you give a pin name, SvxLink will go hunting for a pin with that name inside the chip 🔍
Normally the pin is active high, but prefix the pin specification with an exclamation mark and it becomes active low instead.
Heads up: on some hardware platforms you may also need to set the SQL_GPIOD_CHIP configuration variable, in case the pin you want isn't living on the default GPIO chip.
Example: SQL_GPIOD_LINE=17
SQL_GPIOD_BIAS
This config variable is only available when SvxLink has been built with libgpiod >= 1.5 — so check your build first, bestie 📌
It lets you set whether the squelch GPIO pin should be pulled up or down. Don't know what that means? Go read the documentation for your hardware interface and see whether it needs a pull up or pull down. It's an electronics thing ⚡ In essence: a pull up forces the pin high when nothing is connected to it, and a pull down forces it low.
SQL_COMBINE
This one sets a logical expression used to combine multiple squelch types — the icon of squelch configs, honestly 🧚
The expression syntax uses names of configuration file sections where a specific squelch type is set up, plus these operators:
|— logical or&— logical and!— logical negation
Parts of the expression can be grouped by wrapping them in parentheses, which effectively changes operator precedence. The normal precedence is that & binds harder to its operands than |. The ! operator binds the hardest 🔥
Below is a simple example of how to set up a combined squelch:
[Rx1:CTCSS]
SQL_DET=CTCSS
CTCSS_FQ=77.0
CTCSS_SNR_OFFSETS=77.0:-3.22
[Rx1:SIGLEV]
SQL_DET=SIGLEV
SQL_SIGLEV_RX_NAME=Rx1
SQL_SIGLEV_OPEN_THRESH=30
SQL_SIGLEV_CLOSE_THRESH=2
[Rx1]
...
SQL_DET=COMBINE
SQL_COMBINE=Rx1:CTCSS | Rx1:SIGLEV
...The configuration section names used above are just a convention, but it's wise to include the name of the associated RX so your diagnostic messages actually make sense 💡
Squelch timing parameters like SQL_DELAY, SQL_HANGTIME etc. may be set up in the receiver configuration section (Rx1 in the example above). Those parameters will not be applied to each subsquelch — they'll be applied to the combiner itself. It's often better to set up parameters in each squelch-specific configuration section, unless you really know what you're doing 😌
SQL_SIGLEV_RX_NAME
When you're using the SIGLEV squelch type, this specifies the name of the receiver that provides the signal level. It's only useful when the squelch configuration isn't sitting in the same configuration section as the receiver — like when you're using the COMBINE squelch type, for example. The default is to just use the same configuration section where the SIGLEV squelch is configured 🎀
SIGLEV_DET
Choose which type of signal level detector to use. The available choices are: "NONE", "NOISE" (default), "TONE", "AFSK", "SIM" or "CONST". Depending on your other configuration there may be even more choices available — for example, if a Ddr receiver is used there will also be a DDR signal level detector available 👑
The signal level detector is only needed when you're using multiple receivers in a voter configuration, or when you're using the SIGLEV squelch type.
NONE— disables the signal level detector. Use this if you don't need a signal level detector at all. Simple. Clean. Periodt 💅NOISE— uses a bandpass filter in the range of 5 - 5.5kHz (whenCARD_SAMPLE_RATE >= 16000) or a high-pass filter at 3.5kHz (whenCARD_SAMPLE_RATE = 8000) to estimate how much noise is hanging out on the signal. If the passband contains a small amount of energy, a strong signal is assumed. If the passband contains more energy, a weaker signal is assumed. The noise detector must be calibrated for the receiver and audio levels you use — do this with theSIGLEV_SLOPEandSIGLEV_OFFSETconfiguration variables. See the chapterCALIBRATING THE SIGNAL LEVEL DETECTORbelow for more info 🔧TONE— not really a signal level detector at all, but rather a transport mechanism for getting signal level measurements from a remote receiver site (linked in via RF) to the main SvxLink site. It uses ten tones — one for each signal level step — in the high audio frequency spectrum (5.5 - 6.4kHz, 100Hz step) to indicate one of ten signal levels. Only the receiving part has been implemented in SvxLink at the moment. On the remote receiver side, an Atmel AVR ATmega8 is used to map the signal level voltage to tone frequencies. Use theTONE_SIGLEV_MAPconfiguration variable to map each tone to a corresponding signal level value between 0 - 100 📡AFSK— like theTONEdetector, this is really a transport mechanism. Signal level values are transmitted using Audio Frequency Shift Keying, AFSK, over the receiver uplink channel from a remote receiver site. AFSK reception must have been enabled by settingOB_AFSK_ENABLE=1and also optionallyIB_AFSK_ENABLE=1✨SIM— a simulated signal level detector you can use to debug problems in the SvxLink software. Configure the simulator with theSIGLEV_MIN,SIGLEV_MAX,SIGLEV_DEFAULT,SIGLEV_TOGGLE_INTERVALandSIGLEV_RAND_INTERVALconfiguration variables 🧪CONST— not a detector at all. Instead, you get to set a constant signal level. This can be used for audio sources that don't have the concept of a signal level. If configured in a receiver managed by a Voter, it can be used to determine priority in comparison to other receivers and audio sources. Use theSIGLEV_CONSTconfiguration variable to set the signal level 💜
HID_DEVICE
This parameter defines the device your hidraw adapter is connected to. This port is created by the linux/hidraw driver 🐧
e.g. HID_DEVICE=/dev/hidraw3
HID_SQL_PIN
Define the pin your hardware squelch (from RX) is connected to. Valid values are VOL_UP, VOL_DN, MUTE_PLAY or MUTE_REC 🎚️
Example: HID_SQL_PIN=VOL_UP
SIGLEV_SLOPE
The slope (or gain) of the signal level detector. See the chapter CALIBRATING THE SIGNAL LEVEL DETECTOR below for more information 📈
SIGLEV_OFFSET
The offset of the signal level detector. See the chapter CALIBRATING THE SIGNAL LEVEL DETECTOR below for more information 📉
SIGLEV_BOGUS_THRESH
This configuration variable sets an upper threshold for the estimated signal level when you're using the noise signal level detector. If the estimation goes over that threshold, a signal level of 0 will be reported 🚫
Why would you want that? It's a workaround for receivers with squelched audio output. When the squelch is closed, the receiver audio goes silent — and the signal level estimator will read that silence as a very strong signal 😭 Setting up the bogus signal level threshold counteracts this behavior, but honestly, a better solution is to use unsquelched audio if you possibly can.
By default this feature is disabled. If you do enable it, start with a value somewhere around 120.
TONE_SIGLEV_MAP— okay bestie so this one is the ✨tone-to-signal-level translator✨. It gets used whenSIGLEV_DET=TONE. It's a comma separated list of ten values, each in the0 - 100range. The first value maps to the5500Hztone, the second to the5600Hztone, and so on all the way down the line 💫 — the last value maps to the6400Hztone. Exactly what levels the tones get mapped to depends on how your tone sender is built, iykyk. The default tone map is10,20,30...,100.
The Atmel AVR processor the author uses has a reverse mapping — so the first tone (5500Hz) indicates the highest signal strength and the last tone (6400Hz) indicates the lowest. It's also not linear, because honestly it matters way more to have fine measurement granularity down in the low signal strength range. This is what the mapping looks like for the AVR:
100,84,60,50,37,32,28,23,19,8.SQL_SIGLEV_OPEN_THRESH— the squelch open threshold for the SIGLEV squelch detector 🫶. If you're using theNOISEsignal level detector, make sure you first calibrate the signal level detector with theSIGLEV_SLOPEandSIGLEV_OFFSETconfiguration variables. Normally the signal level detector should be calibrated so that full signal strength is100and no signal is0. Depending on your background noise level, a good value here is somewhere between5and20✨.SQL_SIGLEV_CLOSE_THRESH— and this one is the squelch close threshold for the SIGLEV squelch detector 💅. Same deal: if you're using theNOISEsignal level detector, calibrate the signal level detector first usingSIGLEV_SLOPEandSIGLEV_OFFSET. The signal level detector should normally be calibrated so full signal strength is100and no signal is0. Depending on your background noise level, a good value for this one is between1and10🌸.SIGLEV_MIN— the minimum signal level used by the SIM signal level detector.SIGLEV_MAX— the maximum signal level used by the SIM signal level detector.SIGLEV_DEFAULT— the default signal level set on startup by the SIM signal level detector.SIGLEV_TOGGLE_INTERVAL— the interval, in milliseconds, that the SIM signal level detector uses to toggle between the maximum and the minimum signal levels 🔁.SIGLEV_RAND_INTERVAL— the interval, in milliseconds, that the SIM signal level detector uses between randomizing a new signal level value. At each interval, the simulator randomly either increases or decreases the signal level by one step 🎲.DEEMPHASIS— applies a deemphasis filter on received audio 🎧. You want this when you're taking audio directly from the detector in the receiver, like when you're using a9k6packet radio connector. Skip the deemphasis filter and the high frequencies get amplified, which gives you that very bright (tinny) sound — not the vibe, honestly 😭.SQL_TAIL_ELIM— squelch tail elimination, and yes it does exactly what it says 🎀: it removes noise from the end of a received transmission. It's most useful when you're using CTCSS or SIGLEV squelch with unsquelched input audio. A normal value is a couple hundred milliseconds.
Careful bestie — the audio will be delayed by the same amount of milliseconds. On a simplex link that's whatever, but on a repeater the delay might be annoying since you risk hearing the end of your own transmission 🙈.
PREAMP— the incoming signal gets amplified by the specified number of dB 📈. This is a last-resort move if the input audio level just can't be set high enough on the analogue side. A value of6dBwill double the signal level. But ngl, this is digital amplification, so it reduces the dynamic range of the signal — avoid it if you possibly can. It's always better to fix the audio level before sampling it 💯.PEAK_METER— a lil helper for adjusting your incoming audio level 👑. If it's enabled, it prints a message when distortion occurs. To adjust the audio level: first open the squelch, then increase the audio level until warning messages start printing. Then decrease the audio level until no warning messages print. Once you're done adjusting, you can disable the peak meter.0=disabled,1=enabled.DTMF_DEC_TYPE— specifies the DTMF decoder type 📟. Set it toINTERNALto use the internal software DTMF decoder. To use theS54Sinterface with its hardware DTMF decoder, set it toS54S. To control it over a pseudo tty device, set it toPTY— doing that installs the PTY dtmf decoder, and SvxLink creates a symlink linked to a slave pty device at runtime. That name has to be defined withDTMF_PTY. And if AFSK reception is enabled usingOB_AFSK_ENABLE/IB_AFSK_ENABLE, remotely decoded DTMF digits may be received by setting this configuration variable toAFSK. Setting it toNONE(or just commenting it out) disables DTMF detection entirely 🚫.DTMF_MUTING— mutes the audio while a DTMF digit is being received 🤫. Heads up: the audio will be delayed like40-75ms, depending on which DTMF decoder you're using, so the decoder has time to do its thing. On a simplex link this doesn't matter much, but on a repeater it could be annoying since you'll hear the last40-75milliseconds of your own transmission 😭. To counteract the added delay you can set theSQL_TAIL_ELIMconfiguration variable to at least40milliseconds. Legal values forDTMF_MUTINGare0=disabled,1=enabled.DTMF_HANGTIME— use this one if your DTMF decoder is being too quick to indicate digit idle 🏃♀️. At high signal strengths that's fine, but for weaker signals and mobile flutter it's not good at all — each DTMF digit ends up detected multiple times. With this configuration variable, you can extend the time (ms) a tone must be missing to be indicated as off. Set it too high though and the decoder gets a bit sluggish, and it might consider two digits as one 💀. The hang time only affects consecutive digits of the same value (e.g.1 1). If a detected digit differs from the previously detected digit (e.g.1 2), the hang time is immediately canceled and the detected digit counts as a new one. A good default value is50-100ms✨.DTMF_SERIAL— when you're using an external hardware DTMF decoder, this config variable specifies a serial port (e.g./dev/ttyS0).DTMF_PTY— when you're using the PTY DTMF "decoder", this configuration variable sets the path to the PTY slave softlink that the external interface script uses to talk to SvxLink 🔗. Over this softlink a very simple communication protocol is used to notify SvxLink about received DTMF digits:0-9,A-F,*,#."E"is the same as*and"F"is the same as#. Sending a digit tells SvxLink when it starts. To tell SvxLink that the digit has ended, send a space character.
The PTY DTMF "decoder" can be used by an external script to interface custom devices, modems or other hardware to SvxLink 🛠️. Go look for nhrcx.pl or trx_pty_ctrl.py for an example.
It is possible to specify the same PTY for multiple functions (e.g. squelch, ptt etc) in both TX and RX configurations 👯. This may be good if there's one script handling all functions.
Example: /tmp/rx1_dtmf.
DTMF_MAX_FWD_TWIST— DTMF uses two tones to encode digits0-9,A-F🎵. These two tones should normally have the same amplitude. The difference in amplitude is called twist. Forward twist is when the higher frequency tone is lower in amplitude than the lower frequency tone. According to the standards,8dBforward twist should be allowed. Some transmitters don't correctly modulate the DTMF tones to get zero twist, and the most common situation is that the forward twist is too large. Increasing this configuration variable above8dBmight let DTMF from those transmitters get detected — but when you do that, the DTMF detector becomes more sensitive to noise and might cause more false triggers ⚠️.DTMF_MAX_REV_TWIST— same two-tone situation, digits0-9,A-F, same amplitude ideally, and again the amplitude difference is called twist. Reverse twist is when the lower frequency tone is lower in amplitude than the higher frequency tone. According to the standards,4dBreverse twist should be allowed, but SvxLink will allow6dBby default 💅. The most common reason you get reverse twist is a bad de-emphasis filter, or no de-emphasis filter at all — like when taking audio directly from the FM discriminator. So go have a look at theDEEMPHASISconfiguration variable before you start modifying this one 👀.DTMF_DEBUG— set to1to continuously print software DTMF decoder decision parameters 🖨️. Only use this for a short while to pinpoint problems with DTMF decoding, because it prints one row of analysis parameters 100 times per second 😵. Here's what gets printed:pwr— the power in the audio signal. Must be over about-50dB.q— quality. Should be close to1.00for a good detection. If the signal is strong but the value is low anyway, the signal is probably distorted for some reason — the input audio level may be too high, for example.twist— the amplitude difference between the two tones. Should be around0dB, meaning the tones should ideally be of the same strength. By default, values between-6dBto+8dBare accepted, but the thresholds can be set using theDTMF_MAX_FWD_TWISTandDTMF_MAX_REV_TWISTconfiguration variables.rowq— quality of the row (low group) tone. Should be close to one.colq— quality of the column (high group) tone. Should be close to one.digit— the digit mapped to the two detected tones.row3rd— the row tone relation to its third overtone. Should be close to zero. If it's not, the signal is probably distorted.
col3rd— the column tone's relation to its third overtone. Should be close to zero. If it's not close to zero, then bestie, the signal is probably distorted. 💀im— the relation of the two tones to their intermodulation product. Should also be close to zero, and again, if it isn't, the signal is probably distorted.
1750_MUTING 🫶
Mutes the audio while a call tone of 1750Hz is coming through. Heads up though: the audio gets delayed 75ms so the tone detector has time to do its lil job. On a simplex link that's whatever, nbd. But on a repeater? It could be lowkey annoying, because you'll hear the last 75 milliseconds of your own transmission. 😭 To counteract that added delay you can set up the SQL_TAIL_ELIM configuration variable to at least 75 milliseconds. Legal values for 1750_MUTING are 0=disabled, 1=enabled.
SEL5_TYPE ✨
This is where you define your selective tone call system. The menu of types: ZVEI1, ZVEI2, ZVEI3, PZVEI, PDZVEI, DZVEI, CCITT, EEA, CCIR1, CCIR2, NATEL, EURO, VDEW, AUTO-A, MODAT, PCCIR and EIA. Only one system at a time, no cap. And pls take into consideration that some Sel5 standards use the same or similar tones, so it may have some unwanted effects if you define ZVEI1 for SvxLink and a (e.g.) ZVEI3 sequence gets received. 🙈
SEL5_DEC_TYPE 💅
At the moment only SEL5_DEC_TYPE=INTERNAL is valid. Maybe we'll have support for some external tone detectors later, we'll see. To disable SEL5 tone decoding, just specify NONE or simply comment the configuration variable out.
RAW_AUDIO_UDP_DEST 🌈
Setting this configuration variable makes it possible to stream the raw audio from the sound device straight to a UDP socket. The sample format is the one used internally in SvxLink, that is each sample is represented by a 32 bit float. The sample rate is the same as the one chosen for the audio device. The destination is specified as ip-address:port.
Example:
RAW_AUDIO_UDP_DEST=127.0.0.1:10000OB_AFSK_ENABLE 🦋
Set to 1 to enable reception of metadata like signal level measurements, DTMF digits and tone detections via out-of-band (OB) AFSK. The out-of-band AFSK is transmitted above the voice band, so it's possible to transmit AFSK bursts at the same time as someone is speaking. 🗣️ The AFSK bursts are filtered out before the audio is handed on to the next stage, so normal users should never hear them. The AFSK feature is typically used on a remote receiver uplink. The protocol used is SvxLink specific. Data is transmitted in 300Bd with a shift of 170Hz and a center frequency of 5500Hz. The RemoteTrx application have the capability to transmit this protocol.
OB_AFSK_VOICE_GAIN 🎀
To be able to send both voice and AFSK at the same time it may be necessary to lower the level of the voice audio so you don't overdrive the transmitter. This is compensated in the link receiver by amplifying the voice audio back to its original level. So this configuration variable should be set to the negated value of the same configuration variable in the transmitter section of the transmitting RemoteTrx. If it's set to -6dB in the transmitter configuration it should be set to 6dB here. Math girlies rise 💅
IB_AFSK_ENABLE 🌸
Set to 1 to enable reception of an initial signal level measurement via in-band (IB) AFSK. This works in cooperation with the out-of-band AFSK feature to quickly transfer a signal level measurement so you can get the squelch opened. The in-band AFSK is transmitted in the voice band and can thus use the higher baudrate of 1200Bd. And since it's only transmitted when the squelch is closed, the end user will not hear the AFSK burst. 🫶 The AFSK feature is typically used on a remote receiver uplink. The protocol used is SvxLink specific. Data is transmitted in 1200Bd with a shift of 1000Hz and a center frequency of 1700Hz. The RemoteTrx application have the capability to transmit this protocol.
CTRL_PTY 👑
Set this configuration variable to the path of a PTY to use for controlling a receiver's frequency and modulation. This can be used to interface a receiver to SvxLink using a translation script, like trx_pty_ctrl.py. To set the receive frequency, SvxLink will send the sequence <frequency> followed by ;. Wait, more precisely, like this: f<frequency>;. The frequency will be in Hz, e.g. f145550000; will be sent to set the receiver to 145.550MHz.
To set the modulation the command is m<modulation>;. Look at the documentation of the MODULATION configuration variable to see which modulations that are available. To set "normal" 25kHz channel spaced FM the command would be mFM;.
It is possible to specify the same PTY for multiple functions (e.g. squelch, ptt etc) in both TX and RX configurations. This may be good if there is one script handling all functions. Very one-script-does-everything of it. 😌
LADSPA_PLUGINS 🧚
Used to set up one or more LADSPA plugins to process the received audio. The processing chain is applied just before the final stages of the receiver audio processing and will only affect how the audio sounds. Any digital signal processing done on the audio before that, like DTMF, CTCSS etc, is unaffected. ✨
See "LADSPA PLUGIN USAGE" for more information.
Ddr Receiver Section 📻
A special kind of local receiver is the Digital Drop Receiver (DDR). It will use either the rtl_tcp utility or a direct USB connection to interface to a RTL2832U based DVB-T USB dongle, and use that as a wide-band receiver. These USB dongles can be bought cheaply from an Internet shop (~$10). The radio performance may not be great but better than one might think. Usage as a cheap local coverage receiver or as a link receiver may work very well. Honestly? Budget queen energy. 💅
One big advantage of using a wide-band receiver is that it is possible to monitor more than one narrow band channel at a time. The only limit is the CPU power and the bandwidth of the wide-band tuner. You probably need a Pentium4 or better to fulfill the CPU demands.
Getting the DVB-T dongle running is out of scope for this document, but what you absolutely need to do is to find out the frequency error on your specific dongle. When you have figured out what the frequency error is, set up the FQ_CORR configuration variable in the wide-band receiver configuration section.
The rtl_tcp utility is in a package named similar to something like rtl-sdr. When you have the rtl-sdr stuff installed, just start rtl_tcp. No command line arguments are needed. Then configure a Ddr receiver in SvxLink. All configuration variables that are available for an ordinary local receiver is also available for a Ddr receiver, except the audio device related ones which are just ignored. The following configuration variables are available in addition to the ordinary ones. 🫶
FQ— The narrow-band channel frequency to tune to.
MODULATION 🌈
The modulation used on the channel. Legal values are: "FM" (two-way radio frequency modulation), "NBFM" (two-way radio narrow frequency modulation), "WBFM" (broadcast wide-band frequency modulation), "AM" (two-way radio amplitude modulation), "NBAM" (two-way radio narrow band amplitude modulation), "USB" (Upper Sideband), "LSB" (Lower Sideband), "CW" (Continuous Wave, e.g. Morse), "WBCW" (CW wide).
WBRX— The configuration section for the wide-band receiver to connect this DDR to. See "wide-band Receiver Section" below.
SIGLEV_DET 🦋
For a Ddr there also is a special signal level detector available, DDR, that will measure the RF power before demodulation. This is much more reliable than estimating the signal power through the audio, which is normally done in SvxLink. The drawback is that the Ddr signal level is not completely comparable to the ordinary SvxLink signal level measurements since it have a larger dynamic range. Set SIGLEV_DET=DDR to activate the Ddr signal level detector.
Wide-band Receiver Section 🌊
A wide-band receiver section is used to configure access to a wide-band receiver which can be used by a Digital Drop Receiver (DDR), described above, to handle multiple narrow-band channels using the same hardware. The only hardware supported at the moment is RTL2832U based DVB-T USB dongles. SvxLink access the dongle directly via USB or through the rtl_tcp utility, which make the dongle available on a TCP network port. The following configuration variables are available:
TYPE— The type of wide-band receiver used. The only supported values right now are"RtlTcp"and"RtlUsb".
DEV_MATCH 🎀
When using RtlUsb, this configuration variable is used to select the dongle to use if there are multiple dongles connected to the computer. When looking for dongles, SvxLink will try to match the string given in this configuration variable in different ways. First, if it's a digit, a match against the device index is tried. The device index is just a number, zero and up, that is given to a dongle when it's inserted.
If the device index does not match, a match against the beginning, end or the whole serial number will be tried.
Default: 0 (first device found)
HOST— The name of the host that thertl_tcputility is running on (Default:localhost).PORT— The TCP port thatrtl_tcpis listening on (Default:1234).
SAMPLE_RATE ⭐
The sample rate used by the dongle. Legal values are 960000 and 2400000 (Default: 960000).
FQ_CORR 👑
This is probably the most important configuration variable. Most dongles are far off in frequency so they need to be calibrated. Calibrating the dongle can be done in multiple ways. The recommended way is to use the devcal utility that is distributed along with SvxLink. The calibration procedure is described in the devcal (1) manual page.
The end result should be a correction value for how far off the dongle is in frequency counted in parts per million (PPM). That is, how many Hz per MHz is the tuner off by. Typical values are in the range -100 to 100. 🦋
CENTER_FQ— okay so this is the frequency, in Hz, that the wide-band tuner should be placed at. Normally you just leave this unset because SvxLink will try to place the wide-band tuner to cover all set up Ddr frequencies. SvxLink will also try to avoid placing a Ddr on the center frequency of the wide-band spectrum since there is usually some noise there. Only touch this if you need to override the automatic placement for some reason. 💅XVRTR_OFFSET— If a transverter is used, this configuration variable can be set to the frequency offset that the transverter introduce. The frequency set here will be added to the center frequency of the wide-band receiver. ✨GAIN— If unset, automatic gain is used. Do not use automatic gain control if using the DDR signal level detector. That may mess up the measurements. Finding a good gain setting may be hard. Too little and you will not hear the signals you want to hear. Too much and the tuner will be driven into distortion. One way to decide the maximum usable gain is to use thePEAK_METERexplained below. When there are no distortion warning messages printed or just a single one now and then you have found the max gain. You should probably back at least one step down from this value. If the signals you want to receive are very strong, set the gain as low as possible.
What gain values that are available is tuner dependent. SvxLink will print the available gain values when it establishes the connection to the tuner. Typical values are in the range -10 to 50dB.
PEAK_METER— IfPEAK_METERis set to1, a warning will be printed every time the tuner is driven into distortion. If it happens too often the gain should be lowered. At most, one warning per second will be printed. 🚨
✨ LocalSim Receiver Section ✨
A simulated local receiver can be used to debug problems in the SvxLink software. The only thing that this very simple simulator does is to play a tone. The generated tone can be controlled using some configuration variables. 🎵
SIM_WAVEFORM— Set the waveform to use;SIN=sine wave,SQUARE=square wave.SIM_TONE_FQ— Set the frequency of the tone in Hz.SIM_TONE_PWR— Set the tone power in dB.0dBcorresponds to the power in a full-scale sine wave.
🗳️ Voter Section 🗳️
Receiver type "Voter" is a "receiver" that combines multiple receivers and selects one of them to take audio from when the squelch opens. Which receiver to use is selected directly after squelch open. It is possible to set up a voting delay which will make the voter wait a while before choosing which RX to use. This will give all receivers some time to report their signal strengths. After the initial choice have been made a periodic check is done to see if any of the other receivers receive a stronger signal. In the default configuration file there is a voter section called Voter. 👑
TYPE— Always"Voter"for a voter.RECEIVERS— Specify a comma separated list of receivers that the voter should use. Optionally the receiver name may be followed by a colon and a squelch delay value. This can be used to adjust the voting delay for receivers that always are slower to open for some reason. The delay value given will be subtracted from the voting delay if the receiver is the first one to open.
The usage of the delay value is best illustrated with an example. Let's say we have three receivers where two of the receivers take at most 100ms to report signal level and one receiver requires 300ms. We then need to set the VOTING_DELAY to something like 350ms so as to be sure that all receivers get a chance to report their signal level measurement. If only the slow receiver opens there will be a total delay of 300+350=650ms. This is unnecessarily long since the other two receivers should have reported their signal strength way earlier. It's thus safe to shorten the voting delay for the slow receiver, so we do this: RECEIVERS=FastRx1,FastRx2,SlowRx:200. The total squelch open delay will now be 100+350=450ms for the fast receivers and 300+350-200=450ms for the slow receiver. That is, all receivers are now equally fast.
Example: RECEIVERS=Rx1,Rx2:200,Rx3
VOTING_DELAY— Specify the delay in milliseconds that the voter will wait after the first squelch open detection until the decision of which receiver to use is made. This time must be set sufficiently high to allow all receivers to calculate and report the signal level. Incoming audio and DTMF digits will be buffered for all receivers during the delay time so nothing will be lost, but of course the audio will be delayed the specified amount of time. This is most noticeable when using a repeater logic. Use theBUFFER_LENGTHconfiguration variable to adjust the buffer length. The default voting delay is0.BUFFER_LENGTH— Use this configuration variable to adjust the length of the voting delay buffer. If not specified, the buffer length will be the same as the voting delay. When using the voter with a repeater logic, try to keep this variable at0to reduce the latency. Only increase it if you feel audio is lost in the beginning of transmissions.REVOTE_INTERVAL— This is the interval time in milliseconds with which the voter will check if another receiver is receiving a stronger signal. If that is the case, a receiver switch will be initiated. Default is1000milliseconds.HYSTERESIS— The hysteresis setting will prevent the voter from switching back and forth between two receivers that are equal in signal strength. For a switch to occur, the other receivers signal strength must exceed the current receivers signal strength by the percent specified in this configuration variable. So if the hysteresis is set to50%and the received signal strength on the current receiver is40, a signal strength of40*1.5=60is required on another receiver to initiate a switch. At squelch open, if the received signal strength plus hysteresis is larger than100, the voting delay will be skipped. The default hysteresis is50percent.RX_SWITCH_DELAY— When a receiver switch is initiated by the voter, it will wait the number of milliseconds specified in this configuration variable before actually performing the switch. The switch will only occur if the other receivers signal strength is still higher. Default is500milliseconds.SQL_CLOSE_REVOTE_DELAY— The voter will wait the number of milliseconds specified in this config variable after a squelch close before voting in another receiver. There are two reasons for using this delay. The first is to prevent the voter from going into idle state immediately when the squelch close for a fluttery signal. If it goes to idle, the procedure with voting delay may cause longer dropouts than necessary. The second reason to use this config variable is if different receivers have different hang times (explicitly or implicitly). If both a slow and fast receiver is receiving the same signal and the faster is currently chosen, when the PTT is released the slower receiver will be voted before closing. This will cause a double squelch tail and double roger beep. Default is500milliseconds. 😭COMMAND_PTY— Specify the path to a PTY that can be used to control the voter from the operating system. Available commands:ENABLE rx_name— Enable the given receiverMUTE rx_name— Mute the given receiverDISABLE rx_name— Disable the given receiver
The difference between MUTE and DISABLE is that in the mute state only the content (audio, dtmf, selcall tone detectors etc) is muted but the receiver is still operational. That is probably only useful if also setting VERBOSE=1 so that squelch open/close can be monitored in the log. That may be useful if a new receiver is connected to the system which you want to monitor for a while without having it actually participate in the voting. It may also be of use if a receiver misbehaves in which case it can be monitored until it stops misbehaving.
Commands can be issued using a simple echo command from the shell. Example: echo "DISABLE Rx1" >/dev/shm/voter_ctrl
VERBOSE— Set this to1to enable verbose mode. In verbose mode the squelch state events of the satellite receivers will be printed. This can be used for fine tuning voter timing parameters. Default:0(disabled)
🌐 Networked Receiver Section 🌐
A networked receiver section is used to specify the configuration for a receiver connected through a TCP/IP network. In the default configuration file there is a networked receiver configuration section called NetRx. The section name could be anything. It should match the RX configuration variable in the logic core where the receiver is to be used. The available configuration variables are described below. How to use a networked receiver is further described in the remotetrx(1) manual page. 🦋
TYPE— Always"Net"for a networked receiver.HOST— The hostname or IP address of the remote receiver host.TCP_PORT— The TCP port that RemoteTrx listen on. The default is5210.LOG_DISCONNECTS_ONCE— Set this configuration variable to1to suppress logging of multiple disconnect messages in a row, like when there is no RemoteTrx running on the other side. Thus, failed reconnect attempts will not be logged at all. This may be of use if a RemoteTrx is missing for a long time or if it's only used from time to time. The default is0which means that all reconnect attempts will be logged. 💜AUTH_KEY— bestie, this is the auth key (aka the password) you use to connect to theRemoteTrxserver. The same key has to be in theRemoteTrxconfig too, okurrr? If theRemoteTrxconfig has no key at all, the login is just… unauthenticated 🙈. A good auth key should be 20 characters long. And if the sameRemoteTrxis doing both RX and TX duty, then the same key must go in the RX section and the TX section. The key itself is never transmitted over the network — instead a HMAC-SHA1 challenge-response procedure handles authentication. Queen behavior 🔐CODEC— the audio codec used when transferring audio from this remote receiver. Your options are:RAW(512kbps),S16(256kbps),GSM(13.2kbps),SPEEX(8-25kbps),OPUS(8-64kbps). These are the raw bit-rate values, so heads up — there's some overhead on top, meaning the real bit-rates on the wire run a lil higher.OPUSis the most modern one and it also has the best quality for any given bit-rate. It's giving main character energy, periodt ✨SPEEX_ENC_FRAMES_PER_PACKET— a Speex encoder setting. Every Speex frame holds 20ms of audio. If you're running a low bit-rate config, the network overhead is super noticeable when each frame gets its own packet. One way to chill that overhead out is stuffing multiple frames into each network packet. Downside? You get more delay. Set this to something like4(which is the default) and the delay ends up around 4x20=80ms. Tradeoffs, bestie 💅SPEEX_ENC_QUALITY— a Speex encoder setting. Tell the encoder the quality you want with a number between 0-10. Lower values = poorer quality and lower bit-rates.SPEEX_ENC_BITRATE— a Speex encoder setting. Set the bit-rate you want and Speex will snap to the nearest lower possible bit-rate. Possible values go from2150to24600bps. You should probably not specify quality and bit-rate at the same time. Not sure though… 😭SPEEX_ENC_COMPLEXITY— a Speex encoder setting. This complexity value (0-10) tells the encoder how much CPU time it should spend doing a good job. The SNR difference between the lowest and highest value is about 2dB. So set it as high as possible without overloading the CPU on the encoding computer (check that CPU usage with the command"top"). No cap, just don't cook your CPU 🔥SPEEX_ENC_VBR— a Speex encoder setting. Enable (1) or disable (0) variable bit-rate encoding. Turn it on and the encoder tries to keep a constant quality by bumping the bit-rate up whenever it's needed.SPEEX_ENC_VBR_QUALITY— a Speex encoder setting. The quality (0-10) to use in variable bit-rate mode.SPEEX_ENC_ABR— a Speex encoder setting. Average bit-rate encoding tries to hold a target bit-rate by continuously adjusting the quality. This config variable sets that target bit-rate and enables ABR. It also needs VBR to be enabled, so don't force it off, okay?? 🫶SPEEX_DEC_ENHANCER— a Speex decoder setting. Enable (1) or disable (0) the perceptual enhancer in the decoder. Perceptual enhancement is a part of the decoder that, when it's on, tries to reduce how much you perceive the noise/distortion that the encoding/decoding process made. In most cases it drags the sound further from the original objectively speaking (like, if you only look at SNR), but in the end it still sounds better — that's the subjective glow-up 🌸OPUS_ENC_FRAME_SIZE— an Opus encoder setting. Says how large, in milliseconds, each audio packet should be. Default:20ms.OPUS_ENC_COMPLEXITY— an Opus encoder setting. The complexity value (0-10) tells the encoder how much CPU time it should spend doing a good job. Set it as high as possible without overloading the CPU on the encoding computer (check CPU usage using command"top"). Default:10. Go big or go home 👑OPUS_ENC_BITRATE— an Opus encoder setting. This is the bit-rate the encoder will encode for. Rates from about8000to64000bits per second are meaningful, but the codec can actually handle from like2500to512000bps. Default:20000bps.OPUS_ENC_VBR— an Opus encoder setting. Enable (1) or disable (0) variable bit-rate encoding. With it on, the encoder tries to hold a constant quality by raising the bit-rate when needed and dropping it back down when the quality can be assured at a lower bit-rate. The target average bit-rate is whateverOPUS_ENC_BITRATEsays. Default:1.
🌈 Local Transmitter Section 🌈
A local transmitter section is where you write out the config for a local transmitter. In the default configuration file there's a section called Tx1. The section name can literally be anything you want — it just has to match the TX configuration variable in the logic core where that transmitter is going to be used. All the config variables available are down below, bestie 💖
TYPE— always"Local"for a local transmitter.TX_ID— a single character ident for this transmitter. It's used, for example, in state events published by transmitters through aSTATE_PTYor other state event consumers within SvxLink.AUDIO_DEV— specify the audio device to use. Normallyalsa:plughw:0. Go peek at the AUDIO DEVICE SPECIFICATIONS chapter for more info.AUDIO_CHANNEL— specify the audio channel to use. SvxLink can use the left/right stereo channels as two mono channels. Legal values are0or1.AUDIO_DEV_KEEP_OPEN— the normal behavior for SvxLink is to open an audio device when it's needed and close it once it doesn't have to be open anymore. That can cause problems in some applications or with certain sound hardware. Set this variable to1to force SvxLink to keep the audio device open from application start all the way to exit.LIMITER_THRESH— set the threshold, in dBFS, for the audio limiter. The audio limiter is really a compressor with a super steep compression ratio, like 10:1. The limiter's whole job is helping keep the audio level down so you don't overmodulate the transmitter. For a properly calibrated SvxLink node, max FM deviation is-6dBFS. A good value to start with here is-6, but try lowering it further (like-9to-12) if it doesn't affect audio quality negatively. Tune it till it slays 🎀PTT_TYPE— use this config variable to say which type of hardware controls the PTT. Set"SerialPin"to use a pin in the serial port,"GPIO"(sysfs=deprecated)/"GPIOD"to use a pin in a GPIO port,"PTY"if you wanna use an external interface script via a pseudo tty port, or"Hidraw"to use thelinux/hidrawdriver to support hidraw devices like the CM108 sound card, e.g. the URI device from DMK.
Set PTT_TYPE to "Dummy" or "NONE" to not use any PTT hardware at all. It is an error to not specify PTT_TYPE.
Use PTT_PIN to specify the pin for "SerialPin" or "GPIO".
Use PTT_GPIOD_LINE and PTT_GPIOD_CHIP to specify the GPIO pin to use for "GPIOD".
PTT_PORT— specify the serial port the PTT is connected to. E.g./dev/ttyS0for COM1.PTT_PIN— ifPTT_TYPEis"SerialPin", specify the pin(s) in the serial port the PTT is connected to. You can specify one or two serial port pins. Some interface boards need you to specify two pins because one pin alone doesn't give enough drive power to the circuit. A!in front of the pin name means inverted operation. Some of the possible values areRTS,DTRRTS,!DTR!RTSor evenDTR!RTS.
If GPIO was specified in PTT_TYPE, set the PTT_PIN config variable to the pin name of the GPIO pin to use. The most common name is gpio<number>, like gpio3. Some GPIO drivers use more complex pin names like gpio33_pe11. Have a look at the USING GPIO section for how to set up the operating system. Normally the pin is active high, but if the pin name is prefixed with an exclamation mark it'll be active low instead. For some hardware platforms you may need to also set the GPIO_PATH configuration variable.
GPIO_PATH— use this config variable to set the path to the sys control devices for GPIO. Normally this is/sys/class/gpio, but on some hardware, like the Orange Pi, the path is/sys/class/gpio_sw.PTT_GPIOD_CHIP— the path to the GPIO chip device node to use for PTT.
Example: PTT_GPIOD_CHIP=/dev/gpiochip0
PTT_GPIOD_LINE— ifGPIODwas specified inPTT_TYPE, set this config variable to the gpiod line of the GPIO pin to use. If a number is specified it's assumed to be the GPIO pin offset within the chip. If a pin name is specified, SvxLink will try to find a pin with that name within the chip.
Normally the pin is active high, but if the pin specification is prefixed with an exclamation mark it'll be active low instead.
For some hardware platforms you may need to also set the PTT_GPIOD_CHIP configuration variable, if the pin you want to use isn't on the default GPIO chip.
Example: PTT_GPIOD_LINE=17
PTT_PTY— ifPTT_TYPEis set to"PTY", this config variable sets the path for the PTY slave softlink that the external script uses to communicate with SvxLink.
SvxLink sends a 'T' to start transmitting and a 'R' to turn the transmitter off. An external script can use this to interface custom devices, modems or other hardware to SvxLink. Go look for nhrcx.pl to see an example.
It's possible to specify the same PTY for multiple functions (e.g. squelch, DTMF etc) in both TX and RX configurations. That may be good if there's one script handling all the functions.
HID_DEVICE— define the device node where your hidraw device is accessible at.
Example: HID_DEVICE=/dev/hidraw3
HID_PTT_PIN— define the pin your PTT control is connected to. Valid parameters are areGPIO1,GPIO2,GPIO3,GPIO4. Note that some sound cards like theSSS1621may not supportGPIO3andGPIO4! You can invert the behavior with a"!"in front of the name. Only one value is supported. 🦋
💖 SERIAL_SET_PINS
Okay so this one lets you pin the specified serial port pins into a static state, bestie. Super handy when you're using a pin as a reference voltage, or when a pin literally has to sit in a certain state so it doesn't mess with some other equipment's whole vibe. There are two pins you can play with here: RTS and DTR.
Slap an exclamation mark (!) in front of a pin and it gets cleared. No exclamation mark and it gets set. And heads up: this configuration variable can only be used when PTT_TYPE is set to "SerialPin". No cap.
Example time: SERIAL_SET_PINS=RTS!DTR will set RTS and clear DTR. ✨
🌸 PTT_HANGTIME
Use this configuration variable to set a PTT hangtime. This is lowkey great to have on a transmitter when you're running a tone squelch alongside it. Here's the tea: when the transmitter is told to stop transmitting, the tone gets turned off immediately, which makes the squelch close on the other side. But since the transmitter keeps transmitting for a little while longer, you don't get a squelch tail. Chef's kiss. 🎀
Another glow-up use case: on a remote receiver link transmitter, where you really don't want the transmitter flickering on and off between transmissions — or when the squelch closes and reopens super fast thanks to stuff like mobile flutter. Annoying, so this fixes it.
🔥 TIMEOUT
This is the feature that stops your transmitter from getting stuck transmitting forever. You just specify the number of seconds before the transmitter gets turned off. ✨
Okay but for real, pay attention: this is a low level security mechanism. It's only meant to kick in if there's a software bug in SvxLink, just so the transmitter won't transmit indefinitely. It is not meant to be used to keep people from talking too long. It's a bug trap, not a babysitter, iykyk.
⭐ TX_DELAY
The number of milliseconds (0-1000) to wait after the transmitter has been turned on until audio actually starts being transmitted. Use this to compensate for slow TX reaction, or for remote stations with slow reacting squelches. Patience is a virtue, bestie. 🦋
💜 CTCSS_FQ
The frequency in Hz of the CTCSS tone to transmit. You can specify fractions using "." as the decimal comma (e.g. 136.5). 🎀
But listen — for the tone to actually be transmitted, the CTCSS_LEVEL variable must also be set up, and the TX_CTCSS variable in the logic core configuration section too. All three or nothing, periodt.
🧚 CTCSS_LEVEL
The level in dBFS of the CTCSS tone to transmit. A value of 0 is the highest level, and lower (negative) values give a lower level. What level you should set depends on a bunch of factors — like the audio calibration settings and the low-pass characteristics of the hardware.
So let's assume an ideal audio path with a completely flat frequency response over the whole audio spectrum (yes, including the CTCSS frequency band), plus a standard audio calibration where maximum FM deviation corresponds to -6 dBFS. Under those assumptions, here's what applies 👇
The FM deviation of the CTCSS tone should land in between 500-800 Hz if you're using an FM channel with a maximum deviation of 5 kHz. Given that, you can calculate what the level in dBFS should be:
Llow = 20 * log10(500/5000) - 6 = -26
Lmid = 20 * log10(650/5000) - 6 = -24
Lhigh = 20 * log10(800/5000) - 6 = -22The default in the configuration file is -24. And just like before, for the tone to be transmitted, the CTCSS_FQ variable must also be set up, plus the TX_CTCSS variable in the logic core configuration section. Teamwork makes the dream work. 🫶
🌈 PREEMPHASIS
Turn this feature on if you're modulating the FM modulator directly — like through a 9k6 packet radio input. Because if no preemphasis filter gets applied to the audio, it will sound super dark when received. Not the vibe. 😭
But if you're modulating the transmitter through the microphone input, the radio will apply a preemphasis filter itself, so this feature should be disabled. 0=disabled, 1=enabled.
🍓 DTMF_TONE_LENGTH
The duration, in milliseconds, of DTMF digits transmitted on this transmitter. 100ms is the default. ⏱️
🎀 DTMF_TONE_SPACING
The spacing, in milliseconds, between DTMF digits transmitted on this transmitter. 50ms is the default. 💅
👑 DTMF_DIGIT_PWR
The power, in dB, of DTMF digits transmitted on this transmitter. Zero dB will give the same power in the generated signal as there is in a maximum amplitude (full scale) sine wave. -15dB is the default. 🔥
✨ TONE_SIGLEV_MAP
So it's possible to transmit one of ten tones along with the normal transmission to indicate a signal strength value to the receiver. This is most useful when you're using a local transmitter as a link transmitter in a RemoteTrx. It is not implemented, and probably not useful, in SvxLink Server. Another requirement: SvxLink has been compiled in 16kHz mode. Otherwise this feature is disabled. 🙈
The TONE_SIGLEV_MAP configuration variable is what maps tones to signal level values. It's a comma separated list of exactly ten values in the 0 - 100 range. The first value maps to the 5500Hz tone, the second to the 5600Hz tone, and so on. The last value maps to the 6400Hz tone. 🌈
What levels the tones should be mapped to depends on the tone receiver implementation. Typically, if you're using a SvxLink application as a receiver, the TONE_SIGLEV_MAP should be the same in the RX configuration for that node. Matchy matchy. 🫶
🦋 TONE_SIGLEV_LEVEL
Again: it's possible to transmit one of ten tones along with the normal transmission to indicate a signal strength value to the receiver. Most useful when using a local transmitter as a link transmitter in a RemoteTrx. It is not implemented, and probably not useful, in SvxLink Server. And again, another requirement is that SvxLink has been compiled in 16kHz mode — otherwise this feature is disabled. 😭
The TONE_SIGLEV_LEVEL configuration variable sets the tone level. It's a value in the 1-100 range, which indicates the output level in percent of the maximum possible level. The default is 10. 💜
🌸 LADSPA_PLUGINS
Used to set up one or more LADSPA plugins to process the transmitted audio. The processing chain gets applied right at the top of the transmitter audio processing, so it will only affect how the audio sounds. Any digital signal processing done on the audio after that — like DTMF, CTCSS, etc — is unaffected. Slay. 👑
See "LADSPA PLUGIN USAGE" for more info, bestie.
💅 MASTER_GAIN
This configuration variable lets you fine tune or increase the audio gain for all transmitted sound, for when it's just not possible to do it using the normal sound card hardware gain controls. The gain should be given in dB and can be both positive and negative. Go wild. ✨
🔥 OB_AFSK_ENABLE
Set to 1 to enable transmission of metadata — like signal level measurements, DTMF digits and tone detections — via out-of-band (OB) AFSK. The out-of-band AFSK gets transmitted above the voice band, so it's possible to fire off AFSK bursts at the same time as someone is speaking. 🎀
The AFSK bursts are filtered out before the audio is handed on to the next stage, so normal users should never hear them. The AFSK feature is typically used on a remote receiver uplink. The protocol used is SvxLink specific. Data is transmitted in 300Bd with a shift of 170Hz and a center frequency of 5500Hz. The RemoteTrx application has the capability to transmit this protocol.
⭐ OB_AFSK_VOICE_GAIN
To be able to send both voice and AFSK at the same time, it may be necessary to lower the level of the voice audio so you don't overdrive the transmitter. This gets compensated in the link receiver by amplifying the voice audio back up to its original level. 🫶
So this configuration variable should be set to the negated value of the same configuration variable in the receiver section of the receiving node. If it's set to 6dB in the receiver configuration, it should be set to -6dB here. Math is math. 💅
🎀 OB_AFSK_LEVEL
The out-of-band AFSK modulation level in dBFS (dB full scale). Default is -6dB. 🌈
💜 OB_AFSK_TX_DELAY
The number of milliseconds to send AFSK flag bytes before sending the actual data when transmitting an out-of-band packet. Get those flags out first. 🚩
🧚 IB_AFSK_ENABLE
Set to 1 to enable transmission of an initial signal level measurement via in-band (IB) AFSK. This works in cooperation with the out-of-band AFSK feature to quickly transfer a signal level measurement to get the squelch opened. ⚡
The in-band AFSK is transmitted in the voice band, so it can use the higher baudrate of 1200Bd. And since it's only transmitted when the squelch is closed, the end user will not hear the AFSK burst. Sneaky. 😌
The AFSK feature is typically used on a remote receiver uplink. The protocol used is SvxLink specific. Data is transmitted in 1200Bd with a shift of 1000Hz and a center frequency of 1700Hz. The RemoteTrx application has the capability to transmit this protocol.
🌸 IB_AFSK_LEVEL
The in-band AFSK modulation level in dBFS (dB full scale). Default is -6dB. ✨
👑 IB_AFSK_TX_DELAY
The number of milliseconds to send AFSK flag bytes before sending the actual data when transmitting an in-band packet. Flags first, always. 🚩
🔥 CTRL_PTY
Set this configuration variable to the path of a PTY to use for controlling a transmitter's frequency and modulation. This can be used to interface a transmitter to SvxLink using a translation script, like trx_pty_ctrl.py. 🎀
To set the transmit frequency, SvxLink will send the sequence "F<frequency>;". The frequency will be in Hz — e.g. F145550000; will be sent to set the receiver to 145.550MHz.
To set the modulation, the command is "M<modulation>;". Go look at the documentation of the MODULATION configuration variable to see which modulations are available. To set "normal" 25kHz channel spaced FM, the command would be MFM;. 💅
It is possible to specify the same PTY for multiple functions (e.g. squelch, ptt etc) in both TX and RX configurations. This may be good if there is one script handling all functions. One script to rule them all. 👑
✨ Networked Transmitter Section ✨
Okay so a networked transmitter section is what you write when your transmitter is out there living its life on the other end of a TCP/IP network instead of plugged into your sound card. 🛰️ In the default config file there's a networked transceiver configuration section chilling there called NetTx, but honestly the section name could be anything. Just make it match the TX configuration variable in the logic core where you want to use this transmitter. Here are the variables you can set, bestie:
TYPE— always"Net"for a networked transmitter. No cap, that's the whole job.TX_ID— a single character ident for this transmitter. It gets used, for example, in state events published by transmitters through aSTATE_PTYor other state event consumers inside SvxLink. SvxLink cannot at this moment get the TX ident from the remote transmitter, so you have to specify it here. 💅HOST— the hostname or IP address of the remote transmitter host. Where your transmitter at, fr fr.TCP_PORT— the TCP port that RemoteTrx listen on. The default is5210.LOG_DISCONNECTS_ONCE— set this to1to suppress logging of multiple disconnect messages in a row, like when there's no RemoteTrx running on the other side. So basically, failed reconnect attempts will not be logged at all. This may be of use if a RemoteTrx is missing for a long time or if it's only used from time to time. The default is0, which means that all reconnect attempts will be logged (so your logs will be yapping, nonstop).AUTH_KEY— this is the authentication key (password) you use to connect to the RemoteTrx server. The same key have to be specified in the RemoteTrx configuration. If no key is specified in the RemoteTrx config, the login will be unauthenticated. A good authentication key should be20characters long. If the same RemoteTrx is used for both RX and TX, the same key must be specified in the RX as well as in the TX configuration section. 🔐 The key will never be transmitted over the network — a HMAC-SHA1 challenge-response procedure is used for authentication. Iconic behavior honestly.CODEC— the audio codec to use when transferring audio to this remote transmitter. Available codecs are:RAW(512kbps),S16(256kbps),GSM(13.2kbps),SPEEX(8-25kbps),OPUS(8-64kbps). These are raw bit-rate values, so there will be some overhead added to this and the real bit-rates on the wire are a little bit higher. TheOPUScodec is the most modern one and it also have the best quality for a given bit-rate, periodt. There also is aNULLcodec that will just throw away samples, which can be used in special situations when the audio is sent through another audio path. 🗑️SPEEX_ENC_FRAMES_PER_PACKET— Speex encoder setting. Each Speex frame contains20msaudio. If you're using a low bit-rate configuration, the network overhead will be quite noticeable if you send each frame in its own packet. One way to lower the overhead is to send multiple frames in each network packet. The drawback with doing this is that you get more delay. If you set this option to something like4(default), the delay will be about4x20=80ms.SPEEX_ENC_QUALITY— Speex encoder setting. Specify the encoder quality using a number between0-10. Lower values give poorer quality and lower bit-rates.SPEEX_ENC_BITRATE— Speex encoder setting. Specify the bit-rate to use. Speex will snap to the nearest lower possible bit-rate. Possible values range from2150to24600bps. You should probably not specify quality at the same time as bit-rate. Not sure though... 🙈SPEEX_ENC_COMPLEXITY— Speex encoder setting. The complexity setting (0-10) tells the encoder how much CPU time it should spend on doing a good job. The difference in SNR between the lowest and highest value is about2dB. Set it as high as possible without overloading the CPU on the encoding computer (check CPU usage using command"top").SPEEX_ENC_VBR— Speex encoder setting. Enable (1) or disable (0) variable bit-rate encoding. If enabled, the encoder will try to keep a constant quality by increasing the bit-rate when needed.SPEEX_ENC_VBR_QUALITY— Speex encoder setting. The quality (0-10) to use in variable bit-rate mode.SPEEX_ENC_ABR— Speex encoder setting. The average bit-rate encoding will try to keep a target bit-rate by continuously adjusting the quality. This configuration variable specify the target bit-rate and enable ABR. It also need to have VBR enabled, so don't force it to off. 🙅SPEEX_DEC_ENHANCER— Speex decoder setting. Enable (1) or disable (0) the perceptual enhancer in the decoder. Perceptual enhancement is a part of the decoder which, when turned on, attempts to reduce the perception of the noise/distortion produced by the encoding/decoding process. In most cases, perceptual enhancement brings the sound further from the original objectively (e.g. considering only SNR), but in the end it still sounds better (subjective improvement). The way that it's technically worse but vibes better? That's art. 🎨OPUS_ENC_FRAME_SIZE— Opus encoder setting. Specify how large, in milliseconds, each audio packet should be. Default:20ms.OPUS_ENC_COMPLEXITY— Opus encoder setting. The complexity setting (0-10) tells the encoder how much CPU time it should spend on doing a good job. Set it as high as possible without overloading the CPU on the encoding computer (check CPU usage using command"top"). Default:10.OPUS_ENC_BITRATE— Opus encoder setting. This is the bit-rate that the encoder will encode for. Rates from about8000to64000bits per second are meaningful, but the codec can handle from like2500to512000bps. Default:20000bps.OPUS_ENC_VBR— Opus encoder setting. Enable (1) or disable (0) variable bit-rate encoding. If enabled, the encoder will try to keep a constant quality by increasing the bit-rate when needed and decrease it when the quality can be assured with a lower bit-rate. The target average bit-rate is the one set byOPUS_ENC_BITRATE. Default:1.
Wanna know how to actually use a networked transmitter? That's in the remotetrx(1) manual page, go read it bestie. 📖
🌈 Multi Transmitter Section 🌈
A multi transmitter section is used if you wanna transmit on multiple transmitters simultaneously. Main character energy, much? ✨ The name of the section can be anything — just point it out from another transmitter specification, like the TX variable in a Logic core configuration.
TYPE— always"Multi"for a multi transmitter section.TRANSMITTERS— a comma separated list of transmitters. Just drop them all in there. 💖
🎀 Module Section 🎀
A module section contain the configuration for a specific module. It have some general configuration variables and some module specific configuration variables. The general ones are listed below, so keep scrolling:
NAME— the name of the module. This name must match the namespace used in the TCL event handling script. If not set,NAMEwill be set to the section name.PLUGIN_NAME— the base name of the plugin. For example, if this configuration variable is set toFoo, the core will look for a plugin calledModuleFoo.so. If not set,PLUGIN_NAMEwill be set to the same value asNAME.ID— specify the module identification number. This is the number used to access the module from the radio interface.TIMEOUT— specify the timeout time, in seconds, after which a module will be automatically deactivated if there has been no activity. Not including this parameter removes the timeout. So like, it can stay on forever, no bedtime. 😴MUTE_LOGIC_LINKING— set to1to mute all logic linking audio when the module is activated or0to keep logic linking unmuted at all times. Default is1(mute).
Module specific configuration variables are described in the man page for that module. The documentation for the Parrot module can for example be found in the ModuleParrot.conf(5) manual page. 🦜
💜 LocationInfo 💜
The LocationInfo configuration section is used to specify information that should be sent into the APRS network and also to the Echolink link status page. The use of location info is activated by setting the LOCATION_INFO configuration variable in the GLOBAL section. The following configuration variables can be used in the LocationInfo configuration section:
STATUS_SERVER_LIST— enter a space separated list of EchoLink status servers that should be used to send node status beacons. Your node information can be found onhttps://www.echolink.org/links.jsp. The format ishost:port. Host — hostname or IP address, port — UDP port. Don't change the default unless you know what you are doing. If you don't want to update the EchoLink status server, comment out this configuration variable.
Example:
STATUS_SERVER_LIST=aprs.echolink.org:5199APRS_SERVER_LIST— this configuration variable specifies connection parameters for connecting to an APRS server network using the TCP protocol. In this case, the positioning information is forwarded to the worldwide APRS network. Have a look athttps://aprs.fi/. 👀
To choose a suitable APRS server from the so called tier 2 network, have a look at https://www.aprs2.net/. Either choose a specific server or one of the regional addresses. The regional addresses bundle all APRS servers within a region so that a random tier 2 server is chosen within the region. There are five regions defined: noam.aprs2.net — North America, euro.aprs2.net — Europe, asia.aprs2.net — Asia, soam.aprs2.net — South America and Africa and aunz.aprs2.net — Australia and New Zealand. The format is a space separated list of host:port entries. Host — hostname or IP address, port — TCP port.
Example:
APRS_SERVER_LIST=euro.aprs2.net:14580FILTER— set the APRS-IS filter expression to use. The filter is used to decide which APRS packets the APRS-IS server should forward to SvxLink. Documentation on filter expressions can be found here:https://www.aprs-is.net/javAPRSFilter.aspx. 🧚
Example:
FILTER=m/10LON_POSITION— the longitude of the station position, entered as"degrees.arcminutes.arcseconds".
Example:
LON_POSITION=09.02.20ELAT_POSITION— the latitude of the station position, entered as"degrees.arcminutes.arcseconds".
Example:
LAT_POSITION=51.02.22NWhere you at on the globe? Now everybody knows. 📍🌍
CALLSIGN 💖
okay bestie, this is your identity out there on the APRS network, so listen up. Drop your callsign in here. And here's the fun part — if you use one of the Echolink prefixes, then an Echolink object and Echolink status get published too. Those prefixes tell the world what kind of station you are: ER- for repeaters, EL- for links. Iconic behavior honestly.
Examples:
CALLSIGN=EL-DL1ABC # callsign for a link
CALLSIGN=DB0ABC-1 # callsign (with SSID 1) for node without
EcholinkSOURCE_CALLSIGN 🦋
This is the callsign you want used as the APRS source address. It absolutely must follow the AX.25 source callsign spec, no exceptions, periodt. If you don't set this variable at all, the callsign just gets pulled straight out of the CALLSIGN config variable — and any EL- or ER- prefix gets stripped off in the process. convenient!
Example:
SOURCE_CALLSIGN=DB0ABC-1LOGIN_CALLSIGN ✨
This one is the callsign used to log in to the APRS-IS network. It has to comply with the APRS-IS specification living at https://www.aprs-is.net/connecting.aspx — go read it, fr fr. If you don't specify this variable, the callsign just ends up being the same as the source callsign. one less thing to think about 💅
Example:
LOGIN_CALLSIGN=DB0ABC-2MFREQUENCY 🎀
The tx-frequency of your link/repeater, in MHz. Heads up: for repeaters you should be reaching for the TX_OFFSET configuration variable to set the repeater shift — don't try to do it here.
Example:
FREQUENCY=430.050 # tx-frequency is 430.050 MHzFREQUENCY_SEPARATOR</SEPARATOR> 🫶
(that heading is just FREQUENCY_SEPARATOR, promise 😭) Use the character you specify here to separate the PHG from the frequency. And why does this exist? Because — tragically — different transceivers understand different APRS formats. Not me having to cater to every radio's little quirks 💀. For example, the Yaesu FTM-510D requires that no separator is used, while the Kenwood TM-D710 requires a separator (like /) to be present. The default is to use a slash as the separator character.
TX_OFFSET 🌸
The tx offset is the number of kHz away from FREQUENCY where your node is listening for other stations. For a repeater, that's the "shift" (e.g. -600). For a simplex node it's most often 0. The limits for the offset are [-9990,+9990] kHz. If you don't specify it, it gets set to 0.
lowkey important: when the APRS packet is actually transmitted, the value is expressed in tens of kHz. So if your configuration parameter is set to-600kHz, it goes out on the air as-060. math is math bestie.
TX_POWER 🔥
The power of your transmitter, in watts.
The maximum power allowed by the APRS protocol is 81 watts, so if you specify a power greater than that, it gets set to that maximum value. But — the advice here is to go ahead and set it to your actual power anyway, in case the protocol evolves to handle higher powers in the future. So if your transmitter outputs 200 watts, set it to that. manifesting bigger numbers ✨
Example:
TX_POWER=10 # tx output is 10 wattsNARROW 💜
Set this configuration variable to 1 and you're telling SvxLink that this node is using narrow band FM, i.e. 12.5 kHz channel spacing. The default is 0, which means a channel spacing of 25kHz. pick your lane 🦋
ANTENNA_GAIN</ANTENNA_GAIN> 🌈
(again — it's just ANTENNA_GAIN, my bad 😭) The gain of your antenna in dBd.
Example:
ANTENNA_GAIN=5 # antenna gain is 5 dBdANTENNA_HEIGHT ⭐
The height of the link-/repeater antenna in meters or feet above the terrain (HAAT) — and to be so clear about this, that is NOT sealevel. ground level only, bestie.
Example:
ANTENNA_HEIGHT=10m # 10 meters above the ground
ANTENNA_HEIGHT=90 # 90 feetANTENNA_DIR 🧚
Main beam direction of the antenna, in degrees. If you're running an omni directional antenna, specify -1 as the direction.
Example:
ANTENNA_DIR=-1 # an omni directional antenna is used
ANTENNA_DIR=128 # main beam direction is 128 degreesPATH 💀
okay this one has rules. When you're connecting to APRS-IS, the best move is to leave this configuration variable commented out so the default gets used (TCPIP*). Only the qAR and qAO constructs may be added to the path. Do not change it unless you really know what you are doing. no cap.
If you're not connecting to APRS-IS, then you might be able to use this config variable to control how your packets get forwarded inside the RF APRS network. In some cases it genuinely has to be changed according to local requirements — go contact your local APRS sysop for more info, they know things. Changes should be made only according to the NEWn-N paradigm. Set it to WIDE1-1 if you're unsure of its setting. But once again — leave it unset if you're not sure that it needs to be set. 🙈
Examples:
PATH=WIDE1-1
PATH=WIDE1-1,WIDE2-2BEACON_INTERVAL ⏰
The interval, in minutes, at which beacons get sent to the APRS network. A good value is 10 minutes. If your beacon is gated via RF in a crowded area, you might need to bump the interval up a bit, to keep the APRS traffic on RF produced by the APRS RF gate as low as possible. Intervals shorter than 10 minutes will be changed to 10. the algorithm said nope 🫶
Example:
BEACON_INTERVAL=20 # APRS-beacons will be sent every 20
minutes.SYMBOL 🎀
Pick which APRS symbol shows up on the maps! Symbols are specified using two characters: the first one determines which symbol table to use, and the second one selects the actual symbol from that table. So for example, /- is a house and /r means a repeater tower. For all the details about APRS symbols, go look at the latest documentation: https://www.aprs.org/symbols/symbolsX.txt. And heads up — the symbol you specify is only applied to the base callsign, not to the Echolink one.
Example:
SYMBOL=/rTONE 🎵
The CTCSS sub-audible tone used for operation over your link or repeater. If you don't use tone control, set it to 0.
Examples:
TONE=136.5 # we are using a CTCSS-tone of 136.5 Hz
TONE=0 # we don't use CTCSS sub-audible or call tones
TONE=1750 # the link/repeater use a tone burst of 1750 HzSTATISTICS_INTERVAL 📊
Defines the interval, in minutes, at which APRS statistics (telemetry) get sent into the APRS network. Range: 5-60 minutes, default is 10 minutes.
STATISTICS_LOGIC 🦋
The name of the logic core that statistics (telemetry) should be sent for. If this configuration variable is not set, telemetry will be sent for all logics. Which will probably lead to unpredictable results 😭 — though honestly it depends on what logic core types are loaded in SvxLink.
Example:
STATISTICS_LOGIC=SimplexLogicCOMMENT 💬
Drop a short comment here — maybe a link to your website, or some info that other people might find interesting. The length must not exceed 36 characters, and it may not contain control characters like "Carriage Return" (\r) or "Line Feed" (\n). Keep your comment as short as you can, so users on a tiny display (TH-D7) get a chance to see the whole comment text. be kind to the small screens 🫶
Example:
COMMENT=SvxLink by SM0SVXPTY_PATH 🔌
Specify a path to a communications PTY that external applications can use to inject APRS packets into the APRS-IS network. And here's the cute bit: a source callsign specified with XXXXXX (that's 6 X:es) will be replaced with the configured source callsign. it's giving ✨automation✨
Example:
PTY_PATH=/dev/shm/locationinfo
$ echo 'XXXXXX>APSVX1,TCPIP*:>Testing SvxLink APRS' > /dev/shm/locationinfoDEBUG 🐛
Set to 1 to print which APRS packets are sent into, or received from, the APRS network. perfect for when you need to see exactly what's happening.
🌈 AUDIO DEVICE SPECIFICATIONS 🌈
The AUDIO_DEV configuration variables specify which audio device to use for a receiver or transmitter. SvxLink supports a number of different audio input and output devices. The format of the configuration variable is "type:dev_spec". There are three different types of audio devices supported: alsa, oss and udp. pick your fighter 💅
alsa— will use the specified Alsa device. Example:"alsa:plughw:0". Describing the format of Alsa device names is outside the scope of this document, so don't ask me bestie 😭.oss— will use the specified OSS audio device. Example:"oss:/dev/dsp". OSS is the old sound system used by Linux. Alsa should be used when possible, fr fr.udp— is not really an audio device, but instead will read and write audio from/to a UDP socket. This can be used to interface SvxLink to all sorts of audio sources/sinks capable of streaming raw audio through UDP. One example usage is to interface SvxLink with GNU Radio. Example:"udp:127.0.0.1:10000". Note however that the only supported format is raw 16 bit signed samples, two interleaved channels. The sampling frequency can be chosen using theCARD_SAMPLE_RATEconfig variable as usual. iconic 🔥
⚡ USING GPIO ⚡
GPIO (General Purpose IO) is used to access hardware pins that are made available, for example, on an embedded system. Before you start using a pin in SvxLink, some setup needs to be done in the operating system. With the standard distribution of SvxLink there's a pair of scripts that help with setting up and taking down the GPIO pins. The scripts are named svxlink_gpio_up and svxlink_gpio_down. The configuration file — which you can find among the other SvxLink configuration files (typically in /etc/svxlink) — is called gpio.conf.
so slay, that's the hardware side handled 🎀
🌸 CALIBRATING THE SIGNAL LEVEL DETECTOR 🌸
Okay bestie, this is the part where we make the signal level detector actually trustworthy. It gets used when you're running multiple receivers, or when you're using the SIGLEV squelch. The voter is the one reading the signal level to pick whichever receiver has the highest signal strength — and it makes that choice right after squelch open. So for the voter to pick right, the signal level detector has to be calibrated on each receiver. Every single one. No skipping. 💅
To roll with the noise signal level detector, first set SIGLEV_DET=NOISE — or, since NOISE is the default, just make sure it's unset. Easy. ✨
There are two config variables doing the calibration work. Both of them live in a local receiver section:
SIGLEV_SLOPE— this is the gain of the detector.SIGLEV_OFFSET— this is the adjustment so that with no input signal at all, the detector comes back with0.
The goal, the dream, the vision: no signal received → value of 0. Full signal strength received → value of 100. It will never be exact, and honestly that's fine, that does not matter — what matters is that every receiver produces a measurement that roughly has the same siglev value as the other receivers for a given signal level. Consistency queen behavior. 👑
Calibration is normally done with the siglevdetcal(1) application. For a correct calibration you need to be able to open the squelch so that only noise comes in. So: disconnect the antenna cable, or use a dummy load.
🚨 WARNING: Before starting the siglevdetcal application, pull the PTT cable — the PTT might get triggered during the calibration procedure. Not cute. Do not let this happen to you. 🙈
The siglevdetcal utility also measures the CTCSS tone SNR offset, so you can set the CTCSS_SNR_OFFSETS configuration variable to a proper value. Two birds, one tool. 🦋
If the siglevdetcal application can't be used for some reason, there's a manual procedure below. Heads up though: this procedure only works for a receiver with unsquelched audio. And 📌 Note: to calibrate a remote receiver, it has to be connected to the SvxLink server — otherwise the squelch will not open.
- Connect a dummy load or disconnect the antenna from the transceiver. If you disconnect the antenna, make sure to also disconnect the PTT.
- Set
SIGLEV_SLOPE=1andSIGLEV_OFFSET=0and restart SvxLink. - Open the squelch so that there is only noise coming into SvxLink.
- Use a second transceiver to make a short, unmodulated transmission. Release the PTT when the
"Squelch OPEN"message is printed. Repeat this for about five times. - Calculate the mean diff (open level - close level) and the mean lower (squelch close) value. Make sure to use at least four significant digits in your calculations.
SIGLEV_SLOPE = 100 / (mean diff)SIGLEV_OFFSET = - (mean lower) * SIGLEV_SLOPE- After changing
SIGLEV_SLOPEandSIGLEV_OFFSET, restart SvxLink and check to see that the squelch open value is now around100and the squelch close value is around0.
🎀 STATE PTY FORMAT 🎀
The format of the output from the state PTY is literally this and nothing else:
<timestamp> <context>:<event name> <event data>and here's what all those little parts mean:
timestamp = <seconds since 1 jan 1970>.<milliseconds>
context = Name of context
event_name = Name of event
event data = Event specific dataAn event must be all on one line, so there must be no line breaks. (The JSON event data in the examples below uses line breaks purely so us humans can read it. Do not come for me.)
Wanna pretty print events that contain JSON formatted event data? Obsessed with this one-liner:
awk '{ print "{\"name\":\"" $2 "\",\"time\":\"" strftime("%c", $1) "\",\"data\":" $3 "}"; fflush() }' /dev/shm/state_pty | jq .Now the specific events that exist. Sit down, there's lore. 🍓
Tx:state
Report the state for a transmitter. The event specific data is a JSON object. Example:
{
"id": "T",
"name": "Tx1",
"transmit": false
}where the different fields mean:
name = Configuration file section name for transmitter
id = The transmitter ID from configuration
transmit = Set to true if the transmitter is transmittingVoter:sql_state
Report the state of all squelches and signal levels for all receivers. The event specific data is a JSON array containing an object for each receiver. Example:
[
{
"name": "Rx1",
"id": "E",
"enabled": true,
"sql_open": true,
"active": true,
"siglev": 59
},
{
"name": "Rx2",
"id": "R",
"enabled": true,
"sql_open": true,
"active": false,
"siglev": 33
},
{
"name": "Rx3",
"id": "D",
"enabled": false
}
]where the different fields mean:
name = Configuration file section name for receiver
id = The receiver ID from configuration
enabled = Set to true if the receiver is enabled
sql_open = Set to true if the squelch is open
active = Set to true if the receiver is the active one,
selected by the voter
siglev = The measured signal level✨ LADSPA PLUGIN USAGE ✨
LADSPA is a framework for sharing pluggable audio components, and bestie there are numerous plugins to choose from. Each plugin has a name (a "label") and zero or more configuration parameters ("control input ports"). Wanna know which plugins are installed on your system? Use the "listplugins" command. Missing some plugin? It may be available to install using your package manager (rpm/yum/dnf, deb/apt etc). Wanna know more about a specific plugin? Use the "analyseplugin" command — e.g. analyseplugin filter hpf. And you can always learn more about the LADSPA framework in their official documentation. 📚
In SvxLink, only plugins that have exactly one audio input and one audio output can be used, so all stereo plugins are excluded, for example. Same energy for input-only or output-only plugins. They're out. 💀
The analyseplugin utility will, among other things, list the ports. All ports typed as "input, control" can be used to configure the plugin. A valid range and a default value may also be listed. The format for the LADSPA_PLUGINS configuration variable in SvxLink is:
"label1:port1:port2:...:portN,label2:port1:port2:...:portN,@MyPlugConfig,..."Note that only control input ports are counted here — so when applying the parameters, any intermingled ports of other types get skipped. 🧚
If an instance config starts with an @-sign, a configuration section with the given name is used to configure the plugin. There must be a LABEL configuration item, and the rest of the configuration variables in that section must match input control port names in the plugin instance specified by LABEL. The config variable names are matched against the beginning of the port names, but they don't have to match the whole name. Close enough counts. 🫶
Example:
LADSPA_PLUGINS=hpf:1000,@Tx1_Compressor
[Tx1_Compressor]
LABEL=tap_dynamics_m
Attack=4
Release=500
Offset Gain=15
Makeup Gain=15
Function=13📁 FILES 📁
/etc/svxlink/svxlink.conf(or deprecated/etc/svxlink.conf) — the system wide configuration file.~/.svxlink/svxlink.conf— per user configuration file./etc/svxlink/svxlink.d/*— additional configuration files. Typically one configuration file per module.
👑 AUTHOR 👑
Tobias Blomberg (SM0SVX) <sm0svx at svxlink dot org>
🐛 REPORTING BUGS 🐛
Bugs should be reported using the issue tracker at https://github.com/sm0svx/svxlink.
Questions about SvxLink should not be asked using the issue tracker. Instead use the group set up for this purpose at groups.io: https://groups.io/g/svxlink
🦋 SEE ALSO 🦋
svxlink(1), remotetrx(1), siglevdetcal(1), devcal(1)
and that's a wrap on the whole SVXLINK.CONF(5) page, bestie!! 🎉 you made it to the end, main character energy fr fr 💖 this page is from the Linux manual, dated MAY 2026, and it's SVXLINK.CONF(5) — go forth, configure fearlessly, and remember: calibrate your receivers, pull that PTT cable, and slay. periodt. 💅✨
📦 where this page comes from
- ubuntu stonking: svxlink-server 26.05.1-1 · GPL-2.0-or-later
- 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms