| 
		
		G4USP | Page last updated: 
		19/10/2014 | 
Content-type: text/html 
SVXLINK.CONF
Section: File Formats (5)
Updated: SEPTEMBER 2013
index
 
NAME
svxlink.conf - Configuration file for the SvxLink server  
DESCRIPTION
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.  
FILE FORMAT
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).   
CONFIGURATION VARIABLES
Here is the description of all configuration variables that SvxLink understands. 
The configuration variables are described section for section.  
GLOBAL
The GLOBAL section contains application global configuration data.
	- MODULE_PATH 
- Specify where the SvxLink modules can be found. The default is /usr/lib/svxlink 
	
- LOGICS 
- Specify a comma separated list of logic cores that should be created. 
	The logic core is the thing that ties the transciever 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 behaviour 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 are ignored. 
- TIMESTAMP_FORMAT 
- This variable specifies the format of the timestamp 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 timestamp 
	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 61) So, 
			TIMESTAMP_FORMAT="%d %b %Y %H:%M:%S" would give a timestamp looking 
			something like: "29 Nov 2005 22:31:59".
			
 
 
- CARD_SAMPLE_RATE 
- This configuration variable determines the sampling rate used for audio 
	input/output. SvxLink always work with a sampling rate of 8kHz internally 
	but there still are som benefits from using a higher sampling rate. On some 
	sound cards the filters look pretty bad at 8kHz 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 8kHz due to insufficient 
	anti-alias filtering or resampling effects. These, often cheeper, 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: 8000, 16000 and 48000.  
- LOCATION_INFO 
- Enter the section name that contains information required for 
	transfering 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).
	
Common Logic configuration variables
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_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. This really only is of use when using a radio that it is 
	difficult to send DTMF digits from, like the Yaesu VX-2 handheld. The down 
	side of enabling this option is that the DTMF detection some times false 
	trigger on voice. This can cause interresting situations when all of a 
	sudden a module get activated in the middle of a QSO. 
- 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 
	occurr. The default location is /usr/share/svxlink/events.tcl. 
- DEFAULT_LANG 
- Set the default language to use for announcements. It should be set to 
	an ISO code (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".  
Simplex Logic Section
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.
	
Repeater Logic Section
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. 
- 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 themselvs. 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.
	
QSO Recorder Section
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 splitted 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/bin/oggenc -Q \"%f\" && rm \"%f\" ENCODER_CMD=/usr/bin/lame--quiet\%f\\%d/%b.mp3\&&rm\%f\
			ENCODER_CMD=/usr/bin/speexenc\%f\\%d/%b.spx\2>/dev/null&&rm\%f\
			ENCODER_CMD=/usr/bin/opusenc\%f\\%d/%b.opus\2>/dev/null&&rm\%f\
 
 
 
Macros Section
A macros section 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.   
Logic Linking
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
	
Local Receiver Section
A local receiver section is used to specify the configuration for a receiver 
connected to the sound card. In the default configuration file there is a Local 
configuration section called Rx1. The section name could be anything. It 
should match the RX configuration variable in the logic core where the receiver 
is to be used. The available configuration variables are described below.
	- TYPE 
- Always "Local" for a local receiver. 
- AUDIO_DEV 
- Specify the audio device to use. Normally alsa:plughw:0. Have a look at 
	the AUDIO DEVICE SPECIFICATIONS chapter for more information. 
- AUDIO_CHANNEL 
- Specify the audio channel to use. SvxLink can use the left/right stereo 
	channels as two mono channels. Legal values are 0 or 1. 
- SQL_DET 
- Specify the type of squelch detector to use. Possible values are: VOX, 
	CTCSS, SERIAL, EVDEV, SIGLEV or GPIO.
	The VOX squelch detector determines if there is a signal present by 
	calculating a mean value of the sound samples. The VOX squelch detector 
	behaviour 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.  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.  
- 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 limiti, 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, everthing is 
	back to normal. When it opens the next time a squelch open will be 
	signalled. For example, use this feature to make sure that a faulty receiver 
	cannot block the system indefinitly. 
- 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 
	squlech 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 (Neighbour 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/ttyS0 
- 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. The squelch-open-level must also be specified. This is done using the 
	syntax SQL_PIN=PIN:LEVEL, where PIN is one of the pins above and LEVEL is 
	either SET or CLEAR. Example: SQL_PIN=CTS:SET 
- 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_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. 
	
- SIGLEV_DET 
- Choose which type of signal level detector to use. There are two 
	choices, "NOISE" or "TONE". The signal level detector is only needed when 
	using multiple receivers in a voter configuration or when using the SIGLEV 
	squelch type.
	Type NOISE use a bandpass filter in the range of 5 - 5.5kHz (CARD_SAMPLE_RATE 
	>= 16000) or a highpass 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 spektrum (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.  
- 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. 
- 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. 
- 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 distorsion 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. Setting it to 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/ttyS0). 
- 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. 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. 
- 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.
	
Voter Section
Receiver type "Voter" is a "receiver" that combines multiple receivers and 
selects one of them to take audio from when the squelch opens. Which receiver to 
use is selected directly after squelch open. It is possible to set up a voting 
delay which will make the voter wait a while before choosing which RX to use. 
This will give all receivers some time to report their signal strengths. After 
the initial choice have been made a periodic check is done to see if any of the 
other receivers receive a stronger signal. In the default configuration file 
there is a voter section called Voter.
	- TYPE 
- Always "Voter" for a voter. 
- RECEIVERS 
- Specify a comma separated list of receivers that the voter should use. 
	Example: RECEIVERS=Rx1,Rx2,Rx3 
- VOTING_DELAY 
- Specify the delay in milliseconds that the voter will wait after the 
	first sqeulch 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 noticeble 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.
	
Networked Receiver Section
A networked receiver section is used to specify the configuration for a receiver 
connected through a TCP/IP network. In the default configuration file there is a 
networked receiver configuration section called NetRx. The section name 
could be anything. It should match the RX configuration variable in the logic 
core where the receiver is to be used. The available configuration variables are 
described below. How to use a networked receiver is further described in the 
remotetrx(1) 
manual page.
	- TYPE 
- Always "Net" for a networked receiver. 
- HOST 
- The hostname or IP address of the remote receiver host. 
- 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 transfering audio from this remote receiver. 
	Available codecs are: RAW (512kbps), S16 (256kbps), GSM (13.2kbps), SPEEX 
	(8-25kbps), OPUS (8-64kbps). These are raw bitrate values. There will be 
	some overhead added to this so the real bitrates 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 bitrate. 
- SPEEX_ENC_FRAMES_PER_PACKET 
- Speex encoder setting. Each Speex frame contains 20ms audio. If using a 
	low bitrate 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 bitrates. 
- SPEEX_ENC_BITRATE 
- Speex encoder setting. Specify the bitrate to use. Speex will snap to 
	the nearest lower possible bitrate. Possible values range from 2150 to 24600 
	bps. You should probably not specify quality at the same time as bitrate. 
	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 bitrate 
	encoding. If enabled, the encoder will try to keep a constant quality by 
	increasing the bitrate when needed. 
- SPEEX_ENC_VBR_QUALITY 
- Speex encoder setting. The quality (0-10) to use in variable bitrate 
	mode. 
- SPEEX_ENC_ABR 
- Speex encoder setting. The average bitrate encoding will try to keep a 
	target bitrate by continously adjusting the quality. This configuration 
	variable specify the target bitrate 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 bitrate 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 bitrate 
	encoding. If enabled, the encoder will try to keep a constant quality by 
	increasing the bitrate when needed and decrease it when the quality can be 
	assured with a lower bitrate. The target average bitrate is the one set by 
	OPUS_ENC_BITRATE. Default: 1.
	
Local Transmitter Section
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 alsa:plughw:0. Have a look at 
	the AUDIO DEVICE SPECIFICATIONS chapter for more information. 
- AUDIO_CHANNEL 
- Specify the audio channel to use. SvxLink can use the left/right stereo 
	channels as two mono channels. Legal values are 0 or 1. 
- PTT_PORT 
- Specify the serial port that the PTT is connected to. E.g. /dev/ttyS0 
	for COM1. Set it to NONE if no PTT is desired for some reason.
	If PTT_PORT is set to GPIO, any available GPIO (General Purpose IO) pin 
	may be used. The pin to use is specified using the PTT_PIN config variable. 
	Have a look at the USING GPIO section for information on how to set up the 
	operating system.  
- PTT_PIN 
- 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 for PTT_PORT, 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.  
- 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.  
- 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 indefinately. 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.
	Note: The level of the tone affects the level of the rest of the 
	audio in SvxLink. This is to avoid distorision when the two audio streams 
	are mixed together. For example, if a tone level of 9% is setup the rest of 
	the audio will be attenuated by 9%. This is true even if the CTCSS_FQ and 
	TX_CTCSS configuration variables are not set so comment this configuration 
	variable out if CTCSS on TX is not used.  
- PREEMPHASIS 
- [EXPERIMENTAL] 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 length, 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_TONE_AMP 
- The amplitude, in dB, of DTMF digits transmitted on this transmitter. 
	Zero dB is the maximum amplitude. -18dB 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.  
Networked Transmitter Section
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. 
- 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 transfering audio to this remote 
	transmitter. Available codecs are: RAW (512kbps), S16 (256kbps), GSM 
	(13.2kbps), SPEEX (8-25kbps), OPUS (8-64kbps). These are raw bitrate values. 
	There will be some overhead added to this so the real bitrates 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 bitrate. 
- SPEEX_ENC_FRAMES_PER_PACKET 
- Speex encoder setting. Each Speex frame contains 20ms audio. If using a 
	low bitrate 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 bitrates. 
- SPEEX_ENC_BITRATE 
- Speex encoder setting. Specify the bitrate to use. Speex will snap to 
	the nearest lower possible bitrate. Possible values range from 2150 to 24600 
	bps. You should probably not specify quality at the same time as bitrate. 
	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 bitrate 
	encoding. If enabled, the encoder will try to keep a constant quality by 
	increasing the bitrate when needed. 
- SPEEX_ENC_VBR_QUALITY 
- Speex encoder setting. The quality (0-10) to use in variable bitrate 
	mode. 
- SPEEX_ENC_ABR 
- Speex encoder setting. The average bitrate encoding will try to keep a 
	target bitrate by continously adjusting the quality. This configuration 
	variable specify the target bitrate 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 bitrate 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 bitrate 
	encoding. If enabled, the encoder will try to keep a constant quality by 
	increasing the bitrate when needed and decrease it when the quality can be 
	assured with a lower bitrate. The target average bitrate is the one set by 
	OPUS_ENC_BITRATE. Default: 1.
	
Multi Transmitter Section
A multi transmitter section is used if one wants to transmit on multiple 
transmitters simulaneously. 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.
	
Module Section
A module section contain the configuration for a specific module. It have some 
general configuration variables and some module specific configuration 
variables. The general 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.
	
LocationInfo
	- 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 - Austrailia 
	and New Zeeland. 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 subaudible 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 subaudible or call tones
 TONE=1750 # the link/repeater use a tone burst of 1750 Hz
 
- STATISTICS_INTERVAL 
- Defines the interval in minutes in that a 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
 
AUDIO DEVICE SPECIFICATIONS
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: "alsa:plughw:0". 
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.   
USING GPIO
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. The example below 
will set up pin 31 as an output for PTT use and pin 30 is used as input for 
squelch. Make sure that the commands are run as user root.
  Enable the PTT pin for GPIO: 
  echo 31 > /sys/class/gpio/export 
  Set the direction to output for the pin: 
  echo out > /sys/class/gpio/gpio31/direction 
  Make sure that the svxlink user can write to the GPIO pin: 
  chown svxlink /sys/class/gpio31/value 
  Enable the squelch pin for GPIO: 
  echo 30 > /sys/class/gpio/export 
  Set the direction to input for the pin: 
  echo in > /sys/class/gpio/gpio30/direction 
  Make sure that the svxlink user can read from the GPIO pin: 
  chown svxlink /sys/class/gpio30/value 
These steps have to be performed whenever the system is rebooted. Putting the 
commands in a script is recommended.   
CALIBRATING THE SIGNAL LEVEL DETECTOR
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 "Squech 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.
		
 
FILES
	- /etc/svxlink/svxlink.conf (or deprecated /etc/svxlink.conf)
	
- The system wide configuration file. 
- ~/.svxlink/svxlink.conf 
- Per user configuration file. 
- /etc/svxlink/svxlink.d/* 
- Additional configuration files. Typically one configuration file per 
	module.
	
AUTHOR
Tobias Blomberg (SM0SVX) <sm0svx at users dot sourceforge dot net>
 
SEE ALSO
svxlink(1), 
remotetrx(1), 
siglevdetcal(1)
 
 Index
	- NAME
- DESCRIPTION
- FILE FORMAT
- CONFIGURATION VARIABLES
- 
	
		- GLOBAL
- Common Logic configuration variables
- Simplex Logic Section
- Repeater Logic Section
- QSO Recorder Section
- Macros Section
- Logic Linking
- Local Receiver Section
- Voter Section
- Networked Receiver Section
- Local Transmitter Section
- Networked Transmitter Section
- Multi Transmitter Section
- Module Section
- LocationInfo
 
- AUDIO DEVICE SPECIFICATIONS
- USING GPIO
- CALIBRATING THE SIGNAL LEVEL DETECTOR
- FILES
- AUTHOR
- SEE ALSO
This document was created by 
man2html, using the manual pages.
Time: 16:10:17 GMT, June 30, 2014
 
HOME