Troubleshooting

• Visualizing RF spectrum
• Problems on startup
  • Program terminates without printing any errors
  • "Unable to enable V3D. Please check your firmware is up to date."
  • "Can't open device file /dev/vcio: No such file or directory"
  • "Can't open device file /dev/vcio: No such device or address" or "mbox_property(): ioctl_set_msg failed: Inappropriate ioctl for device"
• Problems on exit
  • "rtlsdr_demod_write_reg failed with -1"
• Problems during program run
  • Audio bleeding between channels
  • Audio speed is wrong
  • Can't use four RTL dongles simultaneously (aka "Failed to submit transfer 12!")

Visualizing RF spectrum

There are several programs that will display a waterfall of the RF spectrum and can be used to verify settings and troubleshoot issues.

SDR++ is one example that runs on multiple platforms and supports most SDRs. Either running directly on the machine with the SDRs or using rtl_tcp (or equivalent) will assist in setting the gain, PPM offset, and looking for imaging / aliasing issues. NOTE - Streaming raw SDR data requires a lot of network bandwidth, so a local wired connection is preferred.

Problems on startup

Program terminates without printing any errors

Errors related to configuration parsing are printed to standard error (so they appear on the terminal when you run the program by hand). After the configuration file has been parsed successfully, all subsequent diagnostic messages are logged to system logger (syslog) by default - both in foreground mode (in order not to clutter the textual waterfalls) and in background mode (because there is no longer a terminal to be written to). So if the program terminates, but no error message appears on the screen, it means that your config has been parsed successfully but there was an error at a later stage (like when the SDR device was about to be initialized). So to put it short: read the logs (see here for more info on where they go). Or rerun the program by hand with -e option to force logging to standard error.

"Unable to enable V3D. Please check your firmware is up to date."

Most probably you are trying to run the program compiled with VideoCore IV GPU support on a platform which does not have this GPU chip onboard. VideoCore IV is present on Raspberry Pi v1, v2 and v3 only. Raspberry Pi v4 has VideoCore VI which is completely different and not supported. Only non-accelerated version of RTLSDR-Airband can be used on RPi v4 (ie. built with PLATFORM=armv8-generic option). See here and here for more information.

Other causes of this include:

• 64-bit OS (the GLES driver is not supported on 64bit OSes see here

• hello_fft (the GPU based FFT) is not supported with either dtoverlay=vc4-kms-v3d or dtoverlay=vc4-fkms-v3d set in /boot/config.txt, if either is set, comment it out and reboot see here

• The default CPU:GPU memory split is lower than 64 MB. Check your /boot/config.txt and remove the gpu_mem setting altogether, if it's there. Then save the file and reboot the Pi.

"Can't open device file /dev/vcio: No such file or directory"

You need to create /dev/vcio device node (it is used to access Broadcom Videocore IV GPU device). To do that, you need to know the correct major number. Older Raspbian kernels (before 4.0) used 100, newer ones use 249, so first check that:

pi@mypi:~$ grep vcio /proc/devices
249 vcio

This means /dev/vcio must be created with a major number of 249:

sudo mknod /dev/vcio c 249 0

In other case, substitute 249 with the number taken from grep output above.

"Can't open device file /dev/vcio: No such device or address" or "mbox_property(): ioctl_set_msg failed: Inappropriate ioctl for device"

This means you have /dev/vcio, but its major number is probably wrong:

pi@mypi:~$ ls -l /dev/vcio
crw-rw---T 1 root video 100, 0 Jan  1  1970 /dev/vcio

This one was created with a major number of 100. grep vcio /proc/devices shows the correct number - if it's different, then delete it (sudo rm /dev/vcio) and create it again (see previous section).

Problems on exit

"rtlsdr_demod_write_reg failed with -1"

When terminating the program (eg. with ctrl+c) the program crashes with Segmentation fault or errors like these:

r82xx_write: i2c wr failed=-1 reg=1a len=1
r82xx_set_freq: failed=-1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -7

This is a bug in libusb versions older than 1.0.17. Upgrade to a newer version.

Problems during program run

Audio bleeding between channels

Sometimes you may experience channel crosstalk, ie. a situation where an unwanted signal interferes with your channel of interest. There may be several causes of this problem.

Strong signals present nearby or gain set too high

When the gain is set too high, a wideband receiver can get saturated by unwanted strong signals. You can observe this with any SDR console (like SDRSharp, GQRX, etc), and a RTL dongle tuned to VHF airband. When the gain is cranked up too much, you will most probably see ghosts of broadcast FM stations in the spectrum. If any of these artifacts coincides with a frequency of your channel of interest, RTLSDR-Airband will pick it up (this holds true for any strong signal, not only FM stations). Try reducing the receiver gain to a level where artifacts disappear and check out if it helps. If the interfering signals are really strong, you may find out that it's not possible to eliminate them this way, because the gain has to be lowered so much, that it's no longer possible to receive your desired channel. In this case it might be necessary to add an appropriate notch or band-pass filter in the antenna feed line before the SDR to get rid of the interference before it reaches the receiver.

Aliasing artifacts at high sampling rates

Some SDRs do not perform well when working at the extremes of their supported sampling rate ranges. RTLSDR-Airband uses 2.56 Msps as the default sampling rate on RTL devices, which usually works fine in most cases. However, if there are strong signals present in the dongle bandwidth, you may see things like this:

Here there are two strong digital transmissions just above 170.2 MHz and a couple of their copies on both sides. These are unfiltered aliasing products. If any of these coincides with frequency of your channel of interest, you will hear it in the audio produced by RTLSDR-Airband.

If you don't need full 2.5 MHz of bandwidth, try reducing sample rate a bit. Here is the same chunk of spectrum, but with a rate reduced to 2.4 Msps. No more artifacts!

Crosstalk between two very close channels

Channel resolution is mostly determined by the FFT size, which is 512 by default. If it's set too low, then two close channels will blend into one. If it's too high, the channel of interest might get clipped (because it won't fit in a bandwidth of a single FFT bin) and audio will be garbled. Increasing FFT size also increases computational overhead. When running on a Raspberry Pi you may find out that running two RTL dongles with NFM enabled and FFT size cranked up to 1024 causes choppy audio. This is because the performance of the RPi GPU is not sufficient to do 32000 FFTs of size 1024 per second.

To fix the problem, try the following:

• increase FFT size by a step or two (provided that your hardware has the necessary horsepower),
• increase the gain a bit. It might sound strange at first, but this will effectively desensitize the squelch by some amount and you may find out that it's enough to cure the problem, because squelch will no longer open on a (weak) crosstalk signal.

Audio speed is wrong

Most probably the sampling rate configured on the SDR device is different than the program thinks it is. It may happen with devices which do not support arbitrary sampling rates, like Airspy. The problem is that the Airspy library does not return an error on an attempt to set the device to a non-supported sampling rate, so the application thinks that everything went fine, while it didn't. Comment out or remove sample_rate setting from the device section - RTLSDR-Airband will automatically pick a sampling rate out of the list of rates supported by the device, which should make the problem go away. If you want to run the device at a non-default sampling rate, make sure it's actually supported by the hardware (RTLSDR-Airband does not verify this).

Can't use four RTL dongles simultaneously (aka "Failed to submit transfer 12!")

When running four or more RTL dongles, it may happen that three dongles work fine but the forth (and fifth, and sixth...?) one doesn't - waterfalls for it do not update, no audio is produced from its channels. Pretty often an error message "Failed to submit transfer 12!" is logged (the number at then end may vary).

The solution which most often helps is to reduce the number of USB data buffers allocated for each dongle. There is a buffers option for that, which sets the number of buffers for respective device. See Configuring RTLSDR devices for description and syntax.

Note that running four RTL dongles on a Raspberry Pi puts it close to its performance limits. This platform has only one USB controller to handle all USB ports and its bandwidth is shared with Ethernet controller. If you don't need full 2.5 MHz of bandwidth on all dongles, try reducing their sampling rates.