Stream Aircraft AM ATC to Broadcastify using RTL-SDR

[JACK26]

Hi DC31, first step to success with this is to make sure you can stay logged on with your feed to broadcastify with squelch set to zero (-l 0). If that doesn't work then there are other problems.

And thanks again for following up on the questions on why this has never worked before Until now that is .

 

[JACK26]

One other thing when you're experimenting with your feed to Broadcastify, it can take up to 90 seconds or more before your connection shows up as "connected" again. It takes a lot of patience to get this working.

Also, regarding the previous post, I have no idea if the keenerd fork worked before on rpi2 since I am using an rpi3 but I doubt it .

 

[DC31]

I am working on it now. For testing purposes, I set up an icecast server on the pi and stream there rather than to bcfy. I seem to have the stream up and running white noise now with the squelch setting -l 0. Waiting on some radio traffic on the channel.

 

[JACK26]

If you are successfully feeding to Broadcastify with the rtl-fm parameters then your channel should appear as online within a few minutes.

BTW, Icecast does not work with SDR USB stick only. You need to to use ezstream .

 

[DC31]

I am working on it now. For testing purposes, I set up an icecast server on the pi and stream there rather than to bcfy. I seem to have the stream up and running white noise now with the squelch setting -l 0. Waiting on some radio traffic on the channel.

Okay, so I got some radio traffic. Still with the -l 0 setting. The radio traffic comes through but it is almost totally unintelligible.


I changed the -l setting. When I do that, my stream does not connect.

 

[JACK26]

I know the posts here are delayed a little but icecast does not work with the USB rtl sticks. You need to follow the instructions for ezstream. That was also part of my learning experience to make this work .

 

[JACK26]

Also, suggest you install this fork:
https://github.com/blantonl/RTLSDR-Airband

Not sure if it affects this issue but I have installed it and everything is working so far.

 

[DC31]

I took down one of my bcfy feeds and connected to it from the rtl pi. It would stream white noise with the squelch setting at -l 0 for about 30 sec. then disconnect. Here is what I see:

pi@raspberrypi_rtlsdr:~ $ sudo /usr/local/bin/rtl_fm -d 0 -M fm -f 460.400M -p 54 -l 0 -g 15 -t 5 -E pad -s 12k | /usr/bin/lame -r -s 12 --resample 22.05 -m m -b 16 --cbr --lowpass 4 - - | /usr/bin/ezstream -q -c /etc/ezstream_bcfy.xml
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
ezstream: Connected to http://audio1.broadcastify.com:80/XXXXXXXX
ezstream: Streaming from standard input
Found Rafael Micro R820T tuner
Tuner gain set to 14.40 dB.
Tuner error set to 54 ppm.
Tuned to 460652000 Hz.
Oversampling input by: 84x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Exact sample rate is: 1008000.009613 Hz
Sampling at 1008000 S/s.
Output at 12000 Hz.


Streaming to icecast works also. I run the same ezstream to do the streaming, just direct the output to icecast on the pi in the configuration file rather than to bcfy. streaming to icecast the stream stays on, it doesn't drop after 30 seconds. Radio transmissions come through the white noise but are totally unintelligible.

I haven't install the airband fork, so I guess i will try that next

 

[DC31]

Also, suggest you install this fork:
https://github.com/blantonl/RTLSDR-Airband

Not sure if it affects this issue but I have installed it and everything is working so far.

Some instructions Please?

In the wiki, I find
Install rtl_airband customized for Broadcastify
but that doesn't seem to refer to the github file that you are referencing.

 

[JACK26]

If you are really connected, you should be able to reload the feed from broadcastify and hear your feed within about 30 seconds if you are successfully feeding even though the web page may show you as offline. I would suggest trying a gain -g 45 setting just to make sure you are transmitting static.

Regarding server icecast vs ezstream, all I know is that icecast does not work with a USB SDR stick and when I googled icecast I've seen a lot of questions about it and a few posters who responded that icecast does not work with streaming the audio from an SDR stick to Broadcastify. I tried for many hours to make that work without success.

My suggestion is to try ezstream.

PS: This is the webpage I've been refering to. If you follow all the instructions and use the ezstream part instead of the icecast part, it should work.
http://wiki.radioreference.com/index.php/Raspberry_Pi_RTL-SDR_Broadcastify

pps if you look up this webpage again it looks like the author removed the icecast install instructions recently. Start over with those instructions and it should work .

 

[DC31]

If you are really connected, you should be able to reload the feed from broadcastify and hear your feed within about 30 seconds if you are successfully feeding even though the web page may show you as offline. I would suggest trying a gain -g 45 setting just to make sure you are transmitting static.

Regarding server icecast vs ezstream, all I know is that icecast does not work with a USB SDR stick and when I googled icecast I've seen a lot of questions about it and a few posters who responded that icecast does not work with streaming the audio from an SDR stick to Broadcastify. I tried for many hours to make that work without success.

My suggestion is to try ezstream.

PS: This is the webpage I've been refering to. If you follow all the instructions and use the ezstream part instead of the icecast part, it should work.
Raspberry Pi RTL-SDR Broadcastify - The RadioReference Wiki

pps if you look up this webpage again it looks like the author removed the icecast install instructions recently. Start over with those instructions and it should work .

Are you perhaps confusing icecast and darkice? Ezstream and darkice are audio streamers. Icecast is a sound server.

I have been using Ezstream to do the streaming all along. Darkice does not work with the rtl-sdr sticks as it cannot accept the audio from stdin. Ezstream can use stdin as an audio source. Stdin is the only option when using the rtl-sdr stick.

To use icecast, install it on the pi at the command line sudo apt-get install icecast2

Accept the default passwords.

Then set up your Ezstream configuration file in /etc as follows (use any number for the mount point):

<ezstream>
<url>http://localhost:8000/12345678</url>
<sourcepassword>hackme</sourcepassword>
<format>MP3</format>
<filename>stdin</filename>
<svrinfoname>EZStream</svrinfoname>
<svrinfourl>http://www.broadcastify.com</svrinfourl>
<svrinfogenre>Scanner</svrinfogenre>
<svrinfodescription></svrinfodescription>
<svrinfobitrate>16</svrinfobitrate>
<svrinfochannels>1</svrinfochannels>
<svrinfosamplerate>22050</svrinfosamplerate>
<svrinfopublic>0</svrinfopublic>
</ezstream>


then from another web browser on the same network, browse to piipaddress:8000 Click on the m3u button and it will stream.

 

[JACK26]

Stand corrected. Confused icecast with darkice. Thanks for the info on using icecast. Have you tried it without using icecast? This introduces an extra complication that may be causing problems.

If you can't stay logged on using -l 0 then there are other problems. Even with the keenerd fork, I was able to stay logged on for a few seconds with squelch enabled (-l 75). With squelch -l 0 I could stay logged on successfully with a lot of static. So if you can't stay logged on with -l 0 then there is some other problem besides the pad 0 problem. Is there audible constant static with -l 0?

PS: On the link for the RTLSDR-Airband that I used, I was refering to this quote from the wiki:

"If you want to use the original working source for rtl_airband for any other distribution, please follow the instructions on the rtl_airband git source page:
https://github.com/blantonl/RTLSDR-Airband"

I don't know if that would make any difference but it is the one I installed but I haven't tested it yet.

 

[JACK26]

You probably already did this but make sure you re-run the black list commands with the sdr stick unplugged:

sudo su -
echo "blacklist r820t" >> /etc/modprobe.d/dvb-blacklist.conf
echo "blacklist rtl2832" >> /etc/modprobe.d/dvb-blacklist.conf
echo "blacklist rtl2830" >> /etc/modprobe.d/dvb-blacklist.conf
echo "blacklist dvb_usb_rtl28xxu" >> /etc/modprobe.d/dvb-blacklist.conf
exit

Also I would suggest not having any other usb devices connected except keyboard, mouse and monitor to get this working the first time.

ps: I'm still not clear if you are staying logged on with -l 0 squelch. If you are staying online then the problem still sounds like the keenerd rtl-sdr fork vs osmocom fork which is working for me.

 

[JACK26]

I re-read your previous posts and it sounds like your rtl-fm -f and -p parameters might be off. I just duplicated the same problem when I switched sdr sticks and forgot to apply the appropriate -p (ppm offset) value.

I used gqrx on the rpi3 to determine those values.

One other thing, if you change your password on rr it changes the feed password and mount so you have to edit the ezstream_bcfy file too. I did not know that before.

Also, if you set everything up and then move the antenna around and vary the signal strength, you have to mess with the -g gain and -l settings again. rtl-fm seems to be very sensitive to that. I used SDR# on win8 pc to find optimum settings for those parameters and still tweaking on the squelch setting.

 

[JACK26]

Update still tweaking on all the parameters for narrow band fm reception. Tweaking on the lame paramerters to get rid of annoying buzz that is not coming from the sdr stick. So far this is working the best for me. Note that the first line -f -p -l -g parameters are critical to the specific usb sdr stick, target freq and signal strength. Those parameters should be determined with a graphic interface like SDR# on a windows PC. Only small adjustments when transferring to the rpi may be needed after that:

sudo /usr/local/bin/rtl_fm -d 0 -M fm -f 482.862M -p 19 -l 73 -g 14 -t 10 -E pad -s 12k | \
/usr/bin/lame -r -s 12 --resample 22.05 -m m -b 24 --vbr-new -V 0 --lowpass 4 --highpass 0.25 - - | \
/usr/bin/ezstream -q -c /etc/ezstream_bcfy.xml

Best info I could find so far on lame is here. If anyone else is trying to make this work well or have made it work with rpi3 (or any rpi), please share:

https://linux.die.net/man/1/lame
http://ryanve.com/lame/

ps: gqrx does not have the background buzz on the same rpi. That is how I know it's not a usb sdr or hardware problem. I've minimized the buzz with the above lame parameters so far, but it has not been eliminated completely. The foreground audio on the rpi3 is actually much better than the scannercast audio from my windows 8 pc so for me, it's worth the effort to get this working well.

 

[JACK26]

Update: Turns out gqrx has the same problem. The 60Hz sounding buzz is unique to the Raspberry Pi and continues to confound me. I went as far as cutting wires on a 20 watt 5VDC power supply and inserting 2000 uF of filtering with long wires for inductance.

There are a lot of posts about this 60Hz hum problem and a few who claimed they fixed it with a better power supply. I know that will absolutely not fix the problem in my case. It has something to do with the rtl-fm or lame software or a combination of the two.

This is the command sequence I'm currently using. It does work and stays connected to Broadcastify with very good audo (except the 60Hz sounding buzz):

sudo /usr/local/bin/rtl_fm -d 0 -M fm -f 482.862M -p 19 -l 73 -g 15 -t 10 -E pad -s 12k | \
/usr/bin/lame -r -s 12 --resample 22.05 -m m --cbr --lowpass 4 --highpass 0.1 --highpass-width 1.0 - - | \
/usr/bin/ezstream -q -c /etc/ezstream_bcfy.xml

This is the link to the live feed (Rpi3 with SDR dongle only). The RPi is headless and only connected to the sdr dongle and the 5VDC powersupply. There is no where any ground loops could possibly exist.

Milpitas Police Dispatch

I don't have this problem with win8 on a mini pc with the same dongle.

ps: This hum problem is driving me crazy because it seemed like such a minor problem to over come. What I have found out is that there is very little support for either rtl-fm or lame. I've scoured the internet for solutions to this problem and the only promising ones were 'ground loops' or a poorly filtered power supply. I've completely eliminated both those possibilities and now the only thing left is either the rtl-sdr or lame software.

This is not a hardware problem because the buzz does not exist playing sample audio files.
I'm still using the current osmocom fork of rtl-sdr sw to get the zero pad to work required by broadcastify. Haven't tried a different fork of rtl-sdr yet to see if that might fix the buzzing problem.

pps to DC31, thanks for the Icecast instructions. I finally understand that now and got it working . Even though it has nothing to do with humming problem, I was able to connect locally without feeding broadcastify thanks to your icecast instructions.

btw. icecast has a huge delay it seems. I would like about a 5 minute or so delay in my feed once I get the feed working well to prevent the bad guys from having real time audio. I think there is currently about a 1 min delay depending on radio traffic at broadcastify.

 

[krokus]

ps: This hum problem is driving me crazy because it seemed like such a minor problem to over come. What I have found out is that there is very little support for either rtl-fm or lame. I've scoured the internet for solutions to this problem and the only promising ones were 'ground loops' or a poorly filtered power supply. I've completely eliminated both those possibilities and now the only thing left is either the rtl-sdr or lame software.

DC being coupled onto the audio line can do this, if there is some 60Hz ripple present.

Sent via Tapatalk

 

[w9yrc]

This is the command sequence I'm currently using. It does work and stays connected to Broadcastify with very good audo (except the 60Hz sounding buzz):

sudo /usr/local/bin/rtl_fm -d 0 -M fm -f 482.862M -p 19 -l 73 -g 15 -t 10 -E pad -s 12k | \
/usr/bin/lame -r -s 12 --resample 22.05 -m m --cbr --lowpass 4 --highpass 0.1 --highpass-width 1.0 - - | \
/usr/bin/ezstream -q -c /etc/ezstream_bcfy.xml

JACK26, recently have been trying to get a local HAM repeater up and running on broadcastify myself and although I can't get the squelch correct, I also was experiencing the same buzz with what was being transmitted and added the -h & -Y options to the lame encoder and that seemed to help as well as configuring my highpass filter to --highpass .080

I'm not sure if the highpass requires the trailing 0 or sans a leading zero however, it's all but eliminated that low buzzing that comes through for me.


The squelch problem with padding zeros on the other hand I simply cannot solve. The squelch and gain numbers you said you grabbed from SDR# on windows which I've tried to myself but the two signals I receive seem completely different when compared as well as anything above 5 or 10 (depending on the gain) won't allow broadcastify to connect yet 3 or 0 connects just fine and allows a constant static through running rtl_fm but on SDR# I have completely different numbers. Any ideas would be greatly appreciated and I've done a clean install with the suggested rtl-sdr fork but no success. This darn squelch just refuses to work with me.

Thanks in advance.

 

[JACK26]

Ok, the way to determine if you have the pad rtl-fm -E parameter is to look at the "rtl-fm.c" that is used.
I'm still new to linux and raspberry pi programming so not sure what the correct path should be. In my case I found it in /home/pi/rtl-sdr/src. Open rtl-fm.c in a text editor and Search for "pad" and there should be a case structure that shows all the working options for -E case. If you can't find "pad" then that is not a working version of rtl-fm for squelch on broadcastify.

That will show you all the other working switches for the -E parameter too.

This is the case structure I have in rtl-fm.c that works for me so far:

case 'E':
if (strcmp("edge", optarg) == 0) {
controller.edge = 1;}
if (strcmp("no-dc", optarg) == 0) {
demod.dc_block = 0;}
if (strcmp("deemp", optarg) == 0) {
demod.deemph = 1;}
if (strcmp("swagc", optarg) == 0) {
demod.agc_mode = agc_normal;}
if (strcmp("swagc-aggressive", optarg) == 0) {
demod.agc_mode = agc_aggressive;}
if (strcmp("direct", optarg) == 0) {
dongle.direct_sampling = 1;}
if (strcmp("no-mod", optarg) == 0) {
dongle.direct_sampling = 3;}
if (strcmp("offset", optarg) == 0) {
dongle.offset_tuning = 1;
dongle.pre_rotate = 0;}
if (strcmp("wav", optarg) == 0) {
output.wav_format = 1;}
if (strcmp("pad", optarg) == 0) {
output.padded = 1;}
if (strcmp("lrmix", optarg) == 0) {
output.lrmix = 1;}
break;

Also I found another version of rtl-fm.c on the same rpi in the folder /home/pi/librtlsdr that had a version of rtl-fm that did not have the -E pad option but apparently that version is not used in my case. If your rpi is using that version then the 0 pad squelch won't work.

PS: I just looked at the osmocom fork on github and I don't think that's the right fork.
It turns out the keenerd fork is the correct one after all. I'm not sure why the original instructions did not work for me the first time but try reinstalling the keenerd rtl-sdr after installing everything else. Just a guess but maybe something after installing rtl-sdr in the original instructions is messing up rtl-fm install for some reason. I re-installed rtl-sdr in different ways so many times that I'm not sure why it wasn't working before.
https://github.com/keenerd/rtl-sdr

This has been a learning experience for me regarding working github versions for different functions and there are several for rtl-sdr.

 

[JACK26]

It appears that the level of the "60hz buzz" is affected by rtl-sdr -g gain. The higher the gain the lower the buzz level. I'm receiving a very strong signal and if the rtl-fm -g gain is turned up over about 20 percent of the range, it floods the receiver but no buzz. Not sure what to make of that. I still don't think it's a power supply problem but the only thing next is to eliminate the AC adapter completely and try one of those big USB back up batteries with no connection to the AC mains.

If anyone else would like to try that, I would welcome the results .

This is the live feed again:http://www.broadcastify.com/listen/feed/23831

headless rpi3 with SDR dongle and 5V power supply only. Network connection is wireless on a protected local router.
Still trying to eliminate the buzz.

This is the startup script I'm using. If I increase the -g gain parameter above that, the signal over modulates and nothing is discernible.

sudo /usr/local/bin/rtl_fm -d 0 -M fm -f 482.862M -p 19 -l 73 -g 18 -t 10 -E pad -s 12k | \
/usr/bin/lame -r -s 12 --resample 22.05 -m m -b 24 --cbr --lowpass 4 --highpass 0.21 - - | \
/usr/bin/ezstream -q -c /etc//ezstream_bcfy.xml