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

[Sam26K]

Thanks for that follow up, Paul. But I still have a question about the MLAT radar sources that actually feed the FR24 server's web page.
My understanding is that MLAT data sourced from RPi receivers (or T-XXXXX feeders) still require a local FR24 receiver (or F-XXXXX feeder) to feed the MLAT calcs to the FR24 servers. MLAT 1/2 radar sources are from FR24 receivers and MLAT 5/6 radar sources are from RPi's. So far in my area MLAT 5/6 still is not working.

Your log files above show MLAT calcs are passed between local receivers but it doesn't prove that those calculations are directly passed from an RPi and displayed on FR24 as RPi sourced.

[Paul30003]

Thanks for that follow up, Paul. But I still have a question about the MLAT radar sources that actually feed the FR24 server's web page.
My understanding is that MLAT data sourced from RPi receivers (or T-XXXXX feeders) still require a local FR24 receiver (or F-XXXXX feeder) to feed the MLAT calcs to the FR24 servers. MLAT 1/2 radar sources are from FR24 receivers and MLAT 5/6 radar sources are from RPi's. So far in my area MLAT 5/6 still is not working.

Your log files above show MLAT calcs are passed between local receivers but it doesn't prove that those calculations are directly passed from an RPi and displayed on FR24 as RPi sourced.

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

[Oblivian]

MLAT
MLAT can only be contributed at this time by RPi and DVBT with Dump1090 capable of MLAT tag enabled
Mar '16 - ModeSBeast and Radarcape with 12MHz timestamps capable to be added

MLAT requires 4+ receivers.
- FR24 Receiver produced MLAT prioritised for accuracy
- Various combinations of receivers can contribute with GPS/time tagged receivers
- at least 1x FR24 receiver needed in combination
- All need to have contact with the same Mode-S Only aircraft (and 1x ADSB reference aircraft).

Attributed on the map caclulated from FR24 boxes as:
T-MLAT (Europe/Africa)
T-MLAT2 (North and South America)
T-MLAT5 (Asia/India/Japan)
T-MLAT3 (Oceania)

Attributed on the map calculated from RPi feeders:
T-MLAT6/7

More than 10 chars

[majo]

It certainly won't do any harm, as long as your sure the value is correct.

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?

[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

[majo]

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

[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.

[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.

[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.

[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]

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.

[Khan]

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

[Sam26K]

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

[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

[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.