Stream Aircraft AM ATC to Broadcastify using RTL-SDR

[DC31]

Hi DC31,
Reviewing and researching good answers to your questions. Did you try reducing the bandwidth of the rtl-sdr to ~250KHz with the previously discussed edits to rtl-fm.c code? I experienced choppiness too when rtl-fm code was using 1+GHz bandwidth with a narrow band fm signal. If you need more than 250KHz there is larger values you can use but the increments are discrete and defined by the rtl-sdr stick.
On the squelch -l value I think I ended up with 90+. Squelch can cause choppy audio if not optimized too.
That recording link doesn't work anymore. Does either of your live feeds use the rtl-sdr?

I just swapped my live feed back over to the sdr stick. Will leave it there for the day.

https://www.broadcastify.com/listen/feed/14693

 

[DC31]

Thanks for the response, Jack. Let me see now if I can remember the basic steps that I have taken thus far.

1. Started off by simply installing the weather radio scripts linked to previously, changing the frequency to my local uhf freq. the weather radio is a continuous broadcast, so requires no squelch. I ran mine without squelch until i found a good gain setting. I am currently using 48, maximum is about 50. Lower settings make the feed very noisy.

2. Once I found a gain setting, then added squelch and found around 70 as being good. All this setup was done utilizing a darkice stream to a local icecast server on the pi. At this point, I was getting good but choppy audio and the darkice connection remained solid (through pulseaudio) with no dropped connections. Strangely enough, the darkice connection stays connected even when I shut the stick down to make adjustments.

3. So now I had good but choppy audio. After experimenting with just about every setting in rtl_fm and sox/play i finally found that the choppines was from alsa underruns in sox/play. Google shows lots of posts about this, but I never found one that said “do this to fix it”. I believe that what i found that corrected things was installing the -E pad option (note that everything to this point did not use the ePad or the -E dc options). Of course, to make this work, I had to go back and install the keenerd fork of rtl_sdr as the one that comes with the weather radio setup does not include the -E pad option.

4. Then i was getting some bleed-over from an adjacent frequency so I had to narrow the band that the stick was listening to, reducing it to 250 kHz

I think that is the basic synopsis. The code that starts it now is:

rtl_fm -f 460.400M -s 48000 -p 55 -g 48.4 -l 73 -E dc -E pad | play -r 48000 -t raw -e s -b 16 -c 1 -V1 -v 2 - sinc -3.5k

Thanks for all the bits and pieces in your previous post. They are what has gotten me to this point.

The thing that I have found most notable is that the darkice stream to icecast or BCFY seems to work without any dropped connections.

 

[JACK26]

Sounds like you are doing ok. only suggestion is to try gain at around 20 or less if u have a strong signal.

 

[JACK26]

This is the startup code I ended up with for one of the sdr feeds:

sudo rtl_fm -d 0 -f 482.8624M -s 16000 -g 29.7 \
-p 0 -l 95 -t 10 -E dc -E pad |
sudo sox -v 0.95 -t raw -r 16000 -b 16 \
-e signed -c 1 - -t .mp3 -c 1 -C 64 \
- sinc -n 3000 280-3.5k : - sinc -n 1000 325-55 |

Not sure the second sinc command works but is not causing a problem. Note -v volume is 0.95.

PS: On dropped connections, it was 90 percent my isp Comcast's fault. Comcast is well known for kicking connections to throttle bandwidth.
I put a lot of effort into resetting my two feeds indivually thinking the connection loss was on Broadcastify side which it is sometimes, but only about 10 percent of the time. The other 90% of the time it was on my end courtesy of Comcast jiggling connections to reduce bandwidth load.

 

[DC31]

This is the startup code I ended up with for one of the sdr feeds:

sudo rtl_fm -d 0 -f 482.8624M -s 16000 -g 29.7 \
-p 0 -l 95 -t 10 -E dc -E pad |
sudo sox -v 0.95 -t raw -r 16000 -b 16 \
-e signed -c 1 - -t .mp3 -c 1 -C 64 \
- sinc -n 3000 280-3.5k : - sinc -n 1000 325-55 |

Not sure the second sinc command works but is not causing a problem. Note -v volume is 0.95.

PS: On dropped connections, it was 90 percent my isp Comcast's fault. Comcast is well known for kicking connections to throttle bandwidth.
I put a lot of effort into resetting my two feeds indivually thinking the connection loss was on Broadcastify side which it is sometimes, but only about 10 percent of the time. The other 90% of the time it was on my end courtesy of Comcast jiggling connections to reduce bandwidth load.

I had tried that startup code and all that it would do is to puke gobbldigook all over my screen. I don’t think that it liked the -t .mp3 portion, but I never really figured it out. I am on comcast also and rock solid as far as the stream goes.

 

[JACK26]

Usually, weird characters flooding the screen means the stream is outputting to the display instead of the Broadcastify connection, i,e, in my case ezstream not connecting, Don't know why anything in the commands above would cause that. Was probably a coincidence with other problems.
Note the -v of 0.95. Had to attenuate the volume of the sdr otherwise it clips the audio and sox has a problem processing it.