|
|
| |
SVXLINK.CONF(5) |
File Formats |
SVXLINK.CONF(5) |
svxlink.conf - Configuration file for the SvxLink server
svxlink is a general purpose voice service system for ham radio use. This
man-page describe the SvxLink server configuration file format.
SvxLink look for configuration files in a number of places. First
it try to find a user specific configuration file. SvxLink will look for a
user specific configuration file in: $HOME/.svxlink/svxlink.conf. If
no user specific configuration file can be found, SvxLink will look for the
system wide configuration file /etc/svxlink/svxlink.conf. The
--config command line option may also be used to specify an arbitrary
configuration file.
The configuration file is in the famous INI-file format. A generic example of
how such a file might look like is shown below.
[SECTION1]
VALUE1=1
VALUE2="TWO "
VAULE3="Multi "
"line"
[SECTION2]
VALUE1=2
This is a simple format that contain name=value pairs that belong
to a section. In written text, a specific configuration variable can be
referred to as SECTION1/VALUE2 meaning "configuration variable VALUE2
in section SECTION1".
The same variable name can exist in two different sections. For
example VALUE1 in section SECTION1 have the value 1 and VALUE1 in section
SECTION2 have the value 2. Values containing spaces at the beginning or end
of the line must be surrounded by citation characters (see SECTION1/VALUE2).
Likewise with a multi line value (see SECTION1/VALUE3).
Here is the description of all configuration variables that SvxLink understands.
The configuration variables are described section for section.
The GLOBAL section contains application global configuration data.
- 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
depend on the architecture but typically on a x86_64 system it is
/usr/local/lib64/svxlink. Leaving this variable unset should work in most
cases.
- 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 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 contain 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.
- 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. 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)
The last one (%f) is a SvxLink specific formatting specifier.
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".
- CARD_SAMPLE_RATE
- This configuration variable determines the sampling rate used for audio
input/output. SvxLink always work 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.
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.
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.
- 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.
- LINKS
- Enter here a comma separated list of section names that contains the
configuration information for linking logics together (see Logic
Linking).
A logic core is what define 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. The configuration variables below are common to all
logic types. Configuration variables that are specific to a certain logic core
type are described below in a section of its own.
- TYPE
- The type of logic core this is. The documentation for the specific logic
core type you want to use describe what to write here.
- 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.
- 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.
- 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.
- TIME_FORMAT
- Specify what format the time should be announced as, valid options are
"12"/"24". NOTE: may not work for all language
packs
- SHORT_IDENT_INTERVAL
- The number of minutes between short identifications. The purpose of the
short identification is to just announce that the station is on the air.
Typically just the callsign is transmitted. For a repeater a good value is
ten minutes and for a simplex node one time every 60 minutes is probably
enough. The LONG_IDENT_INTERVAL must be an even multiple of the
SHORT_IDENT_INTERVAL so if LONG_IDENT_INTERVAL is 60 then the legal values
for SHORT_IDENT_INTERVAL are: 1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, 60. If
unset or set to 0, disable short identifications.
- LONG_IDENT_INTERVAL
- The number of minutes between long identifications. The purpose of the
long identification is to transmit some more information about the station
status (new voice mails etc). The time of day is also transmitted. A good
value here is 60 minutes. If unset or set to 0, disable long
identifications.
- IDENT_ONLY_AFTER_TX
- This feature controls when identification is done. By default,
identification is done every time the SHORT_IDENT_INTERVAL expires. If
this feature is enabled, identification will be done only if there has
been a recent transmission. This feature is good for nodes using an RF
link to provide echolink to a repeater. Often, in this situation, it is
not desirable for the link to identify unless legally necessary. Note that
SHORT_IDENT_INTERVAL still have to be set for this feature to work. That
config variable will then be interpreted as the minimum number of seconds
between identifications. The LONG_IDENT_INTERVAL will not be affected by
this parameter.
- 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 the need to send the #
character. To disable this feature, either comment out the configuration
row or set it to a value less or equal to zero.
- EVENT_HANDLER
- Point out the TCL event handler script to use. The TCL event handler
script is responsible for playing the correct audio clips when an event
occur. The default location is
/usr/local/share/doc/svxlink/events.tcl.
- DEFAULT_LANG
- Set the default language to use for announcements. It should be set to an
ISO code (e.g. sv_SE for Swedish). 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 commenting out this line. Often it is best to use the
SQL_HANGTIME receiver configuration variable to specify a delay instead of
specifying a delay here. This configuration variable should then be set to
0.
- REPORT_CTCSS
- If set, will report the specified CTCSS frequency upon manual
identification (* pressed). It is possible to specify fractions using
"." as decimal comma. Disable this feature by commenting out (#)
this configuration variable.
- TX_CTCSS
- This configuration variable controls if a CTCSS tone should be
transmitted. Use a comma separated list (no spaces!) to specify when to
transmit a CTCSS tone. These are the possible values: SQL_OPEN,
LOGIC, MODULE, ANNOUNCEMENT or ALWAYS.
Commenting out this configuration variable will disable CTCSS transmit.
The tone frequency and level is configured in the transmitter
configuration section.
- 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.
- ALWAYS will always transmit a CTCSS tone as soon as the transmitter
is turned on.
- 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.
- 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.
- 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 is other traffic
present.
- 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, 81 will activate the
recorder and 80 will deactivate it. The command may also be left out. It
will then not be possible to control the QSO recorder using DTMF commands.
Even if the command is left out the colon must always be specified. The
config section point 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,03499 then
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.
- 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. 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. No other commands than the online command will be accepted in the
offline state.
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".
- STATE_PTY
- Using this configuration variable it is possible to specify a path to a
UNIX 98 PTY that SvxLink state events is published to. The published
events is in a simple text format using a space separated list of values.
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. 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 is 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 a
echo '*1#' > /path/to/pty after starting SvxLink. The device
works bidirectional, received dtmf characters (from Rf) are output via
this interface.
Example: DTMF_CTRL_PTY=/dev/shm/dtmf_ctrl
The Simplex Logic section contains 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. The name
"SimplexLogic" is not magic. It could be called what ever you like
but it must match the namespace name in the SimplexLogic.tcl script. The
configuration variables below are those that are specific for a simplex logic
core.
- TYPE
- The type for a simplex logic core is always Simplex.
- MUTE_RX_ON_TX
- Set to 1 to mute the receiver when the transmitter is transmitting
(default) or set it to 0 to make the RX active during transmissions. One
might want to set this to 0 if the link is operating on a split frequency.
Then the link can accept commands even when it's transmitting. The normal
setting is 1, to mute the RX when transmitting.
- MUTE_TX_ON_RX
- Set to 1 to mute the transmitter when the squelch is open (default) or set
it to 0 to make the TX active during squelch open. One might want to set
this to 0 if the link is operating on a split frequency or if it's
connected to some full duplex device. The normal setting is 1, to mute the
TX when the squelch is open.
- RGR_SOUND_ALWAYS
- Set to 1 to always send roger sound after squelch close, even when no
module is active.
A Repeater Logic section contains configuration data for a repeater logic core.
The name of the section, which in the example configuration file is
RepeaterLogic, must have a corresponding list item in the GLOBAL/LOGICS
config variable for this logic core to be activated. The name
"RepeaterLogic" is not magic. It could be called what ever you like
but it must match the namespace name in the RepeaterLogic.tcl script. The
configuration variables below are those that are specific for a repeater logic
core.
- TYPE
- The type for a repeater logic core is always Repeater.
- NO_REPEAT
- Set this to 1 if you do NOT want SvxLink to play back the incoming audio.
This can be used when the received audio is directly coupled by hardware
wiring to the transmitter. What you win by doing this is that there is
zero delay on the repeated audio. When the audio is routed through SvxLink
there is always an amount of delay. What you loose by doing this is the
audio processing done by SvxLink (e.g. filtering, DTMF muting, squelch
tail elimination) and the ability to use remote receivers.
- IDLE_TIMEOUT
- The number of seconds the repeater should have been idle before turning
the transmitter off.
- OPEN_ON_1750
- Use this configuration variable 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 that the
time specified is long enough for the squelch to have time to open.
Otherwise the repeater will open "too soon" and you will hear an
ugly 1750Hz beep as the first thing. A value of 0 will disable 1750 Hz
repeater opening.
- OPEN_ON_CTCSS
- Use this configuration variable if it should be possible to open the
repeater with a CTCSS tone (PL). The syntax of the value is
tone_fq:min_length. The tone frequency is specified in whole Hz and the
minimum tone length is specified in milliseconds. For examples if a 136.5
Hz tone must be asserted for two seconds for the repeater to open, the
value 136:2000 should be specified.
- OPEN_ON_DTMF
- Use this configuration variable 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 configuration variable if you want to open your repeater by using
a selective tone call that is often used in commercial radio networks.
Example: OPEN_ON_SEL5=03345 opens your repeater only if that sequence has
been received. You can use sequence lengths from 4 to 25.
- CLOSE_ON_SEL5
- Use this configuration variable if you want to close your repeater by
using a selective tone call that is often used in commercial radio
networks. Example: CLOSE_ON_SEL5=03345 closes your repeater if that
sequence has been received. You can use sequence lengths from 4 to
25.
- OPEN_ON_SQL
- Use this configuration variable 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 if OPEN_ON_SQL and OPEN_ON_CTCSS should activate the repeater
when the squelch open or close. If set to OPEN, the repeater will activate
and start retransmitting audio immediately. No identification will be
sent. If set to CLOSE, the repeater will not activate until the squelch
close. 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 of 0 disables 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 open the squelch by short bursts.
This configuration variable is used to specify the minimum time, in
milliseconds, that a transmission must last to be classified as a real
transmission. A good value is in between 500-2000ms.
- SQL_FLAP_SUP_MAX_COUNT
- Flapping squelch suppression is used to close the repeater down if there
is interference on the frequency that open the squelch by short bursts.
This configuration variable is used to specify the maximum number of
consecutive short squelch openings allowed before shutting the repeater
down. A good value is in between 5-10.
- ACTIVATE_MODULE_ON_LONG_CMD
- This configuration variable activate a feature that might help users not
aware of the SvxLink command structure. The idea is to activate the
specified module when a long enough command has been received. The typical
example is an EchoLink user that is used to just typing in the node ID and
then the connection should 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 with
EXEC_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.
- IDENT_NAG_TIMEOUT
- Tell repeater users that are not 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 the IDENT_NAG_MIN_TIME configuration variable. We don't know if it's
really an identification but it's the best we can do. Setting it to 0 or
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. This is used as described in the
IDENT_NAG_TIMEOUT configuration variable.
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. More than one logic core can be connected.
- TYPE
- The type for a reflector logic core is always Reflector.
- HOST
- The hostname or IP address of the reflector server.
- PORT
- The TCP/UDP port number used by the server. The client do 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.
- JITTER_BUFFER_DELAY
- A jitter buffer is used to prevent gaps in the audio when the network
connection do not 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.
It is also possible to set audio codec parameters using the same
configuration variables as 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.
The QSO recorder is used to record all received audio to files on disk. All
audio from receivers, modules and logic links are recorded. Announcements are
not recorded.
- REC_DIR
- Use this configuration variable to specify in which directory to write the
audio files. A good place is /var/spool/svxlink/qso_recorder.
- MIN_TIME
- If the duration of the recorded content for a file is less then MIN_TIME
milliseconds, the file will be deleted when the file is closed. Default: 0
(empty files will be deleted).
- MAX_TIME
- Setting this configuration variable will set an upper limit for the file
size of a recording. No more than MAX_TIME seconds of content will be
recorded to a single file. When the maximum time have been reached, the
file is closed and another file is created. Note that it is not the
maximum time that the recording has been active that we are setting a
limit for but rather how much content that have been recorded to the file.
If nothing is recorded, the file can stay open indefinitely. Default: 0
(no limit)
- SOFT_TIME
- To not get abrupt breaks in recordings it is possible to set a soft break
time. Let's say that MAX_TIME is set to 3600 seconds (one hour). If we set
SOFT_TIME to 300 seconds (five minutes) the QSO recorder try to close the
file on a squelch close somewhere between 55 and 60 minutes. In this way
we may avoid getting transmissions 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 is exceeded, the oldest files are deleted. The
directory size is checked upon file close so the size may grow temporarily
past the limit with at most the size of one recorded file. Only files
which have a filename starting with "qsorec_" will be considered
for deletion. If using an ENCODING_CMD, make sure that the
"qsorec_" prefix is not removed from the target filename unless
you really want the MAX_DIRSIZE feature to skip them. Default: 0 (no
limit)
- DEFAULT_ACTIVE
- If this configuration variable is set to 1, the QSO recorder will be
activated by default when SvxLink start. Default: 0 (default
inactive)
- TIMEOUT
- If a timeout is specified, the activation state of the QSO recorder will
return to the value specified in the DEFAULT_ACTIVE configuration variable
when the node has been idle for the specified number of seconds. When
DEFAULT_ACTIVE is unset or 0, if the QSO recorder is manually activated it
will be automatically deactivated after the specified amount of time of
inactivity. When DEFAULT_ACTIVE is set to 1, if the QSO recorder is
manually deactivated it will be automatically activated after the
specified amount of time of inactivity. Default: 0 (no timeout)
- QSO_TIMEOUT
- Set this configuration variable if you want to close the currently opened
file and open a new one after each QSO. The number of seconds the node
should be idle before closing the file should be specified. Default: 0 (no
QSO timeout)
- ENCODER_CMD
- Specify a command to be executed after a new wav file have been written to
disk. This makes it possible to use an external encoder utility to encode
the wav file to another format. Even though this configuration variable
was added to run an external encoder it could do more complicated things
with the file if needed. A couple of examples would be to transfer the
file to another computer or to send a notification e-mail. If the command
line get too complicated it may be a good idea to write a script instead.
The encoder command will be run under a shell so normal shell
operators like redirects and pipes may be used. The shell specified in
the SHELL environment variable will be used and if not set, /bin/sh will
be used. The "-c" command line option will be added so the
complete command will look something like: $SHELL -c
"$ENCODER_CMD". A number of %-codes can be included in the
command. They have the following meaning:
- %f - The full filename with full path
- %d - The directory part (what REC_DIR is set to)
- %b - The basename, that is, the filename without path and
extension
- %n - The filename without path but with extension
The encoder will be started in the background and it will not be
stopped even if SvxLink exits. It will run in the background until it's
done. As long as SvxLink is running it is monitoring the encoding processes.
If a process run for longer than one hour it will be killed.
Note that SvxLink will never remove the original recording so that
have to be done in the encoder command. Here are a couple of examples:
ENCODER_CMD=/usr/local/bin/oggenc -Q \"%f\" && rm
\"%f\"
ENCODER_CMD=/usr/local/bin/lame --quiet \"%f\"
\"%d/%b.mp3\" && rm \"%f\"
ENCODER_CMD=/usr/local/bin/speexenc \"%f\" \"%d/%b.spx\"
2>/dev/null && rm \"%f\"
ENCODER_CMD=/usr/local/bin/opusenc \"%f\" \"%d/%b.opus\"
2>/dev/null && rm \"%f\"
A macros section is used to declare macros that can be used by a logic core. The
logic core points out the macros section to use by using the MACROS
configuration variable. The name of the MACROS section can be chosen
arbitrarily as long as it match the MACROS configuration variable in the logic
core configuration section. There could for example exist both a
[RepeaterLogicMacros] and a [SimplexLogicMacros] section.
A macro is a kind of shortcut that can be used to decrease the
amount of key presses that have to be done 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 the example below. Note that the module name is case
sensitive.
[Macros]
1=EchoLink:9999#
2=EchoLink:1234567#
9=Parrot:0123456789#
For example, pressing DTMF sequence "D1#" will activate
the EchoLink module and connect to the EchoTest conference node.
A logic linking configuration section is used to specify information for a link
between two or more SvxLink logic cores. Such a link can for example be used
to connect a local repeater to a remote repeater using a separate link
transceiver. The link is activated/deactivated using DTMF commands and/or
automatically depending on your configuration. When the link is active, all
audio received by one logic will be transmitted by the other logic(s).
The name of the logic linking section can be chosen freely. In the
example configuration file, there is a section [LinkToR4]. To use a logic
linking section in a logic core it must be pointed out by the LINKS
configuration variable in the GLOBAL section. Example:
GLOBAL/LINKS=LinkToR4
- CONNECT_LOGICS
- A comma separated list of logic specifications for the logic cores to
connect together. Each logic specification has three parts separated by
colons: <logic name>:<command>:<announcement name>. The
"logic name" is the name of the logic to include in the link. To
manually activate or deactivate the link from the just specified logic,
"command" is used. The "announcement name" is used
when announcing link related activities like activation or deactivation.
Both "command" and "announcement name" may be left
empty if no manual control is wanted. An example config line may look like
this:
RepeaterLogic_2m:99:SK3GW,RepeaterLogic_70cm:94:SK3GK
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 send command 991 and deactivated when the user send 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".
- 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. The time is specified by setting the TIMEOUT
configuration variable. If the TIMEOUT variable is not set, no automatic
reactivation will be done.
- 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.
- AUTOACTIVATE_ON_SQL
- Enter a comma separated list of logics, which should automatically
activate the link if there is activity (e.g. squelch open) 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:
AUTOACTIVATE_ON_SQL=MicSpkrLogic
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.
- TYPE
- Always "Local" for a local receiver.
- RX_ID
- A single char uniquely identifying this receiver. The RX identity can for
example be used in the TCL event scripts to get different rogers sounds
for different receivers when using a receiver voter.
- AUDIO_DEV
- Specify the audio device to use. Normally oss:/dev/dsp. 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.
- SQL_DET
- Specify the type of squelch detector to use. Possible values are: VOX,
CTCSS, SERIAL, EVDEV, SIGLEV, PTY, GPIO or HIDRAW.
The VOX squelch detector determines if there is a signal
present by calculating a mean value of the sound samples. The VOX
squelch detector behavior is adjusted with VOX_FILTER_DEPTH and
VOX_THRESH. VOX is actually a bit of a misnomer since it's a "Voice
Operated Squelch" and VOX actually means "Voice Operated
Transmitter". However, the term VOX is widely understood by hams
all over the world so we'll stick with it.
The CTCSS squelch detector checks for the presence of a tone
with the specified frequency. The tone frequency is specified using the
CTCSS_FQ config variable. The thresholds are specified using the
CTCSS_OPEN_THRESH and CTCSS_CLOSE_THRESH config variables. Other config
variables that effect the CTCSS squelch is: CTCSS_MODE,
CTCSS_SNR_OFFSET, CTCSS_BPF_LOW, CTCSS_BPF_HIGH.
The SERIAL squelch 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 with SERIAL_PORT and
SERIAL_PIN.
The EVDEV squelch detector read squelch events from a
/dev/input/eventX device. 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/input device node to use using the EVDEV_DEVNAME config variable.
Set which events that should open and close the squelch using the
EVDEV_OPEN and EVDEV_CLOSE config variables.
The GPIO squelch detector read a pin on the GPIO Port.
Depending on the level of the pin, the squelch is switched. A HIGH
(3.3V) at the pin set the squelch to open and a LOW (GND) level will set
the squelch to closed. Specify which squelch pin to use with the
GPIO_SQL_PIN configuration variable. On some devices, like the Orange
Pi, you also need to set the GPIO_PATH configuration variable.
The SIGLEV squelch 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 the SIGLEV_DET configuration
variable. The open and close thresholds are set using the
SIGLEV_OPEN_THRESH and SIGLEV_CLOSE_THRESH configuration 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 PTY squelch 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 using PTY_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 for nhrcx.pl or
trx_pty_ctrl.py for an example. It is possible to specify the same PTY
for 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 HIDRAW squelch supports human interface devices (HID), USB
devices like CM108 soundcard e.g. used in the URI Echolink adapter made
by DMK.
- 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
- How long, in milliseconds, the squelch will stay open after the detector
has indicated that it is closed. This configuration variable will affect
all squelch detector types.
- SQL_EXTENDED_HANGTIME
- At low signal strengths it can be beneficial to use a longer squelch
hangtime so that it is less likely for the squelch to close. This
configuration variable is unset by default. A value of 1000 milliseconds
may be a good value to start out with. To enable the extended squelch
hangtime feature, set up the SQL_EXTENDED_HANGTIME_THRESH variable.
- SQL_EXTENDED_HANGTIME_THRESH
- At low signal strengths it can be beneficial to use a longer squelch
hangtime so that it is less likely for the squelch to close. This
configuration variable is unset by default. When set to a signal level it
will activate the extended squelch hangtime feature. When the signal
strength during a transmission fall below the set threshold, the extended
hangtime will be used. Start out with a value between 10 to 15. The
SQL_EXTENDED_HANGTIME variable is used to set how long the extended
squelch hangtime should be. Make sure that you have calibrated the signal
level detector before turning this feature on. Otherwise it will not work
as expected.
- SQL_TIMEOUT
- Use this configuration variable to set an upper limit, in seconds, for how
long the squelch is allowed to be open. If the timeout value is exceeded
the squelch is forced to closed. If the squelch close for real, everything
is back to normal. When it opens the next time a squelch open will be
signaled. For example, use this feature to make sure that a faulty
receiver cannot block the system indefinitely.
- 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.
- VOX_THRESH
- The threshold that the mean value of the samples must exceed for the
squelch to be considered open. It's hard to say what is a good value.
Something around 1000 is probably a good value. Set it as low as possible
without getting the vox to false trigger.
- CTCSS_MODE
- This configuration variable set the CTCSS detection method used. These are
the ones to choose from:
- 0 (Default) Will choose the detection mode that is the default in
the software. At the moment this is the "Estimated SNR"
mode.
- 1 (Neighbor bins) This detection mode will use three narrow
frequency bands (~8Hz) to do the detection. One band is centered around
the tone to be detected and then there are one band above and one below
the tone. These bands are used to estimate the noise floor. This is the
detector that have been used in SvxLink for a long time. It is however
rather slow with its detection time of about 450ms. There is no good
reason to use this detector anymore but it is kept in case the new
detector does not work for some hardware setup.
- 2 (Estimated SNR) This is a newer detector implementation which
have some improvements. The most notable difference is that it is faster.
The mean detection time will be around 200ms. This is the default
detection mode if not specified. This detector will use a larger passband
to estimate the noise floor which make it more stable. The default config
use the whole CTCSS passband but this can be customized using the
CTCSS_BPF_LOW and CTCSS_BPF_HIGH config variables.
- 3 (Estimated SNR+Phase) This detector is a bit experimental. It is
even faster and more narrow than the other detection modes. The mean
detection time will be something like 150ms. 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 is it a bit less
sensitive.
- 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.
- 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 or 3 it is helpful to set up the CTCSS_SNR_OFFSET 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 or 3 it is helpful to set up the CTCSS_SNR_OFFSET config
variable. This will make the SNR estimation pretty good. Default threshold
is 9dB.
- CTCSS_SNR_OFFSET
- This config variable is used when CTCSS_MODE is set to 0, 2 or 3. It will
adjust the estimated SNR value so that it becomes 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.
- CTCSS_BPF_LOW
- When CTCSS_MODE is set to 0, 2 or 3, 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 or 3, 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.
- 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/ttyu0
- SERIAL_PIN
- If SQL_DET is set to SERIAL, this config variable determines which pin in
the serial port that should be used for hardware squelch input (COS -
Carrier Operated Squelch). It is possible to use the DCD, CTS, DSR or RI
pin. If inverted operation is desired, prefix the pin name with an
exclamation mark (!).
Example: SQL_PIN=!CTS
- SERIAL_SET_PINS
- Set the specified serial port pins to a static state. This can be good if
using a pin for reference voltage or if a pin have to be in a certain
state to not interfere with the operation of some equipment. There are two
pins that are possible to use, RTS and DTR. If prefixed with an
exclamation mark (!), the pin will be cleared and if not it will be set.
Example: SERIAL_SET_PINS=RTS!DTR will set RTS and clear
DTR.
- EVDEV_DEVNAME
- Specify which /dev/input device node to use for the EVDEV squelch
detector. To find out which device node and event codes to use, install
the evtest utility. Find a candidate device node under /dev/input/ or
/dev/input/by-id/ and try the evtest utility on it. Press some keys on the
device you want to read events from. If you're in luck, events will be
printed on the screen.
- EVDEV_OPEN
- Use the evtest utility, as described above, to find out type, code and
value for the event you want to use to open the squelch. For example if
type is 1, code is 163 and value is 1, set this config variable to
1,163,1.
- EVDEV_CLOSE
- Use the evtest utility, as described above, to find out type, code and
value for the event you want to use to close the squelch. For example if
type is 1, code is 163 and value is 0, set this config variable to
1,163,0. If you set the same type,code,value combination for both
EVDEV_OPEN and EVDEV_CLOSE, that event will toggle the squelch.
- GPIO_PATH
- Use this configuration variable to set the path to the sys control devices
for GPIO. This normally is /sys/class/gpio but on some hardware, like the
Orange Pi, the path is /sys/class/gpio_sw.
- GPIO_SQL_PIN
- If SQL_DET is set to GPIO this configuration variable is used to choose
which GPIO pin to use for squelch input. The most common name is
gpio<number>, like gpio4. Some GPIO drivers use more complex names,
like gpio33_pe11. If inverted operation is desired, prefix the pin name
with an exclamation mark (!).
Example: GPIO_SQL_PIN=!gpio4
- SIGLEV_DET
- Choose which type of signal level detector to use. The available choices
are: "NONE", "NOISE", "TONE",
"AFSK" or "SIM". Depending on other configuration
there may be 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 using multiple receivers in a voter
configuration or when using the SIGLEV squelch type.
Type NONE disable the signal level detector. This may be used
if no signal level detector is needed.
Type NOISE use a bandpass filter in the range of 5 - 5.5kHz
(CARD_SAMPLE_RATE >= 16000) or a high-pass filter at 3.5kHz
(CARD_SAMPLE_RATE = 8000) to estimate the amount of noise present on the
signal. If the passband contain a small amount of energy, a strong
signal is assumed. If the passband contain more energy, a weaker signal
is assumed. The noise detector must be calibrated for the receiver and
audio levels you use. This is done using the SIGLEV_SLOPE and
SIGLEV_OFFSET configuration variables. See chapter CALIBRATING THE
SIGNAL LEVEL DETECTOR below for more information.
Type TONE is not really a signal level detector 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 is using
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 have 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 the TONE_SIGLEV_MAP
configuration variable to map each tone to a corresponding signal level
value in between 0 - 100.
Type AFSK is like the TONE detector 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 enebled by setting
OB_AFSK_ENABLE=1 and also optionally IB_AFSK_ENABLE=1.
Type SIM is a simulated signal level detector that can be used
to debug problems in the SvxLink software. Use the SIGLEV_MIN,
SIGLEV_MAX, SIGLEV_DEFAULT, SIGLEV_TOGGLE_INTERVAL and
SIGLEV_RAND_INTERVAL configuration variables to configure the
simulator.
- 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 chapter CALIBRATING
THE SIGNAL LEVEL DETECTOR below for more information.
- SIGLEV_OFFSET
- The offset of the signal level detector. See chapter CALIBRATING THE
SIGNAL LEVEL DETECTOR below for more information.
- SIGLEV_BOGUS_THRESH
- This configuration variable set an upper threshold for the estimated
signal level when using the noise signal level detector. If the estimation
goes over the given threshold, a signal level of 0 will be reported. This
can be used as a workaround when using a receiver with squelched audio
output. When the squelch is closed, the receiver audio is silent. The
signal level estimator will interpret this as a very strong signal.
Setting up the bogus signal level threshold will counteract this behavior
but a better solution is to use unsquelched audio if possible.
By default this feature is disabled. If enabling it, start
with a value somewhere around 120.
- TONE_SIGLEV_MAP
- This configuration variable is used to map tones to signal level values
when SIGLEV_DET=TONE. It is a comma separated list of ten values in the 0
- 100 range. The first value map to the 5500Hz tone, the second to the
5600Hz tone and so on. The last value map to the 6400Hz tone. What levels
the tones should be mapped to depends on the tone sender implementation.
The default tone map is 10,20,30...,100.
The Atmel AVR processor used by the author have a reverse
mapping so that the first tone (5500Hz) indicate the highest signal
strength and the last tone (6400Hz) indicate the lowest signal strength.
It is also not linear since it's more important to have fine measurement
granularity in the lower signal strength range. This is how the mapping
look for the AVR: 100,84,60,50,37,32,28,23,19,8.
- SIGLEV_OPEN_THRESH
- This is the squelch open threshold for the SIGLEV squelch detector. If
using the NOISE signal level detector, make sure to first calibrate the
signal level detector using the SIGLEV_SLOPE and SIGLEV_OFFSET
configuration variables. The signal level detector should normally be
calibrated so that full signal strength is 100 and no signal is 0.
Depending on your background noise level a good value for this
configuration variable is between 5 and 20.
- SIGLEV_CLOSE_THRESH
- This is the squelch close threshold for the SIGLEV squelch detector. If
using the NOISE signal level detector, make sure to first calibrate the
signal level detector using the SIGLEV_SLOPE and SIGLEV_OFFSET
configuration variables. The signal level detector should normally be
calibrated so that full signal strength is 100 and no signal is 0.
Depending on your background noise level a good value for this
configuration variable is between 1 and 10.
- SIGLEV_MIN
- The minimum signal level used by SIM signal level detector.
- SIGLEV_MAX
- The maximum signal level used by 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 will use
to toggle between the maximum and the minimum signal levels.
- SIGLEV_RAND_INTERVAL
- The interval, in milliseconds, that the SIM signal level detector will use
between randomizing a new signal level value. At each interval, the
simulator will randomly either increase or decrease the signal level with
one step.
- DEEMPHASIS
- Apply a deemphasis filter on received audio. The deemphasis filter is used
when taking audio directly from the detector in the receiver, like when
using a 9k6 packet radio connector. If not using a deemphasis filter the
high frequencies will be amplified resulting in a very bright (tinny)
sound.
- SQL_TAIL_ELIM
- Squelch tail elimination is used to remove noise from the end of a
received transmission. This is of most use when using CTCSS or SIGLEV
squelch with unsquelched input audio. A normal value is a couple of
hundred milliseconds. Note that the audio will be delayed by the same
amount of milliseconds. This does not matter much for a simplex link but
for a repeater the delay might be annoying since you risk hearing the end
of your own transmission.
- PREAMP
- The incoming signal will be amplified by the specified number of dB. This
can be used as a last measure if the input audio level can't be set high
enough on the analogue side. A value of 6dB will double the signal level.
Note that this is a digital amplification. Hence it will reduce the
dynamic range of the signal so usage should be avoided if possible. It's
always better to correct the audio level before sampling it.
- PEAK_METER
- This is a help to adjust the incoming audio level. If enabled it will
output a message when distortion occurs. To adjust the audio level, first
open the squelch. Then increase the audio level until warning messages are
printed. Decrease the audio level until no warning messages are printed.
After the adjustment has been done, the peak meter can be disabled.
0=disabled, 1=enabled.
- DTMF_DEC_TYPE
- Specify the DTMF decoder type. Set it to INTERNAL to use the
internal software DTMF decoder. To use the S54S interface featuring a
hardware DTMF decoder, set it to S54S. To control it over a pseudo
tty device set it to PTY. Setting it to PTY will install the PTY
dtmf decoder. SvxLink creates a symlink linked to a slave pty device on
runtime. The name has to be defined with DTMF_PTY. If AFSK reception is
enabled using OB_AFSK_ENABLE/IB_AFSK_ENABLE, remotely decoded DTMF digits
may be received by setting this configuration variable to AFSK.
NONE or commenting it out will disable DTMF detection.
- DTMF_MUTING
- Mute the audio during the time when a DTMF digit is being received. Note
that the audio will be delayed 75ms to give the DTMF detector time to do
its work. This does not matter much on a simplex link but on a repeater it
could be annoying since you will hear the last 75 milliseconds of your own
transmission. To counteract the added delay one can set up the
SQL_TAIL_ELIM configuration variable to at least 75 milliseconds. Legal
values for DTMF_MUTING are 0=disabled, 1=enabled.
- DTMF_HANGTIME
- This configuration variable can be used if the DTMF decoder is too quick
to indicate digit idle. That does not matter at high signal strengths but
for weaker signals and mobile flutter it's not good at all. Each DTMF
digit will be detected multiple times. Using this configuration variable,
the time (ms) a tone must be missing to be indicated as off can be
extended. Setting this value too high will cause the decoder to be a bit
sluggish and it might consider two digits as one. The hang time only
affect 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 is considered as a new one.
A good default value is 50-100ms.
- DTMF_SERIAL
- When using an external hardware DTMF decoder this config variable is used
to specify a serial port (e.g. /dev/ttyu0).
- DTMF_PTY
- When using the PTY DTMF "decoder" this configuration variable
will set the path to the PTY slave softlink that the external interface
script use to communicate 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 tell 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.
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 is one script handling all functions.
Example: /tmp/rx1_dtmf.
- DTMF_MAX_FWD_TWIST
- DTMF use two tones to encode digits 0-9, A-F. These two tones should
normally have the sample 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, 8dB
forward twist should be allowed. Some transmitters do not correctly
modulate the DTMF tones to get zero twist. The most common situation is
that the forward twist is too large. Increasing this configuration
variable above 8dB might allow DTMF from these transmitters to be
detected. When doing this, the DTMF detector will be more sensitive to
noise and might cause more false triggers.
- DTMF_MAX_REV_TWIST
- DTMF use two tones to encode digits 0-9, A-F. These two tones should
normally have the sample amplitude. The difference in amplitude is called
twist. Reverse twist is when the lower frequency tone is lower in
amplitude than the higher frequency tone. According to the standards, 4dB
reverse twist should be allowed but SvxLink will allow 6dB by default. The
most common reason for getting reverse twist is a bad de-emphasis filter
or that none at all is used, like when taking audio directly from the FM
discriminator. Have a look at the DEEMPHASIS configuration variable before
starting to modify this configuration variable.
- DTMF_DEBUG
- Set to 1 to continuously print software DTMF decoder decision parameters.
This should only be used for a short while to pinpoint problems with the
DTMF decoding since it will print one row of analysis parameters 100 times
per second. The following parameters are printed.
- pwr - The power in the audio signal. Must be over about -50dB.
- q - Quality. Should be close to 1.00 for a good detection. If the
signal is strong but the value is low anyway, the signal probably is
distorted for some reason. The input audio level may be too high for
example.
- twist - The amplitude difference between the two tones. Should be
around 0dB, which means the tones should ideally be of the same strength.
By default, values between -6dB to +8dB are accepted but the thresholds
can be set using the DTMF_MAX_FWD_TWIST and DTMF_MAX_REV_TWIST
configuration 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 relation to its third overtone. Should be
close to zero. If it's not, the signal is probably distorted.
- im - The relation of the two tones to their intermodulation
product. Should be close to zero. If it's not, the signal is probably
distorted.
- 1750_MUTING
- Mute the audio during a call tone of 1750Hz is received. Note that the
audio will be delayed 75ms to give the tone detector time to do its work.
This does not matter much on a simplex link but on a repeater it could be
annoying since you will hear the last 75 milliseconds of your own
transmission. To counteract the added delay one 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
- Define here your selective tone call system. You have the choice of the
following types: ZVEI1, ZVEI2, ZVEI3, PZVEI, PDZVEI, DZVEI, CCITT, EEA,
CCIR1, CCIR2, NATEL, EURO, VDEW, AUTO-A, MODAT, PCCIR and EIA. Only one
system can be used at the same time. Please take into consideration that
some Sel5 standards are using the same or similar tones so it may have
some unwanted effects if you define ZVEI1 for SvxLink and a (e.g.) ZVEI3
sequence is received.
- SEL5_DEC_TYPE
- At the moment only SEL5_DEC_TYPE=INTERNAL is valid. Maybe we have support
for some external tone detectors later. To disable SEL5 tone decoding,
specify NONE or just 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 to an 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:10000
- OB_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 that it is 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 the AFSK bursts. 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 as to not overdrive the
transmitter. This is compensated in the link receiver by amplifying the
voice audio back to its original level. This configuration variable should
thus 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.
- IB_AFSK_ENABLE
- Set to 1 to enable reception of an initial signal level measurement via
in-band (IB) AFSK. This is used 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 and can thus use
the higher baudrate of 1200Bd. 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 receivers 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 "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.
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.
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.
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 the rtl_tcp utility is running on (Default:
localhost).
- PORT
- The TCP port that rtl_tcp is 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
- The frequency, in Hz, that the wide-band tuner should be placed at. This
configuration variable should normally be left unset since 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 use
this configuration variable 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 the
PEAK_METER explained 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
- If PEAK_METER is set to 1, 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.
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. 0dB corresponds to the power in a full-scale
sine wave.
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 the
BUFFER_LENGTH configuration variable to adjust the buffer length. The
default voting delay is 0.
- 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 at 0 to 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 is 1000 milliseconds.
- 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 to 50% and the
received signal strength on the current receiver is 40, a signal strength
of 40*1.5=60 is required on another receiver to initiate a switch. At
squelch open, if the received signal strength plus hysteresis is larger
than 100, the voting delay will be skipped. The default hysteresis is 50
percent.
- 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 is 500 milliseconds.
- 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 is 500 milliseconds.
- 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 receiver
- DISABLE rx_name - Disable the given receiver
Commands can be issued using a simple echo command from the shell.
Example: echo "DISABLE Rx1" >/dev/shm/voter_ctrl
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 is 5210.
- LOG_DISCONNECTS_ONCE
- Set this configuration variable to 1 to 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 is 0 which means that all
reconnect attempts will be logged.
- AUTH_KEY
- This is the authentication key (password) to 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 be 20 characters
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 will be used for authentication.
- CODEC
- The audio codec to use when transferring audio from this remote receiver.
Available codecs are: RAW (512kbps), S16 (256kbps), GSM (13.2kbps), SPEEX
(8-25kbps), OPUS (8-64kbps). These are raw bit-rate values. There will be
some overhead added to this so the real bit-rates on the wire are a little
bit higher. The OPUS codec is the most modern one and it also have the
best quality for a given bit-rate.
- SPEEX_ENC_FRAMES_PER_PACKET
- Speex encoder setting. Each Speex frame contains 20ms audio. If using a
low bit-rate configuration, the network overhead will be quite noticeable
if sending 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 setting this option to something like
4 (default), the delay will be about 4x20=80ms.
- SPEEX_ENC_QUALITY
- Speex encoder setting. Specify the encoder quality using a number between
0-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 from 2150 to 24600
bps. 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 about 2dB. 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).
- 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 about 8000 to 64000 bits per second are meaningful but the
codec can handle from like 2500 to 512000 bps. 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 by OPUS_ENC_BITRATE. Default: 1.
A local transmitter section is used to specify the configuration for a local
transmitter. In the default configuration file there is a configuration
section called Tx1. The section name could be anything. It should match
the TX configuration variable in the logic core where the transmitter is to be
used. The available configuration variables are described below.
- TYPE
- Always "Local" for a local transmitter.
- AUDIO_DEV
- Specify the audio device to use. Normally oss:/dev/dsp. 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.
- PTT_TYPE
- Use this configuration variable to specify which type of hardware to use
to control the PTT. Specify "SerialPin" for using a pin in the
serial port, "GPIO" to use a pin in a GPIO port, "PTY"
if you want to use an external interface script via a pseudo tty port or
"Hidraw" to use the linux/hidraw driver to support hidraw
devices like CM108 sound card, e.g. 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 to use for
"SerialPin" or "GPIO".
- PTT_PORT
- Specify the serial port that the PTT is connected to. E.g. /dev/ttyu0 for
COM1.
- PTT_PIN
- If PTT_TYPE is set to "SerialPin", specify the pin(s) in the
serial port that the PTT is connected to. It is possible to specify one or
two serial port pins. Some interface boards require that you specify two
pins since one pin does not provide enough drive power to the circuit. A
"!" in front of the pin name indicates inverted operation. Some
of the possible values are RTS, DTRRTS, !DTR!RTS or even DTR!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
information on how to set up the operating system. Normally, the pin
will be active high but if the pin name is prefixed with an exclamation
mark it will be active low instead. For some hardware platforms you may
need to also set the GPIO_PATH configuration variable.
- GPIO_PATH
- Use this configuration variable to set the path to the sys control devices
for GPIO. This normally is /sys/class/gpio but on some hardware, like the
Orange Pi, the path is /sys/class/gpio_sw.
- PTT_PTY
- If PTT_TYPE is set to "PTY" this configuration variable will set
the path for the PTY slave softlink that is used by the external script to
communicate to SvxLink.
SvxLink sends a 'T' to start transmitting and a 'R' to turn
the transmitter off. This can be used by an external script to interface
custom devices, modems or other hardware to SvxLink. Look for nhrcx.pl
to see an example.
It is possible to specify the same PTY for multiple functions
(e.g. squelch, DTMF etc) in both TX and RX configurations. This may be
good if there is one script handling all 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 are
GPIO1,GPIO2,GPIO3,GPIO4. Note that some sound cards like SSS1621 may not
support GPIO3 and GPIO4! You can invert the behavior with a "!"
in front of the name. Only one value is supported.
- SERIAL_SET_PINS
- Set the specified serial port pins to a static state. This can be good if
using a pin for reference voltage or if a pin have to be in a certain
state to not interfere with the operation of some equipment. There are two
pins that are possible to use, RTS and DTR. If prefixed with an
exclamation mark (!), the pin will be cleared and if not it will be set.
This configuration variable can only be used when PTT_TYPE is set to
"SerialPin".
Example: SERIAL_SET_PINS=RTS!DTR will set RTS and clear
DTR.
- PTT_HANGTIME
- Use this configuration variable to set a PTT hangtime. This can be good to
have on a transmitter in combination with using a tone squelch. When the
transmitter is ordered to stop transmitting, the tone is immediately
turned off, causing the squelch to close on the other side. Since the
transmitter keeps transmitting for a while, no squelch tail will be heard.
Another use is on a remote receiver link transmitter where you
don't want the transmitter to turn on and off between transmissions or
if the squelch close and open quickly due to for example mobile
flutter.
- TIMEOUT
- This is a feature that will prevent the transmitter from getting stuck
transmitting. Specify the number of seconds before the transmitter is
turned off. Note that this is a low level security mechanism that is meant
to only kick in if there is a software bug in SvxLink. Just so that the
transmitter will not transmit indefinitely. It is not meant to be used to
keep people from talking too long.
- TX_DELAY
- The number of milliseconds (0-1000) to wait after the transmitter has been
turned on until audio is starting to be transmitted. This can be used to
compensate for slow TX reaction or remote stations with slow reacting
squelches.
- CTCSS_FQ
- The frequency in Hz of the CTCSS tone to transmit. It is possible to
specify fractions using "." as decimal comma (e.g. 136.5). For
the tone to be transmitted the CTCSS_LEVEL variable must also be setup and
also the TX_CTCSS variable in the logic core configuration section.
- CTCSS_LEVEL
- The level in percent (0-100) of the CTCSS tone to transmit. What level to
set is hard to say. The FM modulation swing of the tone should be in
between 500-800 Hz. That is a bit hard to measure if you don't have the
right equipment. A normal FM station have a maximum swing of 5kHz so if
you manage to calibrate everything so that you get maximum swing when the
sound card audio is at peak level, the tone level should be in between
10-16%. However, most often the audio settings are configured a bit higher
than max since the audio seldom reaches maximum level. Then the level of
the CTCSS tone should be reduced. The default in the configuration file is
9%. For the tone to be transmitted the CTCSS_FQ variable must also be
setup and also the TX_CTCSS variable in the logic core configuration
section.
- PREEMPHASIS
- Enable this feature if you are modulating the FM modulator directly, like
through a 9k6 packet radio input. If no preemphasis filter is applied to
the audio, it will sound very dark when received. If you modulate the
transmitter through the microphone input the radio will apply a
preemphasis filter 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
- It is possible to transmit one of ten tones along with the normal
transmission to indicate a signal strength value to the receiver. This is
of most use when using a local transmitter as a link transmitter in a
RemoteTrx. It is not implemented, and probably not useful, in SvxLink
Server. Another requirement is that SvxLink has been compiled in 16kHz
mode. Otherwise this feature is disabled.
The TONE_SIGLEV_MAP configuration variable is used to map
tones to signal level values. It is a comma separated list of exactly
ten values in the 0 - 100 range. The first value map to the 5500Hz tone,
the second to the 5600Hz tone and so on. The last value map to the
6400Hz tone. What levels the tones should be mapped to depends on the
tone receiver implementation. Typically, if using a SvxLink application
as a receiver, the TONE_SIGLEV_MAP should be the same in the RX
configuration for that node.
- TONE_SIGLEV_LEVEL
- It is possible to transmit one of ten tones along with the normal
transmission to indicate a signal strength value to the receiver. This is
of most use when using a local transmitter as a link transmitter in a
RemoteTrx. It is not implemented, and probably not useful, in SvxLink
Server. Another requirement is that SvxLink has been compiled in 16kHz
mode. Otherwise this feature is disabled.
The TONE_SIGLEV_LEVEL configuration variable is used to set
the tone level. It is a value in the 1-100 range which indicate the
output level in percent of the maximum possible level. The default is
10.
- MASTER_GAIN
- This configuration variable can be used to fine tune or increase the audio
gain for all transmitted sound if it's not possible to do using the normal
sound card hardware gain controls. The gain should be given in dB and can
be both positive and negative.
- 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 is transmitted above the voice band so that it is
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 the AFSK bursts. 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 as to not overdrive the
transmitter. This is compensated in the link receiver by amplifying the
voice audio back to its original level. This configuration variable should
thus 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.
- 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.
- IB_AFSK_ENABLE
- Set to 1 to enable transmission of an initial signal level measurement via
in-band (IB) AFSK. This is used 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 and can thus use
the higher baudrate of 1200Bd. 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.
- 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.
- CTRL_PTY
- Set this configuration variable to the path of a PTY to use for
controlling a transmitters 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>;". 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.
A networked transmitter section is used to specify the configuration for a
transmitter connected through a TCP/IP network. In the default configuration
file there is a networked transceiver configuration section called
NetTx. The section name could be anything. It should match the TX
configuration variable in the logic core where the transmitter is to be used.
The available configuration variables are described below. How to use a
networked transmitter is further described in the remotetrx(1) manual
page.
- TYPE
- Always "Net" for a networked transmitter.
- HOST
- The hostname or IP address of the remote transmitter host.
- TCP_PORT
- The TCP port that RemoteTrx listen on. The default is 5210.
- LOG_DISCONNECTS_ONCE
- Set this configuration variable to 1 to 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 is 0 which means that all
reconnect attempts will be logged.
- AUTH_KEY
- This is the authentication key (password) to 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 be 20 characters
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 will be used for authentication.
- 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. There will be
some overhead added to this so the real bit-rates on the wire are a little
bit higher. The OPUS codec is the most modern one and it also have the
best quality for a given bit-rate. There also is a NULL codec 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 contains 20ms audio. If using a
low bit-rate configuration, the network overhead will be quite noticeable
if sending 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 setting this option to something like
4 (default), the delay will be about 4x20=80ms.
- SPEEX_ENC_QUALITY
- Speex encoder setting. Specify the encoder quality using a number between
0-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 from 2150 to 24600
bps. 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 about 2dB. 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).
- 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 about 8000 to 64000 bits per second are meaningful but the
codec can handle from like 2500 to 512000 bps. 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 by OPUS_ENC_BITRATE. Default: 1.
A multi transmitter section is used if one wants to transmit on multiple
transmitters simultaneously. 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.
A module section contain the configuration for a specific module. It have some
general configuration variables and some module specific configuration
variables. The general configuration variables are listed below.
- NAME
- The name of the module. This name must match the namespace used in the TCL
event handling script. If not set, NAME will be set to the section
name.
- PLUGIN_NAME
- The base name of the plugin. For example if this configuration variable is
set to Foo, the core will look for a plugin called ModuleFoo.so. If not
set, PLUGIN_NAME will be set to the same value as NAME.
- 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.
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.
- 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 on
http://www.echolink.org/links.jsp. The format is host: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:5199
- APRS_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 at http://aprs.fi/.
To choose a suitable APRS server from the so called tier 2
network, have a look at http://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, 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:14580
- LON_POSITION
- The longitude of the station position, entered as
"degrees.arcminutes.arcseconds"
Example:
LON_POSITION=09.02.20E
- LAT_POSITION
- The latitude of the station position, entered as
"degrees.arcminutes.arcseconds"
Example:
LAT_POSITION=51.02.22N
- CALLSIGN
- Enter your callsign for the APRS network with a prefix that indicates the
type of station, (ER- for repeaters, EL- for links).
Examples:
CALLSIGN=EL-DL1ABC # callsign for a link
CALLSIGN=ER-DB0ABC # callsign for a repeater
- FREQUENCY
- The tx-frequency of the link/repeater in MHz. For repeaters, information
about the RX/TX shift in the COMMENT configuration variable may be useful.
Example:
FREQUENCY=430.050 # tx-frequency is 430.050 MHz
- TX_POWER
- The power of your transmitter in watts.
Example:
TX_POWER=10 # tx output is 10 watts
- ANTENNA_GAIN
- The gain of your antenna in dBd.
Example:
ANTENNA_GAIN=5 # antenna gain is 5 dBd
- ANTENNA_HEIGHT
- The height of the link-/repeater antenna in meters or feet above the
terrain, not sealevel.
Example:
ANTENNA_HEIGHT=10m # 10 meters above the ground
ANTENNA_HEIGHT=90 # 90 feet
- ANTENNA_DIR
- Main beam direction of the antenna in degrees. If an omni direction
antenna is used, specify -1 as the direction.
Example:
ANTENNA_DIR=-1 # an omni directional antenna is used
ANTENNA_DIR=128 # main beam direction is 128 degrees
- PATH
- The PATH variable controls the way of forwarding your beacon inside the
APRS network if it is gated by a local APRS digipeater. In some cases it
has to be changed according to local requirements. Please contact your
local APRS sysop for further information. Changes should be made only
according to the NEWn-N paradigm. Leave this variable untouched if you are
unsure of its setting. No spaces or control characters are allowed. PATH
has no influence on the propagation on non-RF networks.
Examples:
PATH=WIDE1-1
PATH=WIDE1-1,WIDE2-2
- BEACON_INTERVAL
- The interval, in minutes, with which beacons will be sent to the APRS
network. A good value is 10 minutes. If your beacon is gated via RF,
please increase the interval 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.
Example:
BEACON_INTERVAL=30 # APRS-beacons will be sent every 30 minutes.
- TONE
- The CTCSS sub-audible tone that is to be used for operation over your link
or repeater. If you don't use tone control set it to 0.
Examples:
TONE=136 # 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 Hz
- STATISTICS_INTERVAL
- Defines the interval in minutes in that an aprs statistic is sent into the
aprs network. Range: 5-60, default is 10 minutes
- COMMENT
- Specify a short comment here, maybe a link to your website or information
that could be interesting for others. The length should not exceed 255
characters and may not have control characters like "Carriage
Return" (\r) or "Line Feed" (\n) inside. Make your comment
as short as you can to give users with a small display (TH-D7) the chance
to display the full comment text.
Example:
COMMENT=[svx] Running SvxLink by SM0SVX
- PTY_PATH
- Specify a path to a communications PTY that can be used by external
applications to inject APRS packets into the APRS-IS network.
The AUDIO_DEV configuration variables specify which audio device to use for a
receiver or transmitter. SvxLink support 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".
The "alsa" type will use the specified Alsa device.
Example: "oss:/dev/dsp". Describing the format of Alsa device
names is outside the scope for this document.
The "oss" type 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.
The "udp" type 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 interleved channels.
Sampling frequency can be chosen using the CARD_SAMPLE_RATE config variable
as usual.
GPIO (General Purpose IO) is used to access hardware pins that are made
available for example on an embedded system. Before starting to use a pin in
SvxLink some setup need to be done in the operating system. With the standard
distribution of SvxLink there is 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 can be found among the other
SvxLink configuration files (typically in /etc/svxlink), is called gpio.conf.
The signal level detector is used when using multiple receivers or when using
the SIGLEV squelch. The signal level is used by a voter to choose the receiver
with the highest signal strength. The choice is made directly after squelch
open. For the voter to make a correct choice, the signal level detector must
be calibrated on each receiver.
To use the noise signal level detector, first set
SIGLEV_DET=NOISE. There are two configuration variables that is used to
calibrate the detector. They are SIGLEV_SLOPE and SIGLEV_OFFSET in a local
receiver section. The slope is the gain of the detector and the offset is
used to adjust the detector so that when there is no input signal, the
detector will return 0. The goal is to adjust the detector so that when no
signal is received, a value of 0 is produced and when full signal strength
is received, a value of 100 is produced. It will never be exakt but that
does not matter.
The calibration is normally done by using the
siglevdetcal(1) application. To be able to do a correct calibration,
it must be possible to open the squelch so that only noise is received. The
antenna cable should be disconnected or a dummy load should be used.
WARNING: Before starting the siglevdetcal application, pull the PTT
cable since the PTT might get triggered during the calibration
procedure.
The siglevdetcal utility will also measure the CTCSS tone SNR
offset so that the CTCSS_SNR_OFFSET config variable can be set up to a
proper value.
If the siglevdetcal application cannot be used for some reason,
the manual procedure below might be used. This procedure will only work for
a receiver with unsquelched audio. Note: To calibrate a remote
receiver it must be connected to the SvxLink server. Otherwise the squelch
will not open.
- 1
- Connect a dummy load or disconnect the antenna from the transceiver. If
you disconnect the antenna, make sure to also disconnect the PTT.
- 2
- Set SIGLEV_SLOPE=1 and SIGLEV_OFFSET=0 and restart SvxLink.
- 3
- Open the squelch so that there is only noise coming into SvxLink.
- 4
- 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.
- 5
- 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.
- 6
- SIGLEV_SLOPE = 100 / (mean diff)
- 7
- SIGLEV_OFFSET = - (mean lower) * SIGLEV_SLOPE
- 8
- After changing SIGLEV_SLOPE and SIGLEV_OFFSET, restart SvxLink and check
to see that the squelch open value is now around 100 and the squelch close
value is around 0.
The format of the output from the state PTY is:
<timestamp> <context>:<event name>
<event data>
where the different parts mean:
timestamp = <seconds since 1 jan
1970>.<milliseconds>
context = Name of context
event_name = Name of event
event data = Event specific data
The following specific events exist.
- Voter:sql_state
- Report the state of all squelches for all receivers. The format of the
event specific data is:
<rx name><state><siglev>
[<rx_name><state><siglev> ...]
where the different parts mean:
rx_name = Configuration file section name for receiver
state = _ (sql closed), : (sql open), * (sql open and rx
selected)
siglev = The measured signal level
- /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.
Tobias Blomberg (SM0SVX) <sm0svx at users dot sourceforge dot net>
svxlink(1), remotetrx(1), siglevdetcal(1), devcal(1)
Visit the GSP FreeBSD Man Page Interface. Output converted with ManDoc. |