Introduction

EchoLink is one of many techniques for linking transceivers that are BLOS (Beyond Line Of Sight) from one another. There are similar systems (often digital modes) that include technologies like D-STAR, DMR, or Wires-X, each with their own backend infrastructure and protocols. Regardless of the system, they all fundamentally behave as VoIP interface nodes for a transceiver to patch across the Internet to another node. Whether the transceivers are relatively local but simply separated by an obstacle or across the planet from each other, EchoLink provides a means of establishing connectivity. This can be pretty cool when traveling to stay linked into your hometown repeater for a scheduled net, connecting to existing HAM friends in other geographies, or just making QSOs anywhere in the world an EchoLink node exists.

Credit

This article was made possible from the SvxLink documentation, EchoLink documentation, and adapting solutions from other HAM operators.

• EchoLink User Guide (pdf)
• SvxLink Project
• SvxLink Source Code
• SvxLink Configuration Man Page
• SvxLink EchoLink Configuration Man Page
• EchoLink DTMF
• "SvxLink Using DTMF Via Command Line" by ICS-Ctrl
• Forum Post "Activating Module EchoLink Permanently" on SourceForge
• "EchoLink - SvxLink Server" by VK4PK
• "EchoLink on Ubuntu Setting Up SvxLink" by ZR6AIC
• "EchoLink Node on Raspberry Pi Using SvxLink Part 1" and "Part 2" by NP2WJ

Requisite Hardware

Not a lot of equipment is necessary for creating a mobile EchoLink station. For my application, I used a cheap Baofeng UV-5R because it only needed to serve as a local transceiver bridge between my mobile/handheld and the EchoLink node. The Baofeng just needed an audio patch cable to connect it to a Raspberry Pi via a USB soundcard's speaker and microphone ports.

• VHF Radio
• Raspberry Pi
• USB Sound Card
• [optional] Portable Battery

Image linked from: Adafruit product website

Raspberry Pis are easily acquired from a variety of locations like Amazon or Adafruit. Running without the graphical interface reduces the processing demands and a Model 3+ or better Pi will be sufficient. Make sure to get a portable USB battery charger of some kind otherwise you'll have a lot of inert equipment that looks cool.

Baofeng UV-5R Transceiver

The Baofeng UV-5R is a popular Chinese handheld transceiver primarily because it is so cheap. Be cautious in your configuration as the Chinese manufacturing process does not incorporate frequency restrictions which often enable you to accidentally transmit illegally (based on your country's bandplans). Nevertheless, the configurable 5W output power will enable more than enough local range to your EchoLink node without trampling other nearby stations.

Baofeng Audio Patch Cable	UGreen Audio Splitter	USB Audio Dongle

The BTech APRS cable connects to the Baofeng's speaker and microphone ports and serves to patch the audio over the Raspberry Pi. Because both the input and output ride the same cable, a UGreen Audio Splitter cable will split the signals into the more commonly expected audio in/out connections to the Raspberry Pi. There are also many USB sound cards available but the adapter by Sabrent is cheap and functional. It's a simple and small unit offering the USB connection, an audio input, and an audio output.

Installing the USB Sound Card

Just plug it in. Once attached, verify the device is seen by the Raspberry Pi with a few command line tools. For the SvxLink configuration file, you will need the device identifiers. These can be found using the aplay and arecord commands or by listing the attached USB devices.

pi@EchoLink:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: I82801AAICH [Intel 82801AA-ICH], device 0: Intel ICH [Intel 82801AA-ICH]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Device [USB Audio Device], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

pi@APRS:~ $ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: I82801AAICH [Intel 82801AA-ICH], device 0: Intel ICH [Intel 82801AA-ICH]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: I82801AAICH [Intel 82801AA-ICH], device 1: Intel ICH - MIC ADC [Intel 82801AA-ICH - MIC ADC]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Device [USB Audio Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

pi@EchoLink:~ $ lsusb
Bus 001 Device 006: ID 0d8c:0014 C-Media Electronics, Inc. Audio Adapter (Unitek Y-247A)

pi@EchoLink:~ $ sudo dmesg
[156688.382091] usb 1-2: new full-speed USB device number 6 using ohci-pci
[156688.890425] usb 1-2: New USB device found, idVendor=0d8c, idProduct=0014, bcdDevice= 1.00
[156688.890430] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[156688.890433] usb 1-2: Product: USB Audio Device
[156688.890434] usb 1-2: Manufacturer: C-Media Electronics Inc.
[156688.906715] input: C-Media Electronics Inc. USB Audio Device as /devices/pci0000:00/0000:00:06.0/usb1/1-2/1-2:1.3/0003:0D8C:0014.0002/input/input8
[156688.966044] hid-generic 0003:0D8C:0014.0002: input,hidraw1: USB HID v1.00 Device [C-Media Electronics Inc. USB Audio Device] on usb-0000:00:06.0-2/input3
[156689.157446] mc: Linux media interface: v0.10
[156689.711082] usbcore: registered new interface driver snd-usb-audio

Now use the ALSA (Advanced Linux Sound Architecture) tools for configuring the USB sound card as the default audio device. Assuming the USB sound card is the only additional adapter on the Raspberry Pi, the following sed commands will automatically edit the alsa.conf file with the card's previously identified device number (in this case "1").

sudo sed -i "/^defaults.ctl.card/c\defaults.ctl.card 1" /usr/share/alsa/alsa.conf
sudo sed -i "/^defaults.pcm.card/c\defaults.pcm.card 1" /usr/share/alsa/alsa.conf

If you only have one USB audio device, you can use the following lines to automatically do everything above - e.g. grab the card number and do the configuration replacement. This alternative, all-in-one approach is also handy because every now and then, as the Raspberry boots, the devices will be numbered differently and these lines will handle that.

sed -i "/^defaults.pcm.card/c\defaults.pcm.card `grep 'USB\-Audio' /proc/asound/cards | awk '{print $1}'`" /usr/share/alsa/alsa.conf
sed -i "/^defaults.ctl.card/c\defaults.ctl.card `grep 'USB\-Audio' /proc/asound/cards | awk '{print $1}'`" /usr/share/alsa/alsa.conf

Confirm the USB card is now default using the alsamixer utility. It is also possible to adjust the audio levels from within the tool's interface which is helpful for later tweaking signal-to-noise ratios so SvxLink can correctly identify and decode DTMF tones.

TUI from alsamixer

In the alsamixer utility, press F5 to display both the output and input channels. Use the left/right arrow keys to select and the up/down arrow keys to adjust the corresponding level. For my configuration, I raised both the speaker channels up to below the red line. Raising the speaker gain was necessary to avoid vox clipping in the Baofeng. Raisig the mic and mic capture levels was not entirely necessary so long as the "auto gain control" option was active. Without the "auto gain control," raising the input channel gains a little allowed SvxLink to decode the DTMF signals but the VOX would not activate on my voice. It only activated on my voice with the input channels maxed out (or the "auto gain control" enabled).

Installing SvxLink

There are two fundamental ways to install SvxLink. The first is directly from the source code repository and follow the SM0SVX's instructions. The second is from the package repository. For brevity, the output from these commands is omitted. In summary, the source is downloaded from github, configured via cmake, built with make and installed.

wget -O svxlink-19.09.2.tar.gz https://github.com/sm0svx/svxlink/archive/refs/tags/19.09.2.tar.gz
tar xvzf svxlink-19.09.2.tar.gz
cd svxlink-19.09.2/src
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DSYSCONF_INSTALL_DIR=/etc -DLOCAL_STATE_DIR=/var ..
make
make doc
sudo make install
sudo ldconfig

For the less sadist HAM radio operators, just install it from the package repository. It may not be the most bleeding edge version, but the code has not updated since 2019 so it's doubtful doing it the hard way comes with any benefit. The package installer will also configure the binary as a systemd service for easier starting and stopping.

sudo apt install svxlink-server
sudo systemctl enable svxlink-server

Additionally, you will need the "voices" which are audio renderings the server patches through the transceiver for status updates and prompts. There are many different voices to choose from but the following steps download and install the US English voice files.

cd /usr/share/svxlink/sounds/ 
sudo wget https://github.com/sm0svx/svxlink-sounds-en_US-heather/releases/download/19.09/svxlink-sounds-en_US-heather-16k-19.09.tar.bz2 
sudo tar xvjf svxlink-sounds-en_US-heather-16k-19.09.tar.bz2 
sudo ln -s en_US-heather-16k en_US

Configuring SvxLink

There are not a lot of changes required to the SvxLink configuration files to enable an EchoLink node. As a matter of fact, when looking at the configurations, it will quickly become obvious SvxLink can actually do a lot more than just EchoLink. There are features for "parroting" audio which can be handy for testing equipment and there's even a voice mail option. Fortunately, everything is basically disabled by default so the other features will not interfere with any future EchoLink troubleshooting.

The following sed lines will makes the minimum necessary changes to the /etc/svxlink/svxlink.conf configuration file. Additional settings can be adjusted for customization, but they are not necessary to get the node online. This first set of commands makes the configuration changes for the radio interface.

sudo cp /etc/svxlink/svxlink.conf /etc/svxlink/svxlink.conf.original
sudo sed -i "/^#CARD_CHANNELS=1/c\CARD_CHANNELS=1" /etc/svxlink/svxlink.conf
sudo sed -i "/^CALLSIGN/c\CALLSIGN=YOURCALLSIGNHERE" /etc/svxlink/svxlink.conf
sudo sed -i "/^AUDIO_DEV/c\AUDIO_DEV=alsa:plughw:`grep 'USB\-Audio' /proc/asound/cards | awk '{print $1}'`" /etc/svxlink/svxlink.conf

The first line quickly makes a backup of the original configuration in case it is necessary to revert all modifications. When troubleshooting, a quick line to determine what changes have been applied compared to default is the following:

diff -y --suppress-common-lines /etc/svxlink/svxlink.conf /etc/svxlink/svxlink.conf.original

The CARD_CHANNELS option relates to how SvxLink handles mono (1) vs stereo (2). As only one radio needs to be controlled, configuring for mono is appropriate. The CALLSIGN option must be set appropriately to your licensed callsign. The AUDIO_DEV line gets set to the numeric card number of the USB audio device found above when the device was configured. This particular sed line includes the necessary script to automatically identify that number.

sudo sed -i "/^MODULES/c\MODULES=ModuleEchoLink" /etc/svxlink/svxlink.conf

The MODULES option enables the various features within SvxLink. It is possible to leave this alone for the default modules to stay enabled. They can, however, be troublesome later if a DTMF code is interpreted incorrectly and activates an unintended module. If that happens, subsequent DTMF codes will interact with that module instead of the controlling the EchoLink module.

sudo sed -i "/PREAMP/c\PREAMP=6" /etc/svxlink/svxlink.conf
sudo sed -i "/DEEMPHASIS/c\DEEMPHASIS=1" /etc/svxlink/svxlink.conf

These two lines affect how well SvxLink interprets the DTMF codes and may vary depending on the connected transceiver. The PREAMP is a software signal amplification representing the number of dB to boost the signal. Per the SvxLink manual, and good radio practice, if you can optimally tune your radio to get a clean signal, it might not be necessary to use this option. From the SvxLink manual, the DEEMPHASIS filter prevents higher audio frequencies from amplification to avoid a tinny sound. Without the DEMPHASIS enabled, SvxLink was unable to decode the DTMF signals at all.

NOTE: In later testing, I found that enabling the PREAMP makes DTMF decoding much easier but it came at the cost of introducing significant noise to my audio. It is definitely worthwhile to leave the PREAMP disabled (e.g. commented out) and utilize other means of making sure the requisite signals are interpreted.

sudo sed -i "/VOX_THRESH/c\VOX_THRESH=500" /etc/svxlink/svxlink.conf

Changing the VOX_THRESH value adjusts the threshold at which SvxLink opens the squelch due to detecting a signal. By default, the value was 1000. In this particular arrangement, even with the "auto gain control" on the soundcard enabled, I found my voice wasn't tripping the VOX. Previously, I had relied on the PREAMP=6 which worked but made the voice copy almost unintelligible. Leaving the PREAMP disabled but reducing the VOX_THRESH to 500 seemed to consistently open the squelch without any false opens.

sudo sed -i "/PEAK_METER/c\#PEAK_METER=1" /etc/svxlink/svxlink.conf

Lastly, commenting out the PEAK_METER option reduces the amount of logging by SvxLink. It can be helpful during system tuning to have it uncommented and set to 1 but once the system is working, this feature logs a LOT and will not be needed anymore.

Configuring ECHOLINK

The EchoLink node itself is managed by the /etc/svxlink/svxlink.d/ModuleEchoLink.conf file. Truly, it would be possible to alter only the CALLSIGN and PASSWORD options to have a functioning node though a few other options are recommended.

sudo sed -i "/^CALLSIGN/c\CALLSIGN=YOURCALLSIGN-L" /etc/svxlink/svxlink.d/ModuleEchoLink.conf
sudo sed -i "/^PASSWORD/c\#PASSWORD=YOURPASSWORD" /etc/svxlink/svxlink.d/ModuleEchoLink.conf

To register a callsign with the EchoLink system and get a password, follow the validation instructions on the EchoLink website. To reset a forgotten password, use the password reset feature on the EchoLink website.

The callsign used in the CALLSIGN option will have either a -L or a -R appended. The -L suffix indicates that your node is a link, typically for standalone stations. The -R suffix indicates your node is attached to a repeater. For this guide, using a Baofeng UV-5R, the -L is most appropriate.

sudo sed -i "/^LINK_IDLE_TIMEOUT/c\LINK_IDLE_TIMEOUT=600" /etc/svxlink/svxlink.d/ModuleEchoLink.conf
sudo sed -i "/^TIMEOUT/c\TIMEOUT=3000" /etc/svxlink/svxlink.d/ModuleEchoLink.conf

The LINK_IDLE_TIMEOUT option indicates how many seconds until SvxLink will disconnects an idle connection. By default, the option is set to 300 which can be short for users connected via the EchoLink phone app or another connected EchoLink node. Shorter numbers can be troublesome when connected users are just waiting for a net to begin or a contact to return from idle. Bumping the value to 600 at least keeps the connections up for 10 minutes.

The TIMEOUT option exists in the default configuration but is not defined in the documentation. It seemed to relate to how long the EchoLink module would remain active before timing out in SvxLink which would require re-activation via DTMF codes. The only instance of TIMEOUT in the documentation relates to its presence in the SvxLink configuration for a safety cutoff time on a stuck transmission.

There are three remaining options that are easier to edit manually in the /etc/svxlink/svxlink.d/ModuleEchoLink.conf file because they are longer, more personalized information strings. But it is still acceptable to use instance sed lines.

sudo sed -i "/^SYSOPNAME/c\SYSOPNAME='CALLSIGN Raspberry Pi EchoLink'" /etc/svxlink/svxlink.d/ModuleEchoLink.conf
sudo sed -i "/^LOCATION/c\LOCATION='[Svx] Mobile Raspberry Pi'" /etc/svxlink/svxlink.d/ModuleEchoLink.conf
sudo sed -i "/^DESCRIPTION/c\DESCRIPTION='SOME TEXT'" /etc/svxlink/svxlink.d/ModuleEchoLink.conf

The SYSOPNAME will appear at the top of the node's forum if using EchoLink interactively along with the LOCATION information. The DESCRIPTION option can also be a multiline, customized string for the node itself. For radio only users, these options will not be apparent to them.

At this point, a bare minimum configuration exists and SvxLink can connect to the EchoLink network.

Configuring Wireless Configuration

Your EchoLink node will be useless if the Raspberry Pi is not connected to the Internet. Fortunately, you only need to add one or two entries to the /etc/wpa_supplicant/wpa_supplicant.conf file to allow the Raspberry Pi to connect to your available WiFi stations. Add lines similar to the following but tailor them to match your own mobile hotspot or home network.

network={
        ssid="KD3BUG iPhone"
        key_mgmt=WPA-PSK
        psk="NotMyRealPasswordSilly"
}

EchoLink requires that inbound UDP ports 5198 and 5199 to your node are accessible. This can be a problem when some ISPs or modems prevent firewall configurations or port forwarding but EchoLink provides a workaround with a proxy. Assuming these ports are forwarded across your modem, the following firewall rules should be applied:

sudo iptables -F INPUT
sudo iptables -F OUTPUT
sudo iptables -F FORWARD
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -f -j DROP
sudo iptables -A INPUT -p tcp -m state --state INVALID -j DROP
sudo iptables -A INPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 5198:5199 -m state --state NEW -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
sudo iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
sudo iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
sudo iptables -A INPUT -j DROP
sudo iptables -A OUTPUT -o lo -j ACCEPT
sudo iptables -A OUTPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT
sudo iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A OUTPUT -p icmp -j ALLOW
sudo iptables -A OUTPUT -j DROP
sudo iptables -A FORWARD -j DROP

These rules allow for DHCP, SSH, reasonable ICMP, and the EchoLink VoIP traffic inbound along with any established connections. The rules allow unrestricted outbound traffic and prohibit traffic forwarding.

Configuring the Baofeng UV-5R

Setting up the Baofeng is pretty straightforward. Lift the rubber connector flap on the right side of the radio and insert the BTech APRS cable from earlier. The mic and speaker ports are sized differently so it is impossible to put the cable in wrong. Connect the other side of the BTech cable to the splitter and then connect the split mic and speaker lines into the USB soundcard's appropriate ports.

With the hardware setup, now configure the Baofeng radio's settings. These few settings should make the setup work for all future uses by simply by turning the radio on and dialing the volume knob up.

NOTE: It's possible to have the SvxLink software decode and embed the CTCSS codes or allow the radio to handle it in hardware. In my application, I configured the CTCSS codes on the radio and left them commented out (e.g. disabled) within SvxLink.

Running SvxLink

With the configuration files in place, running SvxLink is as simple as making sure the service is running leveraging standard systemctl commands like start, stop, and restart. For example:

sudo systemctl restart svxlink.service

To see any recent error messages related to getting the service itself running (as opposed to errors within the application), which will typically identify invalid settings in configuration files, utilize the following:

journalctl --no-pager -u svxlink.service --since "10 minutes ago"

Using EchoLink

You can keep track of what SvxLink is doing by watching the log file. This log file will inform you of connectivity to the EchoLink network, decoded DTMF tones, squelch setting, transmission status, etc.

tail -f /var/log/svxlink

The Baofeng radio is not the radio you will use for communication. It is only the RF connection serving to bridge client radios to the SvxLink software on the Raspberry Pi. As every radio is different for configuring and sending DTMF codes, that will be left as an exercise to the reader. The following table outlines a sample of default DTMF codes and their corresponding actions.

Troubleshooting DTMF

This is perhaps the most maddening part of the entire process. In order to successfully activate modules and connect to remote nodes, etc. the DTMF codes need to be properly interpreted. The easiest way to know what is working is to watch the SvxLink log file while performing actions to see decoded tones, opening squelch, or activating the transmitter. In the following examples, all the DTMF codes were sent from a Yaesu FT-5DR and an ICOM IC-705. As evident in the log output, SvxLink did not decode the 3, 6, A, B, C, or D tones for the Yaesu FT-5DR but did properly decode all of the tones from the IC-705. Use tail -f /var/log/svxlink to watch the log file live while testing features.

Sun Mar  3 23:55:27 2024: Rx1: The squelch is OPEN (5.09723)
Sun Mar  3 23:55:29 2024: SimplexLogic: digit=1
Sun Mar  3 23:55:31 2024: SimplexLogic: digit=2
Sun Mar  3 23:55:33 2024: SimplexLogic: digit=4
Sun Mar  3 23:55:34 2024: SimplexLogic: digit=5
Sun Mar  3 23:55:36 2024: SimplexLogic: digit=7
Sun Mar  3 23:55:37 2024: SimplexLogic: digit=8
Sun Mar  3 23:55:38 2024: SimplexLogic: digit=9
Sun Mar  3 23:55:39 2024: SimplexLogic: digit=*
Sun Mar  3 23:55:40 2024: SimplexLogic: digit=0
Sun Mar  3 23:55:41 2024: SimplexLogic: digit=#
Sun Mar  3 23:55:49 2024: Rx1: The squelch is CLOSED (7.12021)
Sun Mar  3 23:55:49 2024: Tx1: Turning the transmitter ON
Sun Mar  3 23:55:56 2024: Tx1: Turning the transmitter OFF
Sun Mar  3 23:57:35 2024: Rx1: The squelch is OPEN (4.38234)
Sun Mar  3 23:57:35 2024: SimplexLogic: digit=1
Sun Mar  3 23:57:35 2024: SimplexLogic: digit=2
Sun Mar  3 23:57:35 2024: SimplexLogic: digit=3
Sun Mar  3 23:57:36 2024: SimplexLogic: digit=4
Sun Mar  3 23:57:36 2024: SimplexLogic: digit=5
Sun Mar  3 23:57:36 2024: SimplexLogic: digit=6
Sun Mar  3 23:57:36 2024: SimplexLogic: digit=7
Sun Mar  3 23:57:36 2024: SimplexLogic: digit=8
Sun Mar  3 23:57:37 2024: SimplexLogic: digit=9
Sun Mar  3 23:57:37 2024: SimplexLogic: digit=*
Sun Mar  3 23:57:37 2024: SimplexLogic: digit=0
Sun Mar  3 23:57:37 2024: SimplexLogic: digit=#
Sun Mar  3 23:57:37 2024: SimplexLogic: digit=A
Sun Mar  3 23:57:38 2024: SimplexLogic: digit=B
Sun Mar  3 23:57:38 2024: SimplexLogic: digit=C
Sun Mar  3 23:57:38 2024: SimplexLogic: digit=D
Sun Mar  3 23:57:40 2024: Rx1: The squelch is CLOSED (7.11492)

For more troublesome radios, it might be necessary to tweak settings in a variety of locations. Within the svxlink.conf configuration, adjustments to the de-emphasis, pre-emphasis, pre-amp and various vox-twists are most relevant. For the soundcard itself, adjusting the mic gain with alsamixer may help - but can also introduce noise into the received voice later. Absolutely doublecheck the radio modulations match - e.g. Narrow FM in both the SvxLink connected Baofeng and the radio used for actually sending DTMF and talking.

After arriving at a setting that decodes your radio's DTMF tones, connect the EchoLink module of SvxLink to the test node at 9999. Send some audio through to make sure the audio adjustments did not distort the voice aspect of the setup and continue tweaking until both voice audio and DTMF decoding work together.

The audio sent by SvxLink can be "poorer" than what went in. One way to make sure the original audio was not the problem is to record it at the sound card and play back the .wav audio file. This can be done simply by deactivating SvxLink (to free up the audio device) and then using arecord to capture a sample from the receiving radio. If the resulting .wav file plays back fine, then any distortion is happening after the Baofeng and after the USB audio card within SvxLink.

sudo systemctl stop svxlink
arecord /tmp/sample.wav

Scripting SvxLink to be Self Healing

For a truly portable configuration, you're unlikely to have a keyboard and monitor attached to the Raspberry Pi. This simple script automatically adjusts the svxlink.conf file with the current USB audio card device and then starts the service if it's not running. Utilize a simple cron job to run on a periodic interval to keep SvxLink operating.

#! /bin/bash

varCARD=`arecord -l | grep card | cut -d " " -f 2 | cut -d ":" -f1`
sudo sed -i "/^AUDIO_DEV/c\AUDIO_DEV=alsa:plughw:$varCARD" /etc/svxlink/svxlink.conf

if ps -ef | grep "svxlink" | egrep -v "grep"; then
  printf "[*] ECHOLINK nominal\n"
else
  printf "[!] ECHOLINK missing\n"
  sudo systemctl restart svxlink
fi

Conclusion

This guide should get you 99% to your end solution. After setting everything up, I put everything into a Pelican 1200 case to hold the radio, cables, and Raspberry Pi. Combined with a 20000maH USB battery for the Raspberry Pi, the unit can easily run for nearly 12 hours, is easily transportable, and can be setup anywhere. de KD3BUG