Thanks, realy -l 0 help me. Problem with correct frequency. Why it is not correct? When I set -f434500000 -> Tuned to 434753575 Hz -f100000000 -> Tuned to 100253575 Hz

Can you explain this? How I can calculate right frequency?

On Wed, Nov 14, 2012 at 11:39 PM, Adam Nielsen a.nielsen@shikadi.net wrote:

...

I use rtl_fm, check any options, but I can't listen any good sound :(

For example: rtl_fm -f 10000000 -s 44100 - | mplayer - -quiet -rawaudio rate=8000:bitrate=44100 -demuxer rawaudio

-s means you are setting the RF bandwidth to 44.1kHz. Maybe you meant -r to set the output sampling rate to 44.1k?

Either way your -rawaudio option is setting the input sampling rate to 8kHz, so the audio is going to sound like it has been slowed down.

You may want to add the "-l 0" option to rtl_fm to disable squelch while you're testing, just to see whether you are getting any audio at all. If the signal isn't that strong the default squelch value will cause you to only hear silence.

Cheers, Adam.

On 11/14/12, Adam Nielsen a.nielsen@shikadi.net wrote:

I think it's because it tunes to an offset, to avoid the centre spike. The frequency you use on the command line is what is actually decoded.

I thought this is what the -E option was for, but WBFM reception sounds really bad when I use -E.

Correct on the offset. -E is something else entirely though. When you are working with waterfalls, it is very easy to see the center/carrier and estimate the bandwidth. But usually radio transmitters report their frequency as the lower edge of the spectrum. -E is for tuning this way.

So, lets say I have a NBFM transmitter tuned to 80MHz with 12kHz bandwidth. If you look at it on the waterfall, you will see the carrier centered on 80.06MHz. You could tune to it with either

-f 80e6 -s 12e3 -E -f 80.06e6 -s 12e3

Both of those do the same thing. -E can save some typing but center tuning is easier if you don't know the bandwidth in advance.

With WBFM this all falls apart, because they use 200kHz of bandwidth (stereo and digital modes) but are offset 16kHz from their official frequency. (Because at one point wbfm was mono with 32kHz of bandwidth.) Use -W for wbfm, it takes all that into account.

-Kyle http://kmkeen.com

On 11/15/2012 05:13 AM, Adam Nielsen wrote:

...

Correct on the offset. -E is something else entirely though.

Very interesting! Thanks for the explanation.

I had been wondering whether it was related to the new librtlsdr code which appears to use a non-zero IF with the E4000 to avoid the centre spike, so it's good to know what it's really for.

Cheers, Adam.

I am not sure if this helps anyone at all but I was playing around with the command line options available with rtl_fm while trying to listen to my favorite local FM Broadcast radio station and had pretty good audio results with this ....

rtl_fm -f 88.9e6 -N -s 170e3 -o 4 -A -r 32e3 -l 0 - | play -t raw -r 32k -e signed-integer -b 16 -c 1 -V1 -

as you probably already know, when you run rtl_fm without any options you get a list of all of the command line switches as well as some example commands.

I couldn't tell much difference between using the -A option or not using it.

By the way, I am using an eZcap 668 (E4000/rtl2832u)

Hope this helps. 73 - Dave KD9GN

On Tue, 20 Nov 2012 11:59:19 +0200 Vitaliy Kulchevych coolchevy@gmail.com wrote:

$ rtl_fm -f 100.0e6 -N -s 170e3 -o 4 -A -r 32e3 -l 0 - | play -t raw -r 32k -e signed-integer -b 16 -c 1 -V1 -

I found that Dave had the right idea about jacking up the sample rate.

But another thing is that rtl_fm just won't work until the signal is strong enough. With my dongle I saw a decent FM out of the box on the waterfall display, but rtl_fm just would not grab: outputted noise and small fragments of corrupt sound that resembled the transmissions.

Then, I replaced the stock antenna and its long cable with a basic monopole designed for 1GHz -- way outside of FM radio band! But immediately rtl_fm started working. Apparently the cable attenuation was too bad.

Final command line was this: rtl_fm -l 0 -f 99.5e6 -N -s 170e3 -o 4 -A -r 24e3 - | \ aplay -r 24k -f S16_LE -t raw -c 1

-- Pete

My experience was that several commands / examples I've seen gave me stutters here on a pretty beefy computer. It took playing around and I didn't document everything, but so far what I've got that 'works' stutter-free, although maybe is not so great... but it does work anyways. I know it isn't a rasbpi but it showed me that a lot of times it isn't the hardware causing the stutters.

ron@tripel:~$ rtl_fm -W -f 96.9e6 -W -s 200000 -r 48000 - | aplay -r 48k -f S16_LE -t raw -c 1 Found 1 device(s): 0: Generic, RTL2832U, SN: 77771111153705700

Using device 0: Generic RTL2832U (e.g. hama nano) Found Rafael Micro R820T 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

On Thu, Nov 29, 2012 at 1:28 PM, keenerd keenerd@gmail.com wrote:

On 11/29/12, Pete Zaitcev zaitcev@kotori.zaitcev.us wrote:

...

But another thing is that rtl_fm just won't work until the signal is strong enough.

Maybe you should try increasing the gain.

...

Final command line was this: rtl_fm -l 0 -f 99.5e6 -N -s 170e3 -o 4 -A -r 24e3 - | \ aplay -r 24k -f S16_LE -t raw -c 1

Really, much smarter to use -W instead. You are losing a moderate amount of the signal. First, wbfm is slightly off center pushing 10% of the signal out of range. Second, it carries audio information up to 16kHz and resampling at 24ks/s discards another 25%.

rtl_fm -W -f 99.5e6 -g 49 | aplay -r 32k -f S16_LE -t raw -c 1

will work better. No reason to spell it out the long way.

-Kyle