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

[Oblivian]

So, I'm running up against some issues attempting to get my RTL2832 dongle up and running with my Raspberry Pi 3.

Starting from a brand new Pi, brand new SD card, installed Raspian, built all the packages for dump1090, everything appeared to work just fine.

Went to run dump1090 and received this:

pi@raspberrypi:~/dump1090 $ ./dump1090 --interactive
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
usb_claim_interface error -6
Error opening the RTLSDR device: Device or resource busy

Then, playing around I discovered if I unplug the dongle, plug it back in, and immediately run the "./dump1090 --interactive", dump1090 will fire right up and I'll start getting data!

Read somewhere that issues can occur when not using a powered USB Hub, so figured that maybe the dongle isn't getting enough power or something.
-Went out and got a powered hub, problem persisted.

Checked my blacklist files, and the typical culprits are in there.

Then, I tried a second RTL dongle that I had laying around and had converted to a BNC connector for another project, and had the same issue...so I'm confident that it's not the dongle.

So, needless to say I'm at a loss. It doesn't help that my linux knowledge is about a 3/10.

Planning on mounting this setup outside near my antenna, and really need something that I don't have to physically mess with too much.

Any advice will be greatly appreciated!

If you installed the feeder package and chose DVBT, its already stolen the device. You also can't use --interactive as it doesn't allow connection as the output is sent to screen instead.

I'd suggest taking a bit of a read..

http://forum.flightradar24.com/threads/9866-Fr24feed-software-Additional-FAQs-and-Info

[neppo1345]

So, I'm running up against some issues attempting to get my RTL2832 dongle up and running with my Raspberry Pi 3.

Starting from a brand new Pi, brand new SD card, installed Raspian, built all the packages for dump1090, everything appeared to work just fine.

Went to run dump1090 and received this:

pi@raspberrypi:~/dump1090 $ ./dump1090 --interactive
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
usb_claim_interface error -6
Error opening the RTLSDR device: Device or resource busy

Then, playing around I discovered if I unplug the dongle, plug it back in, and immediately run the "./dump1090 --interactive", dump1090 will fire right up and I'll start getting data!

Read somewhere that issues can occur when not using a powered USB Hub, so figured that maybe the dongle isn't getting enough power or something.
-Went out and got a powered hub, problem persisted.

Checked my blacklist files, and the typical culprits are in there.

Then, I tried a second RTL dongle that I had laying around and had converted to a BNC connector for another project, and had the same issue...so I'm confident that it's not the dongle.

So, needless to say I'm at a loss. It doesn't help that my linux knowledge is about a 3/10.

Planning on mounting this setup outside near my antenna, and really need something that I don't have to physically mess with too much.

Any advice will be greatly appreciated!

[delcomp]

Rgr ,.. Tks Craig...

[Oblivian]

I would think,. That entering which Ports for what,..

Would be a big help to new reader of the Forum.

As this is a big question that is often asked on Chat,.

And not having a PI Stick,. I cannot help them

If they are running a DVBT stick. It's irrelevant.

The port setting only comes in to play with some advanced options, or when it detects FlightFeeder or Dump1090 already running. In which case it helps during setup.

Just tell people. If you choose DVBT. Port doesn't matter
If they have something different setup for whatever reason. Point them here

http://forum.flightradar24.com/threads/9866-Fr24feed-software-Additional-FAQs-and-Info

There is already a port section there for common apps

[delcomp]

I would think,. That entering which Ports for what,..

Would be a big help to new reader of the Forum.

As this is a big question that is often asked on Chat,.

And not having a PI Stick,. I cannot help them

[Sam26K]

@MrMack and Paul, I am still a rookie too and will take awhile to understand all this too but it's hard to get off dismissing GPS equipped Rpi as "useless". Just yet

[Alcra]

Thanks for your reply. Being a "rookie" I dont quite understand your post.

[makkiahmad]

What all Dvb-t dongle support for so feeder fr24? I had a raspberry pi but no Dvb-t

Sent from my SM-J200G using Tapatalk

[MrMac]

I think MrMac has already explained why it is not possible for a Pi to implement mlat.

Pis work just fine with mlat, with the limitation that they need to use ADSB aircraft with known positions to synchronize to. The FR24 implementation also needs a FR24 receiver which helps find absolute sync. Planeplotter and Flightaware versions work fully with "relative" sync.

I think it was Bev who writes PlanePlotter that first came up with the idea to use ADSB-sync.

Please be patient with me but when it comes to MLAT calcs, shouldn't the receiver's time stamp be the important one?
Are you saying that the Aircraft's ADS-B time stamp is to be used for MLAT calcs? If that's the case it's no wonder it's so bad

ADSB aircraft are those with known positions, and they are used to synchronize receivers that can mutilaterate non-ADSB aircraft.

Beast & DVBT Receivers timestamp incoming messages with a 12Mhz rolling clock, completely unsynced but with relativley low jitter. Their actual real time is never used, it's as I said completely useless. That is why a GPS won't matter, unless you build something that takes the PPS pulse and sends it as a detectable signal through the DVBT stick, that Dump then can decode and sync the 12 Mhx clock to. But would that actually be better ? Doubtful.

Knowing the position of an aircraft and the distances to fixed positions gives an expected time difference in arrival of the same transmission. Subtract that difference and you have 2 12 Mhz timestamps that you know are from the same point in time, aka your receivers now have a known sync.

3-4 receivers need to hear both the mlat target AND at least one reference ADSB aircraft to give useful data.

Current mlat is not bad at all, quite the opposite. It's amazing what results you can get with nothing but a few cheap dongles, Rpis and a clever server software. The limitation is just in the numbers, you need a LOT of receivers to get triple coverage, especially at lower altitudes.

/M

[Sam26K]

Thanks for that link, Paul nice pdf

[Paul30003]

This is certainly worth a read. http://www.multilateration.com/downl...ence-Guide.pdf

[Sam26K]

Both of them would be completely useless, your theory is wrong since you don't know how this works today, and that's why you keep going on about something which is a moot point.

Mlat data is not synced by internet timestamps, what gave you that idea? They are synchronized by ADSB transmissions from aircraft with known positions. That's the whole point of mlat using cheap, unsynchronized receivers.

The only thing a GPS would help with is getting the receivers position without user input, or when using a mobile Rx on a boat or vehicle.

Can we move on ?

/M

Not just yet.... I am talking about the receiver that first picks up the airborne aircraft live. So you are saying that the aircraft itself is transmitting a time stamp?

Please be patient with me but when it comes to MLAT calcs, shouldn't the receiver's time stamp be the important one?

Are you saying that the Aircraft's ADS-B time stamp is to be used for MLAT calcs? If that's the case it's no wonder it's so bad

[Paul30003]

I should clarify that my theory is that if the receiver that is logging a particular aircraft live attaches a time stamp from a UART connected GPS receiver, that it would be more accurate than using a internet derived time stamp. Combine a more accurate time stamp with exact terrestrial coordinates of the receiver should improve MLAT results.

As I understand it, no one is using that capability to improve MLAT results yet.

I think MrMac has already explained why it is not possible for a Pi to implement mlat. The data MUST be handled at a HARDWARE level with a dedicated IC. As there is no ASIC's (Application Specific Integrated Circuit) to perform this task at the hardware level, this has been done with an FPGA (Field Programmable Gate Array) In software, there would be several steps involved in time-stamping, the Pi's CPU needs to interpret and manipulate the data, then it has to write the time-stamp. This would take many CPU clock cycles. With an FPGA, it would be as fast as switching a gate, or turning on a transistor. This can be done in nano seconds, rather than milliseconds.

[MrMac]

I am confused about DUMP 1090. I guess it will be on the disc that comes with the Dongle.

NO, and don't load ANY software or driver from the CD, it will just prevent your intended use of the dongle.

You need to download a suitable Dump version for your operating system.

/M

[MrMac]

I should clarify that my theory is that if the receiver that is logging a particular aircraft live attaches a time stamp from a UART connected GPS receiver, that it would be more accurate than using a internet derived time stamp. Combine a more accurate time stamp with exact terrestrial coordinates of the receiver should improve MLAT results..

Both of them would be completely useless, your theory is wrong since you don't know how this works today, and that's why you keep going on about something which is a moot point.

Mlat data is not synced by internet timestamps, what gave you that idea? They are synchronized by ADSB transmissions from aircraft with known positions. That's the whole point of mlat using cheap, unsynchronized receivers.

The only thing a GPS would help with is getting the receivers position without user input, or when using a mobile Rx on a boat or vehicle.

Can we move on ?

/M