InstallSrcHwRpiOld - sm0svx/svxlink GitHub Wiki

RELEASE_CFLAGS=-g -O2 -mfloat-abi=softfp -mfpu=vfp -mcpu=native

cmake -DCMAKE_C_FLAGS="-g -O2 -mfloat-abi=softfp -mfpu=vfp -mcpu=native" ..

Pinouts

Pi Power Button/LED

Audio connections (polarity doesn’t matter at the Easy Digi end):

Line connections:

Radio Pinout:

The power button was inspired by the need to gracefully shut down the Pi to avoid corrupting the SD card, and have a visual indicator to know if it was turned on or not. To that end, I borrowed from the Adafruit retrocade project; specifically an adaptation I found on philtopia.com: http://www.philtopia.com/?p=1823

I have the retrocade code (renamed to button-monitor) loading in rc.local and monitoring GPIO3:

It allows me to do a long press to trigger a shutdown (actually calling a bash script called system-down.sh) that flashes the LED and then calls a shutdown. A trick with GPIO3 is if it’s jumpered to Ground when the system is off, it will start the Pi, so the one button can be used for both startup and shutdown. The code I’m using in the shell script is:

A few notes about finding hardware info and testing:
First off, figuring out the actual HW. If you want to list the output devices, use aplay; if you want the input devices, use arecord:

The important part is the card # and the device #. In this case, 1 and 0. That’s where the -D value for arecord comes from (eg, -D hw:1,0). Since it’s the default capture, just hw:1 is also sufficient. A different sub-device would be necessary only if the sound card had more than one mic input. For another example, card 0 in my config has two output devices and NO capture devices. hw:0,0 is the 3.5mm jack and hw:0,1 is the HDMI audio output on the Raspberry Pi. Card 1 is the USB soundcard that we are using for in/out.

Using arecord, I was finally able to figure out an incantation to test that audio is making it into the device. All three of these will produce the same output:

-vv - make the display very verbose and include a VU meter at the bottom of the screen
-fdat - sets the format. shorthad for [-f S16_LE -c2 -r48000] (16 bit little endian, 48000, stereo)
-c1 - sets number of channels to 1 (mono instead of stereo). Overriding the -fdat+
-D hw:1 or hw:1,0 - uses the default capture device on card 1
-r48000 - bitrate of 48,000Hz

Any of these lines will result in the following recording settings:

svxlink can’t be running while you are testing because the sound device will be busy and arecord will fail: "arecord: main:682: audio open error: Device or resource busy"

This is a collection of issues that I hit during the setup process. I tried to document the specific issue and also the fix to the issue.

**Compile Problems:
NOTE: Most of these are not an issue if you READ THE INSTALL DOCS COMPLETELY FIRST.

it puts everything in /usr/local - if this isn’t what you want (probably not), then change cmake:

missing libs - svxlink: error while loading shared libraries: libasynccpp.so.1.3:

checking with ldd:

a simple ldconfig after the compile fixed this one

missing QT - You have two options for this one, install qt4-dev-tools if you need it, or add -DUSE_QT=NO to your cmake flags if you don’t. If you aren’t going to use the GUI client Qtel, you don’t need it. Removing it will probably save some compile time, too.

make doc fails - install groff first. Might need Doxygen too, but it compiles without it (and Doxygen is 1GB of stuff you don’t need on the SD card, anyway)

TK errors - cmake generates the following. It’s unclear if it’s a problem (it compiles fine). This shouldn’t happen if you install the tcl-dev and tk-dev packages
 — Could NOT find TCLTK (missing: TK_LIBRARY TK_INCLUDE_PATH)
 — Could NOT find TK (missing: TK_LIBRARY TK_INCLUDE_PATH)

Audio HISS in repeater RF audio - This one is really making me nuts. For whatever reason, the PM400 has a very noticeable hiss at around 5kHz. I’m attempting to install the alsaequal equalizer plugin to see if I can pre-process the signal coming in through the alsa device. I have no idea if I can make it work. Steps to configure - apt-get install libasound2-plugin-equal edit .asoundrc file

+

+ This appears to work backwards: pcm.equal → pcm.plugequal → ctl.equal I still need to understand exactly how the plugin arch works. Getting closer. figured out that the syntax for referencing the plugin is alsa:equal, not alsa:plughw:equal but using it for Rx1 results in a hung system after the first time audio comes in. Another angle is to use a hardware Eq. I’ll probably try running it through my old stero Eq as a test.

UPDATE: Still not fixed, but usable. At this point, just accepting that there’s some noise and living with it.

Audio beep during TX - This appears to be the same issue outlined here: http://svxlink.996268.n3.nabble.com/Beeps-in-received-audio-td3088.html "It’s a new feature which was newly added. A beep is added when a remote EchoLink transmission stops. You probably are experiencing dropped UDP packets from the remote station. If SvxLink does not receive audio for 200ms it will interpret this as if the remote transmission has ended." The fix for this is to do a local overlay replacement for the is_receiving proc in the EchoLink Tcl module in /usr/share/svxlink/events.d

audio coming into the Pi from the radio, but not going out the internet - No idea what’s up with this issue yet. doing a tcpdump shows the software isn’t even trying to send. Everything else works (inet → repeater, inet → inet).

FIXED - Use SimplexLogic instead of RepeaterLogic. The basic issue is RepeaterLogic assumes a hard-linked repeater connection rather than a remote-link connection as described on the Echolink site. As a result, svxlink wants to retransmit back out to the repeater, rather than send the received audio out the internet.

stopping TX on open squelch - I don’t want svxlink keying up over top of someone on the repeater and doubling. Need to see if there’s an option to disable this. I know something exists for one type of usage, but I don’t know if that’s globally available.

FIXED - since we are switching to SimplexLogic instead of RepeaterLogic, the default is to do this for us already. There’s going to be doubling, but nothing worse than what you already deal with. What’s important is that it doesn’t step on someone that’s already TXing on the repeater. The variable that addresses this is MUTE_TX_ON_RX=1 (which is enabled by default).

System goes into endless TX when svxlink is shut down - We need to be careful to turn off the link radio when the software is shut down. The voltage on RTS triggers an endless PTT otherwise. We might need to script something to monitor the status (ie, if no svxlink, set the RTS pin).

FIXED - Use GPIO instead. When the software shuts down, it doesn’t reset the pins the same way the serial connection does, so we don’t have the same risk. It’s still a good idea to script it so it disables the port explicitly and also that we set up a watchdog so that if the pin is high and svxlink is not running it shuts it down as well. That will help protect against crashes of the software while it’s TXing.

Incoming audio is clipped. - The squelch is too sensitive and cuts off RF audio whenever someone pauses to breathe. Need to find a setting to make it more forgiving.

FIXED - Since we are using SQL_DET=VOX for RF audio coming in, there’s no reason to be picky about the VOX_THRESHOLD. As a result, I just turned the threshold down (currently VOX_THRESHOLD=200) so that it fires when anything comes in (including what’s basically dead air). In other words, if there’s any RF audio at all, we want to relay it.

REALLY FIXED - I switched to using SQL_DET=GPIO and am reading the CSQ pin from the radio to tell when a signal is coming in. This is a lot more reliable than using VOX. It does mean, however, that the link will trigger on the squelch tail now. I have an issue opened to get SQL_START_DELAY to apply to CSQ over GPIO to fix this (issue137).

spurious connection issues - It’s common for incoming connections to have issues and throw messages about mismatched IP addresses. This is a caching issue with how mobile clients change their IP addresses because most of them use relays and don’t connect directly. As a result, they often end up connecting from a new address every time they start up. A possible fix may be to script to restart if no connections exist to flush the cached data.

FIXED (in testing) - git issue93 covers this with a software fix that isn’t in the master branch yet. I’ve been running on the issue93 branch which successfully deals with the problem. This should work once it’s put in the master branch.

REALLY FIXED - The code change has been put into the master branch and has worked great. It sometimes takes a few extra seconds to connect, but it does work.

audio connection failing (locking up) - This looks like it is probably the issue of not enough power to the USB sound card. I’ve switched to using the Pi2 and GPIO for PTT instead of the Serial port. I’ve also added the following to the /boot/config.txt, which is supposed to supply more power to the USB ports:
max_usb_current=1

FIXED (ish) Update: Power doesn’t seem to be the problem. I’ve run on the Pi2, used an external powered USB hub and that hasn’t helped. What did help, though was disabling the QSORecorder. It’s not clear yet why this makes a difference, but I’ve had no issues for several days after turning off recording. For now, it’s just going to have to be a voodoo thing and keep it disabled.

REALLY FIXED: This turned out to be an issue with running out of disk space for storing the wav files. Two things fixed this: 1. more closely monitoring disk and not letting it fill up. 2. code updates in the source that more gracefully handle if the disk does fill up.

Using GPIO has its own challenges: You need to enable the port, set the direction of flow and match it on the svxlink config side (the useradd -G gpio takes care of this): add svxlink user to the gpio group

I actually prefer using GPIO because you have better control over the PTT (see System goes into endless TX when svxlink is shut down)

The default svxlink.conf has an incorrect variable that the system complains about on startup:

Another way to start svxlink at boot

You need to wait some time after boot for Pi to initialize devices. It will not work when you start svxlink immediately after the boot, the process will run but there will be no access to PTT. Open /etc/rc.local and add this two lines at the end of the file, before exit 0

This will start svxlink 2 minutes after boot.