Non ADS-B. Mode S only aircraft

[Kpin]

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

Well, the only way FR24 can know that MLAT calculation is needed is if no feeders are supplying position data for the aircraft in question. If one feeder cross feed the position from another network, when FR24 is likely to back off and not do its own calculation.
Excluding the cross feeding feeder therefore might initiate FR24 MLAT calculation in the area. However this is not a workable solution worldwide as FR24 doesn't have information about which feeders are cross feeding.

Another related (or separate if you which) issue is the re-transmission of traffic data by FAA. It is captured by secondary radar (SSR) and then transmitted locally to aircraft for traffic avoidance. Some feeders have tried to feed this into the networks as ADS-B as well though it has distinct data characteristics that should keep them out.

[Sam26K]

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-p...teration-mlat/

I think I get it now. Installing piAware with MLAT is the problem. From your link above regarding piAware install:

As you can see, I have two instances of ModeSDeco2 running (one for each receiver) and two instances of ModeSMixer2. This was necessary to ensure that the data I’m sending to other flight tracking sites (like FlightRadar24, RadarBox24 and PlaneFinder.net) does not include the mlat data from FlightAware. These sites calculate their own mlat positions and injecting the data from FlightAware would cause errors to creep into the other sites. Think of it as data pollution.

It looks like piAware can be safely installed without interfering with FR24 if the precautions outlined in the article are observed.

So is FR24's pi MLAT working yet or any word when it will be working?

If there's no way to filter the data from T-'s that are constantly transmitting fully defined tags based on piAware MLAT calcs to FR24, banning them (and the free account) for a couple of days would at least get their attention to fix the problem.

As long as these few T-xxxxx feeders continue to leak MLAT data from other sources and feed to FR24 as fully tagged, it doesn't give FR24's MLAT a chance to work.

My guess is that these feeders do know what they are doing in most cases and it's not an innocent mistake.

[airnrail]

My guess is that these feeders do know what they are doing in most cases and it's not an innocent mistake.

Please remember that FR24 feeders are all volunteers and the T feeders additionally do it entirely at their own expense. You'll catch more flies with honey than vinegar so let's not be too heavy handed. I don't profess to know or care much about this stuff but I doubt that all of the offending feeders are aware of the bad data they are sending out simply because most feeders don't participate in this forum.

[Sam26K]

Please remember that FR24 feeders are all volunteers and the T feeders additionally do it entirely at their own expense. You'll catch more flies with honey than vinegar so let's not be too heavy handed. I don't profess to know or care much about this stuff but I doubt that all of the offending feeders are aware of the bad data they are sending out simply because most feeders don't participate in this forum.

Point well taken. I was referring to 3 or 4 specific feeders in the KSJC area (and other high density areas) and not the whole world . Most of the community is not trying to trick anyone but in my area it is a problem with a few. No offense meant to the vast majority of feeders.

If these feeders follow FR24 at all they would know they are dominating the radar tags in high density areas like San Jose CA. It's not believable they would be unaware of that.

T-KSJC18 and T-KSJC12 are the two biggest offenders of leaking mlat from other sources and feeding it as fully tagged ADS-B data to FR-24 within 50 miles of San Francisco Bay area. It would be nice to hear a comment from one of those guys but I have no doubt they are fully aware of what they are doing.

[Kpin]

Point well taken. I was referring to 3 or 4 specific feeders in the KSJC area (and other high density areas) and not the whole world . Most of the community is not trying to trick anyone but in my area it is a problem with a few. No offense meant to the vast majority of feeders.

If these feeders follow FR24 at all they would know they are dominating the radar tags in high density areas like San Jose CA. It's not believable they would be unaware of that.

T-KSJC18 and T-KSJC12 are the two biggest offenders of leaking mlat from other sources and feeding it as fully tagged ADS-B data to FR-24 within 50 miles of San Francisco Bay area. It would be nice to hear a comment from one of those guys but I have no doubt they are fully aware of what they are doing.

The average volunteer feeder may not know much about the inner workings of the different networks. I set up my RPi based on bits of information I picked up form multiple places. Beyond what I needed to get it going I don't know much about the set up.
So these people may very well be in good faith. Best way forward is to inform FR24 on support@FR24.com, and let them contact to the feeders.

As for the reactivation of RPi based MLAT, mum seems to be the word.

[Sam26K]

The average volunteer feeder may not know much about the inner workings of the different networks. I set up my RPi based on bits of information I picked up form multiple places. Beyond what I needed to get it going I don't know much about the set up.
So these people may very well be in good faith. Best way forward is to inform FR24 on support@FR24.com, and let them contact to the feeders.

As for the reactivation of RPi based MLAT, mum seems to be the word.

Remotely possible that they are unaware as these feeders have been broadcasting to FR24 for awhile. One reason I built a pi feeder was because I was under the impression that there were not many feeders in the area and wanted to increase the accuracy of the flights over my house where the flights leaving SJO take a sharp U-turn to avoid the bay and SFO and OAK traffic. Then I find out that there are dozens of feeders in the area who are rarely seen. Surprise!

Until FR24 really gets the pi MLAT working they probably are not too concerned about a few MLAT leaks and are probably already aware of most of them in high profile areas. The tolerance for that will probably drop dramatically once the pi-mlat is working.

[Oblivian]

You can check the number of Pi coverage into FA here http://flightaware.com/adsb/coverage (turn off all but the white ones)

If theres a few about, you can throw on PiAware and get some local MLAT happening to pinpoint ones you can't locate currently

[Sam26K]

You can check the number of Pi coverage into FA here http://flightaware.com/adsb/coverage (turn off all but the white ones)

If theres a few about, you can throw on PiAware and get some local MLAT happening to pinpoint ones you can't locate currently

I'm tempted to install piAware for local traffic too, but just want to be careful that it doesn't contaminate my FR24 feed with MLAT derived data as outlined in the article you linked to above .

Link Repeated here http://sonicgoose.com/flightawares-p...teration-mlat/

Near the bottom of the article the author warns about FA's piAware leaking MLAT data to FR24 and the precautions taken to avoid the conflict.

[Sam26K]

MLAT leakers

To follow up on this thread, feeders that leak MLAT (or other fully tagged) data from other sources as T-Feeders to FR24 are a major problem for the FR24 experience.

I did a little follow up investigation on T-KSJC12 and T-KSJC18. I don't really know if they are intentionally leaking data but aside from dominating the radar tags in the area they are also the source of most of the "phantom" aircraft in my area as you can see an example in the image below.

[Oblivian]

Forget about it. It's not for us to worry.

If you check the other thread it's known and the latest release resolves this, and normal MLAT will be resumed in the near future.

Aircraft are still being displayed, sure some info and the Radar ID tag is wrong but its better than not seeing anything. And don't get hung up on it (radar code), the popularity race died a long time ago and they've not decided when but it WILL be removed from screen to stop such queries. Especially when sometimes its lagging and current display does not actually match the code shown.

[Kpin]

According to other posts the new feeder software for RPi 1.0.16-10 available now should take care of that problem. If people do upgrade ...

[Oblivian]

According to other posts the new feeder software for RPi 1.0.16-10 available now should take care of that problem. If people do upgrade ...

Don't be in too much of a hurry :P not a good success rate so far..

[Sam26K]

Forget about it. It's not for us to worry.

If you check the other thread it's known and the latest release resolves this, and normal MLAT will be resumed in the near future.

Aircraft are still being displayed, sure some info and the Radar ID tag is wrong but its better than not seeing anything. And don't get hung up on it (radar code), the popularity race died a long time ago and they've not decided when but it WILL be removed from screen to stop such queries. Especially when sometimes its lagging and current display does not actually match the code shown.

I hope they don't remove the Radar code ID's. It's one of the few user tools to pinpoint the source of problem feeders. By eliminating that, the source of the data just becomes more obscured at the user level and diminishes their ability to filter it out.

I have seen posts by Mike that Radar ID's are not reliable as true sources but at least it narrows problems down to a source with some level of id. If you remove the radar id's, you just obscure the source of problems and the users ability to contribute significant data about a problem.

[Kpin]

Don't be in too much of a hurry :P not a good success rate so far..

I updated without issues (European time zone).