NFM support

[jonathanfmorgan]

Would it be possible to add narrowband FM support into the app? I'm interested in using the app to monitor the rail frequencies (http://wiki.radioreference.com/index.php/Current_VHF_Railroad_Frequencies), which all fit nicely within 2.5 MHz.

[szpajder]

Yup, I already have this feature on my TODO list.

[jonathanfmorgan]

Great - thanks!!

[jonathanfmorgan]

Hi szpajder. Any update on NFM support?

[szpajder]

Work is in progress, I'll let you know when it's done (or at least usable). Keep this issue open.

[k1mgy]

We'd very much like to use this tool to record multiple radio channels (NBFM) of a large public event. I can help add the FM mode feature with a little guidance. Would this be possible to arrange?

[szpajder]

I already have a working proof of concept, but it's not usable yet, because the squelch does not work. I have to rewrite it from scratch. Recently I've been quite occupied with other tasks, so I haven't made a lot of progress during last month, but I think I'll manage to get something usable in March, or so.

[k1mgy]

Tomasz,

Thank you so much.

If I can be of any help, just send me into the code as you may direct.

I'm looking also at Ham2Mon (https://github.com/madengr/ham2mon) which
appears to have the needed features, but I haven't tested it yet to confirm.

/mark richards
K1MGY

On 2/18/2016 08:14, Tomasz Lemiech wrote:

I already have a working proof of concept, but it's not usable yet,
because
the squelch does not work. I have to rewrite it from scratch. Recently
I've
been quite occupied with other tasks, so I haven't made a lot of progress
during last month, but I think I'll manage to get something usable in
March, or so.

Untitled Document
Mark Richards
29 Juniper
Littleton, MA 01460
617 592 4392
[email protected]
[email protected]

[szpajder]

NFM support has arrived.

There is no release yet, however it's already pretty usable - you may grab the unstable branch (go to https://github.com/szpajder/RTLSDR-Airband/tree/unstable and hit "Download ZIP" or git pull the branch) and test it.

How to use it?

Just put a line:

modulation = "nfm";

in the appropriate channel section (for example just before or below freq line).

You can also adjust the de-emphasis filter (ie. high-frequency noise rejection) by tweaking a global tau parameter. The higher the value, the more high frequency band gets attenuated. Refer to rtl_airband.conf.example for examples.

You may notice higher CPU utilization than before, even when not using NFM. This is because the sampling rate has been changed from 8 to 16 kHz. It seems it is not possible to demodulate NFM correctly with 8 kHz sample rate. I will work on further optimizations, though.

[jonathanfmorgan]

I've been testing it and it is working great so far. Thanks!

[szpajder]

I've noticed that the auto squelch seems to be opening fairly often when
there is no signal there. I'm running a conventional scanner simultaneously
and it's not hitting a signal, while RTLSDR-Airband will broadcast just
static for a few seconds. They are both running off the same antenna. I'm
using auto-gain, if that makes a difference.

Try setting the gain manually. RTL auto-gain is not a perfect one.

Start with a value like eg. 20 dB and launch rtl_airband with -f option. It
will run in the foreground and show you simple textual waterfalls. The
first number in the waterfall is the signal strength, while the second one
is the noise floor. Adjust your gain, so that when the squelch is closed,
the signal level is stable (it varies only very slightly, like +- 1 or 2)
and it's more or less equal to the noise floor. So for example, when the
squelch is closed, you should be seeing something like 20/18 or 12/11, but
definitely not 60/30 with the first number varying wildly. If your noise
floor is a single-digit number, you can probably increase the gain safely.

The squelch opens when the signal level exceeds the noise floor by a factor
of 3 for a small amount of time. I think I could even set the threshold a
bit lower for NFM, because it happens that even weaker transmissions are
sometimes perfectly audible. For example, during my tests rtl_airband was
often able to catch transmissions from handsets of train crews on a rail
station several kilometers away. That's the advantage of NFM, as compared
to AM.

I could make the squielch threshold configurable, however it would probably
be of any use only in come corner cases, like high-interference environment
or really poor or distant transmitters. Tweaking the gain is simply
sufficient in most cases.

Regards and thanks for your feedback.

[jonathanfmorgan]

That helped a lot. Thanks.

I was running two dongles doing nfm scanning. It seemed like the streaming got very choppy. In VLC, the stream time would stop and the yellow buffering bar would appear on both streams. I haven't seen this happen when only doing one nfm scan.

[szpajder]

Probably the CPU gets saturated. What kind of hardware platform are you using?

[jonathanfmorgan]

Raspberry Pi 2 Model B. When I ran htop the CPU didn't appear to be maxed out.

[szpajder]

It seems that for some reason it is unable to output samples with the requested speed. Either due to CPU or GPU load. As I mentioned earlier, with NFM I had to increase WAVE_RATE and MP3_RATE from 8000 to 16000. You may try to revert it back (just change the two #define lines in rtl_airband.cpp and recompile). It will definitely make a difference to CPU load, but as far as quality is concerned, your mileage may vary. From my experience, 8000 is too low for NFM - there is a lot of aliasing and the sound gets unbearably distorted when somebody speaks loudly (ie. when the frequency deviation is at its maximum). However, different FM radio systems may use different deviation values, so It may happen that 8000 will work OK for the channels you are listening to. My plan is to make WAVE_RATE configurable (at least at compilation time), because AM-only users would not be happy about severe performance degradation introduced by a feature which they don't use. If sample rate of 8000 does not work for you, then I'm currently out of ideas. It might be that RPi is simply not beefy enough for the task.

[spotter-ssol]

I could make the squielch threshold configurable, however it would probably
be of any use only in come corner cases, like high-interference environment
or really poor or distant transmitters. Tweaking the gain is simply
sufficient in most cases.

If you could make the squelch threshold configurable it would be great!

[hhopjh]

I could make the squielch threshold configurable, however it would probably
be of any use only in come corner cases, like high-interference environment
or really poor or distant transmitters. Tweaking the gain is simply
sufficient in most cases.
If you could make the squelch threshold configurable it would be great!

I'm also interested in configurable squelch threshold.

[jonathanfmorgan]

Do you know what might be causing the clicking? I don't hear it when listening to AM. I also don't hear it when listening to this freq on a regular scanner. Recording:

https://db.tt/hlGi5zCZ

[szpajder]

These regular clicks every half a second - it's probably some bug which I yet have to trace.

Generally, the click in FM occurs when the signal phase shifts by a random amount due to noise. This is common when the carrier signal level is weak. In AM we don't pay attention to the phase, because the signal is encoded in the amplitude of the carrier. Therefore, random phase shifts do not cause clicking in AM.

FM is one of these things which are simpler and better done in analog domain than in digital, so the scanner will always be better for that purpose (especially that in rtl_airband we simplify things a bit to get better performance on the RPi).

Your audio sample has a non-zero DC offset. Please pull the latest code from unstable branch, which has this issue fixed. You may also try the (not yet documented) -Q command line option for FM, which enables a different demodulation algorithm (quadri correlator instead of standard, atan2-based one). It's a little easier on the RPi's CPU and it should also click less often.

[jonathanfmorgan]

Thanks! I'll give it a try.

[khuopio]

Suggestion: add bandwidth option to NFM channels. A 12.5 kHz channel is getting very noisy on a regular 25 kHz channel filter.

Thanks for a great tool!

[szpajder]

There is no channel filter in rtl_airband, because it does not use direct channel selection / demodulation. Input signal is channelized with FFT - each FFT bin represents a single narrowband channel. The bandwidth is determined by sample rate and FFT size. It can't be set individually for each channel. We are aiming for the best possible performance on low-power platforms (like RPi), so things need to be simplified as much as possible.

If you have noisy audio, first make sure your PPM setting is correct (use SDRSharp, tune the dongle to some known frequency and adjust PPM until the channel spike is exactly centered, then copy the PPM setting to your config file). Then you may try to increase the tau parameter in the config file, which will make the FM deemphasis filter more agressive (it will cut off more high-frequency noise).

[szpajder]

If you could make the squelch threshold configurable it would be great!

I'm also interested in configurable squelch threshold.

Manual squelch setting is now implemented (commit b8c2686). Please pull latest unstable branch for testing (https://github.com/szpajder/RTLSDR-Airband/tree/unstable).

See also #23 (comment)

[szpajder]

NFM is now implemented in stable release 2.1.0.

Closing.