Scan mode speed

[spotter-ssol]

Currently I'm running RTLSDR-Airband in scan mode on a RPi2. Due to the scan speed currently achieved, I've found that number of channels should not exceed a certain quantity or it will start to miss significant parts os messages. What limits the scan speed? Hardware (dongle, RPi), software or both? An upgrade to a RPi3 would bring a significant improvement into scan speed?

[szpajder]

Scanning speed is hardcoded to 5 frequencies per second. Increasing the speed would mess up the squelch.

I tried to rework the squelch code to make it faster, but I haven't got a significant improvement - just approx. 8-10 channels/sec. Retuning the dongle takes time.

[spotter-ssol]

Can you upload your new code to unstable branch for testing? 8-10 channels/s sounds great!

[szpajder]

Not yet - it's so broken that it does not even deserve the name "unstable".

[elad661]

Retuning the dongle takes time.

Maybe you can group frequencies that are in the same 2.4Mhz range (the bandwidth of RTL-SDR dongles) and use frequency offset instead of re-tuning the hardware frequency, just like you support listening to multiple channels on multichannel mode.

[szpajder]

Yes, provided that a particular set of frequencies can be grouped, this would improve speed somewhat.

But is doesn't change the fact that currently we are heavily optimized for multichannel mode with the lowest possible CPU usage on the Raspberry Pi (which is currently the most common HW platform among LiveATC feeders who use rtl_airband). One of the tricks we use is aggregating input samples in large batches in order to calculate many FFTs in one shot using the GPU. This is good for speed, however it introduces a processing delay. When the channel power gets calculated and the squelch decides that it should open and stop scanning, it is too late because the scanner has already moved to the next frequency. We could reduce the batch size to reduce latency, however it would incur a performance penalty (ie. the dongle count that the box is able to handle would be reduced).

As I wrote earlier, I have done some experiments on this, but the results were not too compelling, so I have put this topic aside to do other stuff (stream mixing feature, in particular). The scanning mode was just a quick hack, but it seems there is quite a bit of interest in this feature, so it deserves a rewrite.

[bluepup]

I'd like to watch a 200kHz part of the spectrum with 16 Channels. The Limitation will be the raspberry, so I think. It would be great if I could watch one or two channels permanently and "scan" the other channels. All channels could be monitored by one rtlsdr because tuning is not necessary. But I can't at the moment specify to record all channels as far as I know and give priority so that only x simultaneous recordings are made because of raspberry resources, or what happens when too many channels are active?

[szpajder]

The number of simultaneous channels per device is currently limited to 8, however rtl_airband will eventually support wideband SDRs like Mirics (SDRPlay). The number of channels per device will then be increased (not only for Mirics, but for rtl-sdr as well). At that point you will be able to configure 16 channels per dongle (or possibly even more). It might be problematic for RPi v1, however RPi v2 or v3 (ie the quad-core versions) should be able to handle this (although I haven't yet tested it). Adding an additional channel does not make a huge difference to CPU usage due to the channelization method used by rtl_airband (see https://github.com/szpajder/RTLSDR-Airband/issues/57 for further explanation of why things work as they do).

200 kHz of bandwidth is not an issue, as you already have a fixed bandwidth of 2.56 MHz on on rtl-sdr.

[bluepup]

Thanks for the hints. This is really great. BTW what is the with of nfm demodulation? I have some crosstalk on neighbouring channels. A channel is 12,5-kHz wide. Can I change the width in configuration or source?

[spotter-ssol]

200 kHz of bandwidth is not an issue, as you already have a fixed bandwidth of 2.56 MHz on on rtl-sdr.

I know that 2.56MHz it the maximum bandwidth that the rtl dongle is capable to use without losing samples. But, is it possible (without too much hassle in the code) to use a bigger bw (like 2.8MHz)? Just curious.

[szpajder]

Currently no. This program is actually a giant ball of hacks which make it possible to run on the Pi without killing its CPU, however there is a tradeoff - it's not very flexible.

In a while I'm going to restructure the code a bit to make it possible to add support for other SDRs than RTL, so if you are looking for a larger bandwidth, you may expect Mirics/SDRPlay to become available in rtl_airband in some time, with its 8 MHz of bandwidth. However it may happen that some RPi-related optimizations might need to be dropped to make this possible. I need to experiment on this topic a bit.

[bluepup]

It seems that writing all 8 channels continuous as well as non-continuous causes the audio to miss some samples. Looking at a continuous file which should have a recording time of 1 hour contains only 47 or so minutes. Listening to the audio shows that there are milliseconds missing from the speech. The recording sounds chopped, speech has missing or chopped "characters" or even words both in continuous as well as non-continuous files.. I'm using a Pi B+ shightly overclocked, which might be too slow. Haven't checked syslog yet.

[szpajder]

Version 3.0.0 has SoapySDR support, so it shall be possible to use any SDR for which there is a Soapy plugin available. Sampling rate is configurable per device, regardless of used driver. Refer to the docs here and here.

Regarding crosstalk on neighbouring channels - if they are really close to each other (ie. closer than 20 kHz), then not much can be done about it. However version 3.0.0 supports configurable sampling rate and FFT size, which can help in such cases to some extent. See alse here.

[charlie-foxtrot]

Scan speed may be increased by #370