Simple Ham Radio FM receiver with rtl-sdr

[Efcis]

Inspired by http://www.reddit.com/r/RTLSDR/comments ... er_rtl_fm/ , I tried to use my current DVB-T dongle and the raspi, as a first project.

After a succesful compilation of rtl_fm (I can elaborate, if needed), I'm currently facing various issues for a "complete" FM receiver.

1/ As "play" (from the sox package) can't find any default device (how to set that ?), I used aplay instead from the ALSA package. After much testing it appears the current sound driver (and/or aplay) only accept raw files sampled at 44100 and 48000 Hz. When using other sampling rates files, aplay doesn't complain, no sound is output, the raspi just hangs, and a reboot is required. I guess it is a sound driver bug (or a limitation ?).

2/ Thus, I used the 44100 sampling rate (a bit wide for NBFM), but it only works few seconds before hanging.

Code: Select all

rtl_fm -f 144800000 -s 44100 -g 9 -l 10 - | aplay -t raw -r 44100 -c 1 -f S16_LE

(-l 10 ensures I can hear the FM background noise).

There are some indications of underrun, which mutes the audio for few milliseconds, and few seconds after, no more sound, no more network (I'm using SSH for now), and a reboot is required.

I'm using the 2012-07-15-wheezy-raspbian image.

If you own a DVB-T dongle and you are more proficient in linux that me, please try it and report your results !

Larry - F6FVY

[Efcis]

Few indications on my progress :

The ALSA thing can't handle for now sampling rates different from 44.1 kHz and 48 kHz. There is a dedicated thread on this issue in the Raspbian forum. Check here. For the record, I'm currently using the analog (jack) audio output. Maybe it differs with the HDMI output.

I also faced a power voltage issue. When the DVB-T dongle was hooked up, and one software of the rtl-sdr repo was running, the voltage between TP1 and TP2 could decrease under 4.7 volts. I thus decided to use another PSU, which was delivering a better voltage under these conditions. I now rather have between 5.3 and 5.4 volts, and things are getting much better.

Nevertheless, I'm still experiencing constant audio drop outs (every 5 seconds or so), despite using a sampling rate of 44100 Hz. I get "underrun" error messages in the console. I guess they are output by aplay ?

Code: Select all

pi@raspberrypi ~/rtl-sdr/src $ ./rtl_fm -f 144800000 -s 44100 -g 9 -l 0 - | aplay -t raw -f S16_LE -r 44100 -c 1
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN:

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Elonics E4000 tuner
Oversampling input by: 23x.
Oversampling output by: 1x.
Buffer size: 8.08ms
Tuned to 145053575 Hz.
Sampling at 1014300 Hz.
Exact sample rate is: 1014300.020041 Hz
Tuner gain set to 9.00 dB.
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
underrun!!! (at least 0.264 ms long)
underrun!!! (at least 0.178 ms long)
underrun!!! (at least 0.092 ms long)
underrun!!! (at least 0.529 ms long)
underrun!!! (at least 0.141 ms long)
underrun!!! (at least 0.052 ms long)
underrun!!! (at least 0.625 ms long)
underrun!!! (at least 0.404 ms long)
underrun!!! (at least 0.313 ms long)
^CAborted by signal Interrupt...
Signal caught, exiting!

User cancel, exiting...
Signal caught, exiting!
pi@raspberrypi ~/rtl-sdr/src $

For the record, the CPU load is around 20% for a 44100 bandwidth demodulation. Once we will be able to use sound samples with a lower sampling rate (11025 is enough for NBFM), it should decrease a bit.

To be continued...

Larry - F6FVY

[kadamski]

5.3 V is out of spec too. So now you have to much voltage! As for underruns, it is possible that rtl_fm is just not able to deliver sound fast enough. There may be some buffering issues - it may buffer too much data before sending it to stdout and aplay has no data to play, thus underrun messages.

[Efcis]

I'll try to find a Schottky diode to lower the overall voltage and keep it "nominal".

Meanwhile I modified the rtl_fm.c code a bit, and tried several 'capture' rate (from 1Msps to 2.4 Msps), for a given output rate (24k). Quite strangely, the underruns are less frequent with a higher capture rate, while the CPU load is higher :

Capture set at 1 Msps - Output rate 24k (CPU load 15.7 %) -> Underrun every 14 sec
Capture set at 2 Msps - Output rate 24k (CPU load 27.4 %) -> Underrun every 22 sec
Capture set at 2.4 Msps - Output rate 24k (CPU load 31.3%) -> underrun every 25 sec

I ordered several different audio USB dongles, and will check if it makes any difference with the built-in audio output.

To be continued...

[jbeougher]

Could you post how you built rtl_fm on your rpi?

[M0RBD]

Could you post how you built rtl_fm on your rpi?

Follow the instructions here:

http://sdr.osmocom.org/trac/wiki/rtl-sdr

[M0RBD]

I'll try to find a Schottky diode to lower the overall voltage and keep it "nominal".

Meanwhile I modified the rtl_fm.c code a bit, and tried several 'capture' rate (from 1Msps to 2.4 Msps), for a given output rate (24k). Quite strangely, the underruns are less frequent with a higher capture rate, while the CPU load is higher :

Capture set at 1 Msps - Output rate 24k (CPU load 15.7 %) -> Underrun every 14 sec
Capture set at 2 Msps - Output rate 24k (CPU load 27.4 %) -> Underrun every 22 sec
Capture set at 2.4 Msps - Output rate 24k (CPU load 31.3%) -> underrun every 25 sec

I ordered several different audio USB dongles, and will check if it makes any difference with the built-in audio output.

To be continued...

Have you tried using rtl_sdr and stream to a remote machine? Do you get buffer under-runs/crashes as well? It seems to be more stable if I do the other way around with my card both under rtl_sdr and rtl_fm. I.e lower the sampling rate.

I'm having this card btw http://erewhon.superkuh.com/gnuradio/rt ... _DVB-T.jpg

[Efcis]

Could you post how you built rtl_fm on your rpi?

Follow the instructions here:

http://sdr.osmocom.org/trac/wiki/rtl-sdr

FYI, I just did :

Code: Select all

sudo apt-get install git libusb-dev libusb-1.0 libtool cmake

to install requirements (I'm using raspbian and use the beta "alsa sound driver" - check this)

Hope this helps

[jbeougher]

How did you get gnuradio build? I'm am having trouble building that on the rpi.

[Efcis]

I haven't build gnuRadio personally (rtl_fm is standalone), but there are instructions here

[Efcis]

Have you tried using rtl_sdr and stream to a remote machine? Do you get buffer under-runs/crashes as well? It seems to be more stable if I do the other way around with my card both under rtl_sdr and rtl_fm. I.e lower the sampling rate.

Actually, I don't have another linux machine at hand. I guess my best bet would be to install one in a VM with VirtualBox on my Win machine, and run rtl_fm on it, aplay on the Raspi, and link them with a ncat (for example) between them. Or the opposite.

[Efcis]

I finally installed Ubuntu into a VirtualBox VM on my Windows machine.

rtl_fm doesn't work much better on it than my previous experiments with the raspi. I still get constant underruns, while the CPU load of rtl_fm is only around 3% on it. A bit disappointing...

I also tried to run rtl_fm on the raspi and sent the demodulated output stream data to Ubuntu, running aplay, thru a ncat connection. Same failure. And finally, the opposite (rtl_fm on the Ubuntu VM and aplay running on the raspi) doesn't help.

I'm still puzzled by these results. I even tried various options on rtl_fm (rate, quality FIR, "high speed arctan"...) with no difference.

To be continued...

[M0RBD]

I finally installed Ubuntu into a VirtualBox VM on my Windows machine.

rtl_fm doesn't work much better on it than my previous experiments with the raspi. I still get constant underruns, while the CPU load of rtl_fm is only around 3% on it. A bit disappointing...

I also tried to run rtl_fm on the raspi and sent the demodulated output stream data to Ubuntu, running aplay, thru a ncat connection. Same failure. And finally, the opposite (rtl_fm on the Ubuntu VM and aplay running on the raspi) doesn't help.

I'm still puzzled by these results. I even tried various options on rtl_fm (rate, quality FIR, "high speed arctan"...) with no difference.

To be continued...

I have to admit I have not tested rtl_fm on my PC...

However, I got completely different results with the onboard USB2 card and an external card when using rtl_sdr on the same machine. I'm going to recompile libusb with debug log on this weekend to see whether it will shed some light on the matter. I believe it boils down to either libusb or the hw used.

That said, there appears to have been some regression introduced into libusb after 1.0.8 especially if using SDR and gnuradio, here is a post regarding that: http://www.libusb.org/ticket/131

[Efcis]

Just received today one of the USB dongle I ordered. Unfortunately, as a Linux / Rasbian newbie I can't find how to use it with aplay or even the plain speaker-test utility.

I *guess* the name of the device to use is "front" (no quotes), according to the aplay -L command :

Code: Select all

 pi@raspberrypi ~/dvpt/rtl-sdr/src $ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
sysdefault:CARD=ALSA
    bcm2835 ALSA, bcm2835 ALSA
    Default Audio Device
sysdefault:CARD=Device
    Generic USB Audio Device, USB Audio
    Default Audio Device
front:CARD=Device,DEV=0
    Generic USB Audio Device, USB Audio
    Front speakers
surround40:CARD=Device,DEV=0
    Generic USB Audio Device, USB Audio
    4.0 Surround output to Front and Rear speakers
surround41:CARD=Device,DEV=0
    Generic USB Audio Device, USB Audio
    4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=Device,DEV=0
    Generic USB Audio Device, USB Audio
    5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=Device,DEV=0
    Generic USB Audio Device, USB Audio
    5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=Device,DEV=0
    Generic USB Audio Device, USB Audio
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=Device,DEV=0
    Generic USB Audio Device, USB Audio
    IEC958 (S/PDIF) Digital Audio Output
pi@raspberrypi ~/dvpt/rtl-sdr/src $

but "speaker-test -D front" fails

Code: Select all

pi@raspberrypi ~/dvpt/rtl-sdr/src $ speaker-test -D front

speaker-test 1.0.25

Playback device is front
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.BRCM bcm2835 AL.pcm.front.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM front
Playback open error: -2,No such file or directory
pi@raspberrypi ~/dvpt/rtl-sdr/src $

Maybe an obscure configuration file requires an update ?

Any help appreciated !

[Efcis]

I finally edited /etc/asound.conf with :

Code: Select all

pi@raspberrypi ~ $ cat /etc/asound.conf
pcm.!default {
        type hw
        card 0
}

ctl.!default {
        type hw
        card 0
}

pcm.usb {
        type plug
        slave {
                pcm "hw:1,0"
        }
}

ctl.usb {
        type plug
        slave {
                ctl "hw;1,0"
        }
}
pi@raspberrypi ~ $

Note : I'm not sure the ctl section requires the plug type, but it works. Critics welcome.

Now I can use my USB audio dongle by using the -D usb parameter, and can specify -c 1 (mono output) with aplay or speaker-test.

Unfortunately, I'm still facing the same underruns with rtl_fm

[m0ute]

Hi,

I'm having a hard time with rtl_fm. It constantly crashes like this :

Code: Select all

Script started on Mon 06 Aug 2012 21:35:51 UTC
[01;32mpi@raspberrypi[00m [01;34m~ $[00m rtl_fm -f 144.8e6 -s 44100 - | aplay -t raw -r 44100 -c 1 -f S16_LE
Found 1 device(s):
  0:  Generic, RTL2832U, SN: 77771111153705700

Using device 0: Generic RTL2832U (e.g. hama nano)
Found Elonics E4000 tuner
Oversampling input by: 23x.
Oversampling output by: 1x.
Buffer size: 8.08ms
Tuned to 145053575 Hz.
Sampling at 1014300 Hz.
Exact sample rate is: 1014300.020041 Hz
Tuner gain set to -1.00 dB.
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono

Library error 0, exiting...
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_write_reg failed with -1
[01;32mpi@raspberrypi[00m [01;34m~ $[00m exit

Script done on Mon 06 Aug 2012 21:36:20 UTC

Then I have to unplug and replug the device, otherwise i'm getting "Failed to open rtlsdr device #0".

I tried using libusb 1.0.8 without success. rtl_test crashes in a similar fashion.
I'm running on Raspbian wheezy by the way.
Any hints on what could be the problem here?

[Efcis]

Hi

I'm not very familiar with getting version numbers of my installed packages but here's the listing of the dpkg command if it can help :

Code: Select all

pi@raspberrypi ~ $ dpkg -l libusb*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libusb-0.1-4:a 2:0.1.12-20    userspace USB programming library
ii  libusb-1.0-0:a 2:1.0.11-1     userspace USB programming library
ii  libusb-1.0-0-d 2:1.0.11-1     userspace USB programming library developmen
ii  libusb-dev     2:0.1.12-20    userspace USB programming library developmen
un  libusb0        <none>         (no description available)
pi@raspberrypi ~ $

I also faced several crashes when my power supply voltage was too low. Check voltage between TP1 and TP2.

[ltaing]

m0ute, I'm having the same exact error messages. I have determined that it's a dongle problem: the dongle works for 2 mins and then it craps out with the err msgs that you posted. I then have to remove the dongle and wait like 10 minutes for the dongle to work again.

Have you gotten anywhere in terms of fixing this issue?--it seems to me a hardware issue--where the dongle is over-heating or over charging.

I'm using the ezcap USB 2.0 DVB-T/DAB/FM dongle which has the Elonics E4000 tuner.

Hi,

I'm having a hard time with rtl_fm. It constantly crashes like this :

Code: Select all

Script started on Mon 06 Aug 2012 21:35:51 UTC
[01;32mpi@raspberrypi[00m [01;34m~ $[00m rtl_fm -f 144.8e6 -s 44100 - | aplay -t raw -r 44100 -c 1 -f S16_LE
Found 1 device(s):
  0:  Generic, RTL2832U, SN: 77771111153705700

Using device 0: Generic RTL2832U (e.g. hama nano)
Found Elonics E4000 tuner
Oversampling input by: 23x.
Oversampling output by: 1x.
Buffer size: 8.08ms
Tuned to 145053575 Hz.
Sampling at 1014300 Hz.
Exact sample rate is: 1014300.020041 Hz
Tuner gain set to -1.00 dB.
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono

Library error 0, exiting...
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_write_reg failed with -1
[01;32mpi@raspberrypi[00m [01;34m~ $[00m exit

Script done on Mon 06 Aug 2012 21:36:20 UTC

Then I have to unplug and replug the device, otherwise i'm getting "Failed to open rtlsdr device #0".

I tried using libusb 1.0.8 without success. rtl_test crashes in a similar fashion.
I'm running on Raspbian wheezy by the way.
Any hints on what could be the problem here?

[Sonny_Jim]

Just to add that I've had some success with a PROlectrix DV107669 plugged into my Pi. At the moment I've only got rtl-sdr compiled as per the instructions above. To test it I've been using multimode.py on a laptop connected to it via ethernet cable. I did try using a zd1211 wireless card but it causes stuttering audio.

On the Pi, I run rtl_tcp:

Code: Select all

rtl_tcp -a PI_IP_ADDRESS

On my laptop, I run multimode.py like this:

Code: Select all

multimode.py --devinfo=rtl_tcp=PI_IP_ADDRESS:1234

My next plan is to try and get uhd_modes running either natively on the pi (requires building gnu-radio) or modifying it so it can receive the signal via rtl_tcp.

[Sonny_Jim]

Another update, I've managed to get FM receiving working with rtl-sdr. The big stopping block was using play from SoX to playback the audio, which was causing stuttering. I'm now using aplay and it's working a lot better. I'm using the source from here as it has more options to control the samplerate:
https://github.com/keenerd/rtl-sdr

Code: Select all

rtl_fm -f 88.2e6 -W -A -r 32e3 -l 0 - | aplay -r 32k -f S16_LE -t raw -c 1

[Sander]

I only get white noise with all the command I used. Tips how to solve that?

Furthermore, when I specify 98900000 (=98.9 MHz), rtl_fm tunes to 99152000 (99.152 Mhz), 252000 Hz (252 kHz) higher. Any reason for that?

Code: Select all

sander@R540:~$ sudo rtl_fm -f 98900000 -s 12000 -g10 -l10  - | aplay -t raw -f S16_LE -r 12k -c 1
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000013

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Oversampling input by: 84x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Tuned to 99152000 Hz.
Sampling at 1008000 Hz.
Output at 12000 Hz.
Exact sample rate is: 1008000.009613 Hz
Tuner gain set to 10.00 dB.
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 12000 Hz, Mono
^CSignal caught, exiting!
Aborted by signal Interrupt...

User cancel, exiting...
Signal caught, exiting!
sander@R540:~$ 

and

Code: Select all

sander@R540:~$ sudo rtl_fm -f 98648000 -s 12000 -g10 -l10  - | aplay -t raw -f S16_LE -r 12k -c 1
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000013

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Oversampling input by: 84x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Tuned to 98900000 Hz.
Sampling at 1008000 Hz.
Output at 12000 Hz.
Exact sample rate is: 1008000.009613 Hz
Tuner gain set to 10.00 dB.
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 12000 Hz, Mono
^CSignal caught, exiting!
Aborted by signal Interrupt...

User cancel, exiting...
Signal caught, exiting!
sander@R540:~$ 

and

Code: Select all

sander@R540:~$ sudo rtl_fm -f 98648000 -s 12000 -g10 -l10  - | play -t raw -r 12k -e signed-integer -b 16 -c 1 -V1 -
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000013

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle

-: (raw)

  Encoding: Signed PCM    
  Channels: 1 @ 16-bit   
Samplerate: 12000Hz      
Replaygain: off         
  Duration: unknown      

In:0.00% 00:00:00.00 [00:00:00.00] Out:0     [      |      ]        Clip:0    Found Rafael Micro R820T tuner
Oversampling input by: 84x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Tuned to 98900000 Hz.
Sampling at 1008000 Hz.
Output at 12000 Hz.
Exact sample rate is: 1008000.009613 Hz
Tuner gain set to 10.00 dB.
In:0.00% 00:00:08.19 [00:00:00.00] Out:90.1k [     -|-     ]        Clip:0    ^CSignal caught, exiting!

User cancel, exiting...
In:0.00% 00:00:08.34 [00:00:00.00] Out:98.3k [     -|-     ]        Clip:0    
Aborted.
sander@R540:~$

[dbrashear]

rtl_fm -f 96900000 -W -s 200000 -r 48000 - | aplay -r 48k -f S16_LE -t raw -c 1

Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN:

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Elonics E4000 tuner
Oversampling input by: 2x.
Oversampling output by: 4x.
Buffer size: 5.12ms
Tuned to 97315000 Hz.
Sampling at 1600000 Hz.
Output at 48000 Hz.
Tuner gain set to automatic.
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono


and it starts spitting out 96.9fm successfully and does so for ... well, minutes and then i got bored.

Playing with 160mHz range now.

[zanco]

Hi,
I am running rtl_tcp as server on the Raspberry Pi. From a Windows machine I can connect to it by using software like sdrsharp.

On my Linux system I am trying to get multimode.py connect to the Pi. However, it always choosed "using device #0" which is locally connected to this Linux machine.

I am viewing the Pi by an SSH connection, it states:
raspbian@pisces:~$ rtl_tcp -a 192.168.0.50
Found 1 device(s).
Found Elonics E4000 tuner
Using ezcap USB 2.0 DVB-T/DAB/FM dongle
Tuned to 100000000 Hz.
listening...
Use the device argument 'rtl_tcp=192.168.0.50:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...)

On my Linux system I try this:
./multimode.py --devinfo=rtl_tcp=192.168.0.50:1234 which starts but then tells me:
Using device #0 Realtek RTL2838UHIDIR
Found Elonics E4000 tuner

What would be the right way to have multimode.py connect to the remote rtl_tcp and not to the local available device #0 ?

Thanks in advance.

Ben

[geggino]

I try many test, but I always get the sound intermittent:

Code: Select all

rtl_fm -f 96900000 -W -s 200000 -r 48000 - | aplay -r 48k -f      S16_LE -t raw -c 1
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN:

Using device 0: Generic RTL2832U OEM
Found Elonics E4000 tuner
Oversampling input by: 2x.
Oversampling output by: 4x.
Buffer size: 5.12ms
Tuned to 97316000 Hz.
Sampling at 1600000 Hz.
Output at 48000 Hz.
Tuner gain set to automatic.
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
underrun!!! (at least 9,574 ms long)
underrun!!! (at least 11,873 ms long)
underrun!!! (at least 7,504 ms long)
underrun!!! (at least 15,390 ms long)
underrun!!! (at least 6,811 ms long)
underrun!!! (at least 16,309 ms long)
underrun!!! (at least 5,701 ms long)

[ersten]

I have same problem - "rtl_fm ... | aplay ..." was generating a lot of underruns and sound was intermittent every second.

Today unexpectedly I found solution:
While the CPU have full load - rtl_fm and aplay works fine!

My solution:

1. Launch on first SSH session:

Code: Select all

rtl_fm -f 97.5e6 -s 200000 -r 48000 - | aplay -r 48k -f S16_LE -t raw

2. On second SSH session launch CPU load:

Code: Select all

tar -czf ./root.tgz /

After execution those commands I heard normal sound.

This solution work only for me?
Why this solution works? How CPU load influences to rtl_fm and aplay?

PS: sorry for my bad English.