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

[Sam26K]

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.

[Sam26K]

I still think that GPS connected pi's has an advantage if exploited some day. There is a way to wire a GPS directly to the Raspberry Pi's UART. It would eliminate any errors in user input in their accurate receiver coordinates and and all the receivers in range of MLAT calcs would have the exact same time stamp independent of any internet time stamp for a local area.

MLAT calcs are derived from 4 or more receivers within 300 miles of each other. The GPS time stamp and received ADS-B signal should be the same within nanoseconds or less for all local receivers.

My take is that no one is developing this GPS pi ability for the flight trackers but I wouldn't dismiss it as "useless" tech as so far the MLAT tracking is pretty raged and is in dire need to be improved on all the tracking websites so far .

PS: Mlat is "supposed to be obsolete" by 2020 which is one reason no one has a priority on developing the tech. But if you want to see Military or other exempt planes, it's still worth pursuing improvement.

[Alcra]

Sounds like good advise, thanks

[Alcra]

Count me in. I have ordered all the gear from Ebay $103 NZ. Looking forward to getting it going. I am confused about DUMP 1090. I guess it will be on the disc that comes with the Dongle.

[Paul30003]

I thought this had been discussed to death already. A GPS contributes NOTHING to the timing AFTER the datagram has been received by an RTL stick, sent through the USB bus and decoded by a multitasking software in a non-realtime OS. The precision would be down to micro- or even milliseconds and we need nanoseconds.

Radarcapes /FR24-boxes timestamp the received packet already in the FPGA where delays are minimal, BEFORE it goes into the general microprocessor and suffers from bus delays etc.

SO: GPS timestamping with precision needs a dedicated hardware receiver.

/M

Thanks MrMac. That is a superb reply to this thread which seems to have gone a little off topic. I fully understand how the Raspberry Pi would make no useful contribution to mlat calculations. Your absolutely right that time stamping needs to be done in nano seconds. Taking into account, the need for the DVB-T stick to send over USB, then to process and time-stamp, I think 10ms would be a very generous time to handle the data, based on that, the radio wave would of traveled an additional 1863 miles before it was time stamped, A massive error. If an FPGA done it in 10 nanoseconds, then the error would be just 300 cm I can fully understand why mlat could only be handles in hardware rather than software, as you said, nano second precision is required. Its amusing to me really, because it is something I already have an understanding of, but I just could not see it.

[MrMac]

Khan, Thanks for replying. It would be nice if FR24 takes advantage of GPS equipped RPi's some day.

I thought this had been discussed to death already. A GPS contributes NOTHING to the timing AFTER the datagram has been received by an RTL stick, sent through the USB bus and decoded by a multitasking software in a non-realtime OS. The precision would be down to micro- or even milliseconds and we need nanoseconds.

Radarcapes /FR24-boxes timestamp the received packet already in the FPGA where delays are minimal, BEFORE it goes into the general microprocessor and suffers from bus delays etc.

SO: GPS timestamping with precision needs a dedicated hardware receiver.

/M

[Sam26K]

Khan, Thanks for replying. It would be nice if FR24 takes advantage of GPS equipped RPi's some day.

[Khan]

Sam26K, It would perhaps help with system time but not with MLAT.

[Sam26K]

Hi Oblivian, as usual a misunderstanding. I do not disagree with anything you said before
But so far no one has answered the question about RPi equipped GPS and if would increase the capability and accuracy of FR24.

[Oblivian]

Hi Paul,

I've followed that thread for a few months and as far as I can tell the RPi T-MLAT6/7 radar sources have never been implemented. That goes back to my original question paraphrased "if the RPi is GPS equipped, would that help the effort to get that working?"

My original question was actually directed at the FR24 developers since they are the ones who would actually know.

If you don't want to believe my quote, this was the source

http://forum.flightradar24.com/threads/9132-Beta-test-new-Flightradar24-MLAT-software-for-Raspberry-Pi?p=76188&viewfull=1#post76188

The important part being

Another important fact: If we have enough FR24 receivers (4+) for an aircraft, we use that data first and foremost. You might see mlat stats "0/0" in some areas because of that.

So the likely hood of 100% calculated Pi data is next to 0

And we all know how accurate the 'radar' contribution is, it can't ever be wrong by not showing 6/7.. surely? /sarcasm/

[Sam26K]

I did get better results with gain -10 (Auto-gain) That's not to say, that you will also get better results. It all depends on your antenna quality, location, nearby sources of interference, manufacturing tolerances of your DVB-T stick. You will just need to experiment a bit and see what works best. Just a note to add, I am using a home made 12 element Coaxial Collinear Antenna.

Just looked up your stats on http://jollain.com/FR24/stats.php and you are showing a 300nm range which is the highest possible range. Noting your location you are in a high traffic area but maybe not such shallow altitudes? (I have a lot of traffic under 5K feet above my location within 5 miles of KSJC, and 15 miles from KOAK).

Besides your 12 element colinear antenna, what else are you using if you don't mind my asking? How high is your antenna?

Edit: Note: The max range logged by jollain website is 325nm for all feeders but some apps default to a max range of 300nm.

[Sam26K]

I think i'm going to have to agree to disagree, credit has been given to RPi feeders for their MLAT contributions, I'm only into about 7 pages of a thread of 73, but after doing my thorough research, if proved wrong, I surly will hold my hands up and stand corrected. http://forum.flightradar24.com/threa...ll=1#post68343

Hi Paul,

I've followed that thread for a few months and as far as I can tell the RPi T-MLAT6/7 radar sources have never been implemented. That goes back to my original question paraphrased "if the RPi is GPS equipped, would that help the effort to get that working?"

My original question was actually directed at the FR24 developers since they are the ones who would actually know.

Thanks for that list of dump1090 parameters. On the gain issue I've got mine set to 45 which seems to be the best with an FA Pro-Stick, FA 6 dB colinear antenna and FA1090 filter in a high density RF area (KSFO area).
As I understand from other posts from devs is that "-10" or "AGC" represents max gain plus a bit. It's not an actual classic "automatic gain control" where the gain is dynamically varied depending on the strongest signal.

As you mentioned, the gain that works the best depends on the setup and radio traffic in the area but if I set my gain to "-10" I actually end up with fewer a/c contacts because the receiver is over modulated.

ps: The thread you mentioned: http://forum.flightradar24.com/threa...ll=1#post68343
should be closed as it's so far off topic since last year and it's a sticky. If there are any new updates on RPi MLAT6/7 they should start a new sticky.

[Paul30003]

That is profound information, thank you!
Did you get much better results with gain-10 instead of gain max?

I did get better results with gain -10 (Auto-gain) That's not to say, that you will also get better results. It all depends on your antenna quality, location, nearby sources of interference, manufacturing tolerances of your DVB-T stick. You will just need to experiment a bit and see what works best. Just a note to add, I am using a home made 12 element Coaxial Collinear Antenna.

[majo]

That is profound information, thank you!
Did you get much better results with gain-10 instead of gain max?

[Paul30003]

I did the adjustment a couple of days ago and since then I could notice slightly better results in range, aircrft seen and position reports!

Could you please give us some more information about your second adjustment concerning the "--gain -10" please?

I'm pleased you are having better results. I use the option "--gain -10" to enable auto-gain, there is another option --agc-enable. I tried this and found that I could not pickup any aircraft?
I spent quite a lot of time, configuring various options and noting the results.
If you do change anything, just keep a note of the previous setting just in case any changes have a negative impact.
Here are all the dump1090 options.

-----------------------------------------------------------------------------
|                        dump1090 ModeS Receiver         Ver : 1.10.3010.14 |
-----------------------------------------------------------------------------
--device-index <index>   Select RTL device (default: 0)
--gain <db>              Set gain (default: max gain. Use -10 for auto-gain)
--enable-agc             Enable the Automatic Gain Control (default: off)
--freq <hz>              Set frequency (default: 1090 Mhz)
--ifile <filename>       Read data from file (use '-' for stdin)
--interactive            Interactive mode refreshing data on screen
--interactive-rows <num> Max number of rows in interactive mode (default: 15)
--interactive-ttl <sec>  Remove from list if idle for <sec> (default: 60)
--interactive-rtl1090    Display flight table in RTL1090 format
--raw                    Show only messages hex values
--net                    Enable networking
--modeac                 Enable decoding of SSR Modes 3/A & 3/C
--net-beast              TCP raw output in Beast binary format
--net-only               Enable just networking, no RTL device or file used
--net-bind-address <ip>  IP address to bind to (default: Any; Use 127.0.0.1 for private)
--net-http-port <port>   HTTP server port (default: 8080)
--net-ri-port <port>     TCP raw input listen port  (default: 30001)
--net-ro-port <port>     TCP raw output listen port (default: 30002)
--net-sbs-port <port>    TCP BaseStation output listen port (default: 30003)
--net-bi-port <port>     TCP Beast input listen port  (default: 30004)
--net-bo-port <port>     TCP Beast output listen port (default: 30005)
--net-ro-size <size>     TCP raw output minimum size (default: 0)
--net-ro-rate <rate>     TCP raw output memory flush rate (default: 0)
--net-heartbeat <rate>   TCP heartbeat rate in seconds (default: 60 sec; 0 to disable)
--net-buffer <n>         TCP buffer size 64Kb * (2^n) (default: n=0, 64Kb)
--lat <latitude>         Reference/receiver latitude for surface posn (opt)
--lon <longitude>        Reference/receiver longitude for surface posn (opt)
--fix                    Enable single-bits error correction using CRC
--no-fix                 Disable single-bits error correction using CRC
--no-crc-check           Disable messages with broken CRC (discouraged)
--phase-enhance          Enable phase enhancement
--aggressive             More CPU for more messages (two bits fixes, ...)
--mlat                   display raw messages in Beast ascii mode
--stats                  With --ifile print stats at exit. No other output
--stats-every <seconds>  Show and reset stats every <seconds> seconds
--onlyaddr               Show only ICAO addresses (testing purposes)
--metric                 Use metric units (meters, km/h, ...)
--snip <level>           Strip IQ file removing samples < level
--debug <flags>          Debug mode (verbose), see README for details
--quiet                  Disable output to stdout. Use for daemon applications
--ppm <error>            Set receiver error in parts per million (default 0)
--help                   Show this help

Debug mode flags: d = Log frames decoded with errors
                  D = Log frames decoded with zero errors
                  c = Log frames with bad CRC
                  C = Log frames with good CRC
                  p = Log frames with bad preamble
                  n = Log network debugging info
                  j = Log frames to frames.js, loadable by debug.html