Non ADS-B. Mode S only aircraft

[Oblivian]

I still don't get that theory and don't believe it. More receivers at the same location will not contribute to determining aircraft location.

Before we go too far, you are aware what MLAT is, and how it works reading the FAQ right?

[Oblivian]

Because thats EXACTLY what its for. Meshed, and using time stamp you can triangulate where those Mode-S only contacts are in the air. If more than 4 see it, you work out the distance from each one and bingo. You have a position in the sky to go with that altitude.

And as pointed out, some feeder apps are capable of using other nearby peers also outputting the same MLAT time tagged data to do its own positioning. And then in error, this is uploaded to FR24 via port 30002

It doesn't mean the closest neighbour or own may be producing the target, it only needs to be one internally downloaded in a datapacket from someone else. If configured wrong, it'll still put that straight back out again to FR24 to be seen as a fully location tagged one.

[DrHyperKALICH]

I still don't get that theory and don't believe it. More receivers at the same location will not contribute to determining aircraft location.

Why same place? Different!
Ideally square with distance 20+ km between receivers.

[Sam26K]

Because thats EXACTLY what its for. Meshed, and using time stamp you can triangulate where those Mode-S only contacts are in the air. If more than 4 see it, you work out the distance from each one and bingo. You have a position in the sky to go with that altitude.

And as pointed out, some feeder apps are capable of using other nearby peers also outputting the same MLAT time tagged data to do its own positioning. And then in error, this is uploaded to FR24 via port 30002

It doesn't mean the closest neighbour or own may be producing the target, it only needs to be one internally downloaded in a datapacket from someone else. If configured wrong, it'll still put that straight back out again to FR24 to be seen as a fully location tagged one.

That's exactly how I thought it worked.

[Patrick Reeves]

Still FR24 never locks on to my feeder so far.

I like watching SFO so it was easy to center on KSJC, filter your callsign and use replay.

ksjc28.jpg

With the number of feeders in the Silicon Valley-Bay area there is a lot of competition to overcome. But you can't say never anymore...

[awitty]

It comes from this:

Some FR24-feeders are also feeding other networks. One of these networks are calculating a position for S-mode aircraft using MLAT (just like FR24) BUT ALSO have the added feature of sending the MLAT position back to the feeder for local display. Some of these feeders then retransmit the MLAT position to FR24 as if it was an ADS-B position received directly form the aircraft and FR24 will then mark it with that feeder name.
FR24 are aware of this but have not been able to filter out these 'stolen' positions. This have been going on for a year or so.

Thanks Kpin, that's what i've concluded also. I note that piaware send calculated MLAT positions back to their feeders so you can easily see how this can then be retransmitted as an actual position to fr24.

[Sam26K]

I like watching SFO so it was easy to center on KSJC, filter your callsign and use replay.

[ATTACH=CONFIG]6937[/ATTACH]

With the number of feeders in the Silicon Valley-Bay area there is a lot of competition to overcome. But you can't say never anymore...

Thanks very much for that post, Patrick! Very encouraging and made my day. Seeing more T-MLAT's in the area today too.

[Sam26K]

Thanks Kpin, that's what i've concluded also. I note that piaware send calculated MLAT positions back to their feeders so you can easily see how this can then be retransmitted as an actual position to fr24.

There should be some way of filtering T-XXXXX radar feeders that are feeding mode-s transponders as ADS-B transponders to FR24. It's obvious who they are as you can usually count them on one hand in an area with dozens of ADS-B feeders showing the transponder as mode-s only without ADS-B.

I'm not saying those feeders should be blocked but when they send data as ADS-B when many other feeders are sending mode-s only data, that specific ADS-B feeder's data should be ignored for that ICAO number. That way the MLAT algos can take over.

[Sam26K]

Why same place? Different!
Ideally square with distance 20+ km between receivers.

Sorry for the misunderstanding. The reply about multiple receivers in the same location was meant as a reply to someone else's comment that someone could generate accurate mlat calculations with multiple receivers spaced a few feet apart. That is what I don't believe would work unless maybe it's a nanometer precision setup.

[Sam26K]

On the issue of T-xxxx feeders that feed fully defined positional data to FR24 when others are only receiving mode-s data, in my area of KSJC in San Jose the worst offender is T-KSJC18.

Seems to be a great feeder with strong signal strength but it's masking out the nearby feeders that could be used for more accurate MLAT calculations.
This feeder is definitely sourcing positional data from something other than a local receiver and is not accurate with tight turns as planes land and take off from KSJC.

The attached FR24 image shows a B737 SW flight that passed about 9 thousand feet above my house and does not show positional data on my feed, yet T-KSJC18 has it fully (and inaccurately) tagged.

[Oblivian]

This anomaly doesn't stop the MLAT data calculations or hinder anyone elses feeder. It simply sends apparent positional data out on 30002 the same as if it were normal ADSB data and doesn't tag it as from 'MLAT-6/7' correctly

The receiver may or may not still be getting the same Mode-S and sending it in MLAT packages.The software that captures the data is getting mode-s no doubt. But also retransmitting pre-edited additional Dump1090 data out the other port incorrectly flagged as positional.

It's shouldn't be stopping any other MLAT calculations. However Pi MLAT still appears down (see other threads) so yes, it will be more apparent at present.

http://forum.flightradar24.com/threads/9619-Feeders-cross-feeding-position-data-from-Flightaware-for-MLAT-aircraft

It appears 1xFR + 3+ Pi receivers are required to have contact at any 1 time for the back end to do what it needs to do.

[Sam26K]

I'm still confused on the issue of MLAT.
As the OP originally mentioned, my impression is that MLAT was handled by the FR24 servers and not by the 'T-xxxxx' feeders.
Otherwise how can you trust the data if the mlat calculations are done by the voluntary free feeders?

[Oblivian]

Their modified software does some pre-work to data. As long as it gets MLAT time-tagged data. And then sends to the servers for further bundle and display. Hence the separate MLAT options in the config. And statistics.

AKA --mlat enabled commandline in dump1090.

You can use the malcolm robb fork which is supplied in FR24feed bundle. Or you can use a separate one. It is the separate one installed by the FA feeder, that allows and is configured for localised MLAT loop back using client-client feedback calculations FROM OTHER SERVERS AND CLIENTS. Its a completely separate function, nothing to do with FR24 or its servers. BUT it outputs out port 30002 so you can view it locally in VRS or similar.

It does not require nor involve FR24 at all.

However what does FR24 software listen on for its source data.. Port 30002 - the same port the other variants output ALL data types (including MLAT pre calculated) on

Hence the fix, in that other thread to redirect it away so FR24feed is not receiving it and showing incorrectly.

MLAT shown on FR24 comes from 2 sources. FR24 receivers - T-MLAT3. Or a combination of Pis and FR24feed for reference - T-MLAT6/7. The errors you see, are people running other setups.

http://sonicgoose.com/flightawares-piaware-software-now-supports-multilateration-mlat/

[Sam26K]

Thanks for the follow up, Oblivian. Still it would be interesting to see what the SFO bay area would look like if T-KSJC18 and T-KSJC12 was blocked from the FR24 servers for a few days

[Oblivian]

At present, probably pretty empty. Seems the Pi based MLAT supplied stuff isn't happening. Couple have noted it, especially around oceania