Stream Aircraft AM ATC to Broadcastify using RTL-SDR

[DC31]

Some limited success.

All that I could get was garbled garbage until I took the -g gain setting right out of the command line. That enables AGC and that got rid of the garbage.

Now it is understandable but the audio is choppy, like in a poor reception area. I am not in a poor reception area, get a very strong signal. I have tried adjusting the -l squelch setting but it doesn't seem to make a difference.

Here is the link to the feed:

Franklin County Fire and EMS Dispatch 1

Don't expect a lot of activity.

Ok, Jack, I am back home and back at it again. This morning I seem to have found a somewhat sweeter spot. I have set up the rtl-sdr stick on my feed again. Use the link in the above post to access it. See how it compares to your audio. I have some background noise also. Is that similar to what you were experiencing?

Here is the command that starts it:

~ $ sudo /usr/local/bin/rtl_fm -d 0 -M fm -f 460.400M -p 54 -g 49.6 -l 60 -t 2 -s 12k -E pad | /usr/bin/lame -r -s 12 --resample 22.05 -m m -b 16 --cbr --lowpass 4 - - | ezstream -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/136987518
ezstream: Streaming from standard input
Found Rafael Micro R820T tuner
Tuner gain set to 49.60 dB.
Tuner error set to 54 ppm.
Tuned to 460463000 Hz.
Oversampling input by: 21x.
Oversampling output by: 1x.
Buffer size: 32.51ms
Exact sample rate is: 252000.000300 Hz
Sampling at 252000 S/s.
Output at 12000 Hz.

 

[DC31]

The Bcfy feed using the sdr stick/ezstream ran fine for about 8 hours, then dropped out. Restarted and dropped out again within an hour. Rebooted pi and restarted again. Ran for about six hours before dropping out. I have switched back to the scanner/darkice feed.

 

[JACK26]

Glad to hear you are making progress. What you need is a way to restart the rpi if it looses contact with the server. The original startup code sends the ezstream stream to a file if it looses connection. Instead of falling out to that, there should be a way to reboot the rpi. Also the rc.local file needs the code with the .sh startup code to start the stream on reboot.

Original suggested startup code ended as follows:
/usr/bin/ezstream -c /etc/ezstream_bcfy.xml > /var/log/bcfy2.log 2>&1 &

If the connection to the server is lost it drops thru to "/var/log/bcfy2.log 2>&1 &" and floods the SD card with the audio stream. Instead of that step there should be a way to reboot the rpi.

I tried replacing "/var/log/bcfy2.log 2>&1 &" with "sudo reboot >&1 &" but that doesn't seem to work as the rpi doesn't actually reboot when I thought it should. Any ideas on that?

I'm still trying to get sox working to filter out the annoying 6 msec (167Hz) buzz. Currently abandoning the lame encoder and using sox exclusively.

Also, when you try the rtl-fm audio again, could you please use sound recorder or something to record a sample to a .wav ifile and post it? I'm curious if you're seeing the same noise I am. Easy to see with a .wav with audacity.

One other thing I found out about the rtl-fm -l squelch range is that it goes higher than 100 maybe up to 200. I found that I got rid of adjacent channel interference by setting the -l value to 95. The -g gain value seems to agree fairly closely to the SDR# value, but the -l squelch value doesn't match very well.

Also you want to use a -g value that is compatible with the specific SDR stick using "rtl_test" command.
EG: Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6. If exact values are not used, rtl-fm is not very good at "picking the closest value".

 

[JACK26]

Currently online with this iteration:

rtl_fm -f 482.8625M -s 32000 -g 19.7 \
-p 19 -l 95 -t 10 -E dc -E pad | \
sox -v 2.0 -t raw -r 32000 -b 16 \
-e signed -c 1 - -t .mp3 -c 1 -C 64 \
- sinc -n 3000 280-3.5k : - sinc -n 1000 325-55 |\
/usr/bin/ezstream -q -c /etc/ezstream_bcfy.xml

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

ps I have no idea what many of those parameters are doing but that string works so far.

pps: I have seen in other threads that people who "know sox" need examples to comment on the use so there you go, please feel free to comment. .

I am still struggling to completely eliminate this 6 msec noise factor.

 

[DC31]

Currently online with this iteration:

rtl_fm -f 482.8625M -s 32000 -g 19.7 \
-p 19 -l 95 -t 10 -E dc -E pad | \
sox -v 2.0 -t raw -r 32000 -b 16 \
-e signed -c 1 - -t .mp3 -c 1 -C 64 \
- sinc -n 3000 280-3.5k : - sinc -n 1000 325-55 |\
/usr/bin/ezstream -q -c /etc/ezstream_bcfy.xml

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

ps I have no idea what many of those parameters are doing but that string works so far.

pps: I have seen in other threads that people who "know sox" need examples to comment on the use so there you go, please feel free to comment. .

I am still struggling to completely eliminate this 6 msec noise factor.

I will have to try some of this when i get my pi back. I have several but needed one quickly yesterday. My neighbor just lost three sheep to coyotes so we set up a pi camera with motion detection to let us know when the culprits were there. I think that there may be a couple who won't be back...

Once things settle back down, i will do some more testing. Very versatile devices, these pi's.

 

[JACK26]

I will have to try some of this when i get my pi back. I have several but needed one quickly yesterday. My neighbor just lost three sheep to coyotes so we set up a pi camera with motion detection to let us know when the culprits were there. I think that there may be a couple who won't be back...

Once things settle back down, i will do some more testing. Very versatile devices, these pi's.

Sorry to hear about your neighbor's sheep problem. Do they have any dogs? Netcam is a cool free security cam app but I think it only works for windows.

Strange things happening here. I went to add my second bcfy feed to the rpi and plugged in a second dongle (nooelec TCO type):
https://www.amazon.com/NooElec-NESD...e=UTF8&qid=1499503335&sr=1-1&keywords=nooelec

I restarted the rpi feed and no more 167Hz noise. It turned out that the it was using the nooelec TCO dongle that has zero ppm offset (easy to tell because the nooelec dongle was running hot and the non TCO dongle that has a ppm offset was cold). So even though I'm using almost exact frequency published for the station, with a 19 ppm offset with a TCO stick that is supposed to have 0 ppm offset, now there is no more buzz.

I now I have both feeds on a single rpi3 with 2 rtl2832 dongles. The second feed (Milpitas Fire Dispatch) is up and running on the rpi with the non TCO dongle but since Milpitas is such a small area with much larger cities boarding it to the north and south I haven't heard any traffic yet. First thing I intend on tweaking on is the -p ppm setting if it sounds bad.

This is the updated startup code I'm using and now the Milpitas Police feed sounds better than SDR#. I think the second iteration of SOX (band reject filter) is not doing anything though but it's not generating any errors. The first sox iteration (bandpass filter) seems to work though as it did reduce the 167 Hz noise but didn't eliminate it.

Startup code working:

sudo rtl_fm -d 0 -f 482.8625M -s 32000 -g 19.7 \
-p 19 -l 95 -t 10 -E dc -E pad | \
sox -v 0.9 -t raw -r 32000 -b 16 \
-e signed -c 1 - -t .mp3 -c 1 -C 64 \
- sinc -n 3000 280-3.5k : - sinc -n 1000 325-55 |\
sudo /usr/bin/ezstream -q -c /etc/ezstream_bcfy.xml & \
sleep 1 |\
sudo rtl_fm -d 1 -f 460.624M -s 32000 -g 16.6 \
-p 19 -l 95 -t 10 -E dc -E pad | \
sox -v 2.0 -t raw -r 32000 -b 16 \
-e signed -c 1 - -t .mp3 -c 1 -C 64 \
- sinc -n 3000 300-3.5k : - sinc -n 1000 315-0 |\
sudo /usr/bin/ezstream -q -c /etc/ezstream_bcfy_FireMilp1.xml \
> sudo reboot &

 

[JACK26]

Also, the nooelec TCO stick had the 167Hz noise problem when I tried it before with zero -p ppm offset on the same radio frequency. Running the nooelec stick with a 19 ppm offset, combined with the sinc bandpass filter completely eliminated the noise (at least audibly). So it's not a difference between the two rtl2832's. Not sure what to change with the non TCO stick if it sounds bad though. Will probably have to play with both -p and -f parameters or maybe replace the non TCO stick with a TCO stick with some non-zero -p ppm offset. I still have 2 RTL-SDR brand TCO compensated sticks that have zero offset with SDR# but would like to use those for a trunked decoder project.
https://www.amazon.com/gp/product/B0129EBDS2/ref=s9_dcacsd_dcoop_bw_c_x_1_w

ps: Note to all reading this thread : One of the critical factors with tweaking on rtl-fm parameters is that the antennas should not be moved around between changes. They are critical to signal strength and optimum performance.

 

[DC31]

Sorry to hear about your neighbor's sheep problem. Do they have any dogs? Netcam is a cool free security cam app but I think it only works for windows.

Strange things happening here. I went to add my second bcfy feed to the rpi and plugged in a second dongle (nooelec TCO type):
https://www.amazon.com/NooElec-NESD...e=UTF8&qid=1499503335&sr=1-1&keywords=nooelec
.

Okay, so I haven't been keeping up with developments. The newest dongle I have is the blue Nooelec NESDR Mini2 (not the + version). So it looks like I am a couple generations behind. Once I get the mini2 working readonably well, it may be time to upgrade. Making sure that I understand you correctly, a dongle that is advertised as 0.5ppm TCXO does not need a -p value for the offset in the rtl-fm command line? Just use the exact frequency for the desired channel?

 

[JACK26]

Okay, so I haven't been keeping up with developments. The newest dongle I have is the blue Nooelec NESDR Mini2 (not the + version). So it looks like I am a couple generations behind. Once I get the mini2 working readonably well, it may be time to upgrade. Making sure that I understand you correctly, a dongle that is advertised as 0.5ppm TCXO does not need a -p value for the offset in the rtl-fm command line? Just use the exact frequency for the desired channel?

That is where the confusion is. I am currently using a nooelec sdr stick that works fine with sdr# with zero -p ppm offset. When I use it with rpi3 and rtl-fm it has that annoying 167 buzz. I accidently started up the feed using a rtl-fm -p offset of 19 with the nooelec stick that "needs no offset with SDR#" and Bingo! No more noise .

These are my feeds fed by a single rpi3 with 2 rtl2832 usb sticks only. Let me know how they sound
https://www.broadcastify.com/listen/feed/25781
https://www.broadcastify.com/listen/feed/23831

 

[JACK26]

Update. It ran for a few hours then crashed. Probably lost connection to the Broadcastify servers for some reason. By the time I realized the feeds were down, one of the ezstreams flooded the 32GB SD card with a root file called "/home/pi/sudo" and the VNC connection stopped working, It turns out this "sudo" file is a text file with no extension that is generated by ezstream for some reason. It grew to over 20GB and I simply deleted it and after that everything was ok and working.

Tried googling this problem and narrowing down the searches and haven't been able to find anything.

Current startup code I'm using:

rtl_fm -d 0 -f 482.8625M -s 32000 -g 19.7 \
-p 19 -l 95 -t 10 -E dc -E pad | \
sox -v 0.9 -t raw -r 32000 -b 16 \
-e signed -c 1 - -t .mp3 -c 1 -C 64 \
- sinc -n 3000 280-3.5k : - sinc -n 1000 325-55 |\
sudo /usr/bin/ezstream -q -c /etc/ezstream_bcfy.xml & \
sleep 1 |\
sudo rtl_fm -d 1 -f 460.624M -s 32000 -g 16.6 \
-p 19 -l 95 -t 10 -E dc -E pad | \
sox -v 2.0 -t raw -r 32000 -b 16 \
-e signed -c 1 - -t .mp3 -c 1 -C 64 \
- sinc -n 3000 300-3.5k : - sinc -n 1000 315-0 |\
sudo /usr/bin/ezstream -q -c /etc/ezstream_bcfy_FireMilp1.xml \
> sudo reboot &

 

[JACK26]

On the issue of the newer rtl-sdr usb sticks that have TCO, so far all the ones I've bought work at the exact published frequency that the licensed transmitters are operating at within some +/- Khz whereas the cheap ones that don't have a TCO usually require some ppm offset with SDR#. I have TCO sticks from both nooelec and RTL-SDR.com and both work well at the published frequencies with zero ppm offset using SDR# on a Windows PC. The one non TCO rtl28xx stick I have requires a ppm offset of 19 to make the frequencies agree with the FCC published values. It's possible there is a difference in -p offset using rtl-fm versus using SDR#. Hopefully the manufacturers are using calibrated spectrum analyzers and not using SDR# to tune the sticks as there could be a problem with SDR# (and/or a problem with rtl-fm).

ps: at the risk of further confusion, the TCO compensated sticks require zero ppm offset to center well on SDR#'s FFT display. The cheap non-compensated stick I have required a ppm offset to agree with FCC's published frequencies.
When I tried to match the SDR# ppm offset to the rtl_fm -p offset I get a 167Hz buzz. I accidently used the -p offset of 19 for a TCO stick that is zero ppm offset in SDR# and no more 167Hz buzz using rtl_fm.
I absolutely am not sure what is going on yet.

 

[JACK26]

BTW to anyone listening to my channel, how do you get rid of that slowly decaying ticking ?

 

[DC31]

BTW to anyone listening to my channel, how do you get rid of that slowly decaying ticking ?

I noticed your ticking. I get the same thing. In one of my scanner feeds i get a noticable tick during radio transmission also. I have not figured it out.

 

[JACK26]

Well this is not going well. I figured out how to get the rpi to auto reboot on connection loss but the bad news is I made a change to the streamstartup.sh file that rc.local uses and got lost in an endless loop that I was unable to recover from. Fortunately I made a backup of the SD image so don't have to start over but it puts me back to over a month ago. Tried to use a knoppix live cd with a win 7 pc to correct the error in the .sh startup file but it just made the problem worse lol. There maybe a way to do that but spent too much time on that and going back to a June 7 image I backed up with win32 disk imager.

In post #130 above the last line should be:
sudo reboot &

i.e. no '>" what that did was create a text file in the root directory called "sudo" that flooded the sd card with the stream when the connection was lost or some other error.

To everyone following this thread, absolutely do not use that last line in the startup .sh file (sudo reboot &) that /etc/rc.local points to until you are absolutely sure the startup code works and you have a backup image of the SD card without that last line.

For now I'm back feeding with a windows 8 pc .

 

[JACK26]

Back online with the rpi. Will be interesting to see how long it lasts . There is that line in the ezstream specific files regarding sample rate that I changed from 22.05 KHz to 33KHz to match the other settings .
Keeping fingers crossed.

PS: I now have 2 rtl2832 sticks with TCO's on both channels that have a zero -p setting with SDR# and using with a -p setting of 19 with rtl_fm and no `167 Hz buzz.

My personal opinion is that the coders of SDR# probably knew about the noise problem and simply heavily filtered the noise.

 

[JACK26]

One other thing, what is with those noisy transmitters that are within 15Khz of Milpitas frequencies? Don't be too surprised if those transmissions show up on my channel.

 

[JACK26]

Learned some new things today. the 32KHz bandwidth is too wide and I dropped it to 16KHz. That's why offsetting the oscillator -p offset seemed to reduce the 6msec buzz. That's also why I was picking up that adjacent channel to Milpitas FD. Someone (maybe the city of Milpitas) is occasionally operating a transmitter that is within 15-30KHz of the Milpitas FD primary dispatch channel (460.625MHz). It's not a frequency I could find listed anywhere and it may be an unlisted frequency that is within their licensed bandwidth. Long story short, reducing the channel bandwidth from 32KHz to 16KHz seemed to filter out the channel adjacent to FD.

I'm still getting some 6msec buzzing and it is definitely affected by gain. the higher the -g gain is set to the lower the buzz. Back to balancing gain and working with sox to reduce the noise further.

This is the script that is working best for Milpitas PD so far:
rtl_fm -d 0 -f 482.8624M -s 16000 -g 29.7 \
-p 2 -l 95 -t 10 -E dc -E pad | \
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 |\
sudo /usr/bin/ezstream -q -c /etc/Ezstream

Also having a problem with staying up with the rpi so back to the Windows PC for now.

 

[JACK26]

Follow up to anyone following this thread, I am back online with rpi3 and rtl2832 only on this channel:
https://www.broadcastify.com/listen/feed/23831

 

[DC31]

Follow up to anyone following this thread, I am back online with rpi3 and rtl2832 only on this channel:
https://www.broadcastify.com/listen/feed/23831

That audio sounds pretty good, Jack. It seems a liitle speeded up, however. Just a little "chipmunks" sound.

I have also had lots of trouble with an adjacent frequency. Locally, FD is on 460.400 and PD is on 460.350. Sometimes it seems like I am receiving only one but many times they bleed into each other when I use the rtl-sdr stick. I will have to try the 16000

 

[JACK26]

That audio sounds pretty good, Jack. It seems a liitle speeded up, however. Just a little "chipmunks" sound.

I have also had lots of trouble with an adjacent frequency. Locally, FD is on 460.400 and PD is on 460.350. Sometimes it seems like I am receiving only one but many times they bleed into each other when I use the rtl-sdr stick. I will have to try the 16000

Thanks, still trying to tweak on startup script to recover from a loss of connection that is typical. Scannercast on windows automatically recovers from loss of connection.

The audio sounds really good to me. Sped up audio maybe buffering on your end? You can look up my recent archives and they should sound ok.

For now I am back feeding from the win 8 mini pc as I'm trying to develop the script for the rpi3 to restart on connection loss.