Raspberry Pi type B + DVB-T Dongle to feed FR24

[Jayant]

Should do much better than that - click the link in my sig ... that is a Pi+dongle+home built co-linear (with an amplifier that didn't make much difference), I don't see much eastwards because the house roof gets in the way (need to do some antenna work)

Peter,

What antenna are you running now? I remember you were planning to build a Franklin. My CoCo isnt doing as well as I'd hoped, so I'm looking to build another one to get better range.

Best
Jayant

[loplo]

Welcome to the ADSB Pi club :-)

The driver which now comes with the Wheezy kernel does cause problems, and can be removed by either making a blacklist (as you did) or by compiling the rtl-sdr driver source with the -DDETACH_KERNEL_DRIVER=ON option. This is given in Peter's document. The built-in driver shouldn't cause any problems after this.

If I understand correctly, the kernel issue hasn't been fixed yet. Damn!
My PI hasn't been updated/upgraded since December 2013, and needs an update urgently, because it's running other stuff too - not being dedicated 100% to ADSB.
Should I risk running an update? What's your opinion guys?

[trigger]

Same dongle and same antenna. I'll try your suggestions.

I have a 6 element Franklin which I've made myself with the help of abcd. Details are on another Plane Finder forum. On the PC I'm getting 200+ km range.

[Dundee]

Hi Dundee,

Can you confirm whether you're using a wired or a wifi connection? If it's a problem related to a wifi dongle, you may need to configure it by installing wpasupplicant on your Pi and configuring it. Please also post the dongle model you're using, if you're on wifi.

Best,
Jayant

Hi Jayant,
I just used a wired connection and without a rtlsdr dongle (As I had some FlightFeeder and what RPi did is just sharing Basestation format signal from FlightFeeder to FR24).
What I did just now is to modify the "etc/network/interfaces" with following commands to replace hotplug command:

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp

I will connect the RPi to my home router again on weekend to see whether it is successful...
If it's still not ok, then I will try to use static IP command instead...

Regards,
Dundee

[Jayant]

If I understand correctly, the kernel issue hasn't been fixed yet. Damn!
My PI hasn't been updated/upgraded since December 2013, and needs an update urgently, because it's running other stuff too - not being dedicated 100% to ADSB.
Should I risk running an update? What's your opinion guys?

If you upgrade, the new kernel will be installed, with the internal driver. This will conflict with the rtl-sdr driver. To prevent this, you will need to recompile the rtl-sdr driver source with the additonal option --DETACH_KERNEL_DRIVER=ON.

I suggest you make a backup of your current working SD card. Then do the upgrade, and if you have problems, delete the rtl-sdr directory and redo the driver installation with the detach kernel driver option. Peter's invaluable setup document is your best reference. Here are the relevant bits:

After you delete the rtl-sdr directory:

git clone git://git.osmocom.org/rtl-sdr.git
cd rtl-sdr
mkdir build
cd build
cmake ../ -DDETACH_KERNEL_DRIVER=ON -DINSTALL_UDEV_RULES=ON
make
sudo make install
sudo ldconfig
cd ~
sudo cp ./rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/

... and then reboot.

If anything breaks, your backup can save the day!

[Jayant]

Hi Jayant,
I just used a wired connection and without a rtlsdr dongle (As I had some FlightFeeder and what RPi did is just sharing Basestation format signal from FlightFeeder to FR24).
What I did just now is to modify the "etc/network/interfaces" with following commands to replace hotplug command:

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp

If you don't plan to use wifi at all, all you need is:

auto lo
iface lo inet loopback
iface eth0 inet dhcp
iface default inet dhcp

You shouldn't need to do the auto eth0. And don't forget the last line, which is the default interface. AFAIK, it's required.

If you do plan to use wifi, that's a whole new chapter! :-)

[loplo]

If you upgrade, the new kernel will be installed, with the internal driver. This will conflict with the rtl-sdr driver. To prevent this, you will need to recompile the rtl-sdr driver source with the additonal option --DETACH_KERNEL_DRIVER=ON.

I suggest you make a backup of your current working SD card. Then do the upgrade, and if you have problems, delete the rtl-sdr directory and redo the driver installation with the detach kernel driver option. Peter's invaluable setup document is your best reference. Here are the relevant bits:

After you delete the rtl-sdr directory:

git clone git://git.osmocom.org/rtl-sdr.git
cd rtl-sdr
mkdir build
cd build
cmake ../ -DDETACH_KERNEL_DRIVER=ON -DINSTALL_UDEV_RULES=ON
make
sudo make install
sudo ldconfig
cd ~
sudo cp ./rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/

... and then reboot.

If anything breaks, your backup can save the day!

Jayant, Peter's documentation it's bookmarked everywhere
I'm going to read some more info regarding the SD backup, to be 100% sure that I'm on the safe side, after that I'll give it a try. Let's see what's happening
I'll report back.

The forum needs a "Thank you" button.

[trigger]

Sorted! I had an old 2Gb SD card with Wheezy on it. I went through Peter's instructions and it almost worked. I got to the last "make" and the card ran out of space. I re-booted the pi and re-ran the build dump1090 section. Bingo, it worked.

Thanks Peter and Jayant for your help.

I've got to tune my 6 element Franklin next.
Regards
Dave

[peterhr]

You're very welcome.

Sent from my Nexus 4 using Tapatalk

[loplo]

Well, what can I say, I've made some preparations, got some coffee ) and started the update/upgrade.
- made an SD backup, to be on the safe side
- fired up putty and .... sudo apt-get update / apt-get upgrade / reboot
- ready recompile the whole thing for the "detach kernel" operation when I fire up Chrome to check the local radar screen. And a big surprise: I had planes on my map, checked fr24, and I was online
- recompile mission scrambled

Feeling happy.

Thanks Jayant for your message, that was the spark for the update/upgrade.
Thanks peterhr for constantly keeping up to date your tutorial.

[peterhr]

Jayant is the person that did the legwork on what to do with the 'detach kernel',

I just did what I could to avoid the issue on people doing new builds.

Document is updated when it has stuff that has become problematic.

[Jayant]

Jayant is the person that did the legwork on what to do with the 'detach kernel',

I just did what I could to avoid the issue on people doing new builds.

Document is updated when it has stuff that has become problematic.

Peter, your documentation has definitely helped a huge number of people to get up and running with zero Linux knowledge. So a big thanks from all of us for that!

I'm always glad to help out with whatever limited Linux knowledge I have! :-)

I've been fiddling with the logs a bit. I've started logging to /var/log/fr24/ now instead of the /tmp directory, because I was never able to see exactly when fr24feed stopped transmitting stuff in case of a crash, so troubleshooting and correlating with the system logs was difficult. So I've added date/time stamps to the fr24feed log, and started logging to the /var/log/fr24/ directory to make the log stay across reboots and crashes. To avoid the logs filling up the SD card, setup logrotate to automatically rotate the logs every day and kill off old logs. I'll post the whole process up one of these days, for those who are interested in maintaining persistent logs.

Possible caveat: I'm investigating the possibility of the SD card dying with too many write operations, especially if it crashes or reboots without a proper shutdown. It's been running fine for a couple of weeks so far, but bear with me for a couple of days more. If I kill my SD card, we'll know this isn't a good idea! :-)

Best
Jayant

[peterhr]

I don't concern myself with not feeding
- I have no control over the quality of the FR24 feeder
- can't do much with the config .... it is downloaded from the FR24 Servers on startup. FR24 don't need my data
- I just restart the feeder every few hours and am happy with that.

[Andres]

If possible, I would like to have a log of "uploaded planes", i.e.: ICAO, CS if available, and Timestamp (for instance, at time of first complete detection). Other fields may be optional, as Lat/Long/Alt coordinates (again, at first complete detection). However, this may require modifications on Dump1090... As there are quite a number of planes flying near here, but not as much as in other places, it would be nice to have someting that calls your attention whenever a complete detection happens. It may be a sound or some kind of LEDs connected to the Raspberry Pi I/O pins.

Thank you for all your help. Best regards,

[peterhr]

If possible, I would like to have a log of "uploaded planes", i.e.: ICAO, CS if available, and Timestamp (for instance, at time of first complete detection). Other fields may be optional, as Lat/Long/Alt coordinates (again, at first complete detection). However, this may require modifications on Dump1090... As there are quite a number of planes flying near here, but not as much as in other places, it would be nice to have someting that calls your attention whenever a complete detection happens. It may be a sound or some kind of LEDs connected to the Raspberry Pi I/O pins.

Thank you for all your help. Best regards,

As far as I'm aware, dump1090 source is available so you can modify it yourself if you want to - doing so is beyond the the interest of most of us here.