Nobody is contributing to MLAT (?)

[Kpin]

Lately I have come to the conclusion that T-xxxx receivers based on Raspberrys og other Linux-variants DO NOT really contribute to the MLAT position calculation in FR24 (I would like to be proven wrong).

At my local airfield (EKRD, Denmark) the flying club hosts a FR24 provide receiver F-EKRD1. Other F-receivers are located 20-50 miles away.
Members of the flying club have put up 4-5 RPi-based receivers in the local area 5-15 miles from the airfield in an attempt to improve the MLAT coverage e.g. at low altitudes ideally catching aircraft on final to the runway. The aera should be really good covered.

The results have been most disappointing. There seems to be no improvement og at times it even looks worse then previously. Aircraft disappear way above 2-3.000 feet.
We compare our self to EKRK near Copenhagen where MLAT seems to work at as low as 4-500 feet. The Copenhagen area has many T- and F-receivers and now I conclude that it is the number of F-receivers that counts and that T-receiver are not really used for MLAT even if you sign up for this when you register.

I would like anybodys opinion, but I'm not sure anything short of at confirmation/explanation form a FR24 team member will convince me

[hansp]

Funny that you should bring this up because I have come to the same conclusion. During the last month I have been working with friends and added two new recievers nearby my local airfield (ESMK), and also made sure that the timesync, that is vital for MLAT coverage, and gain settings are optimal for recieving low-level non-ADSB traffic. I can verify using dump1090-fa and other services that the coverage is much better in the area - since I now manage 4 recievers (!) that is not surprising. However, in FR24 it appears that the F recievers are given much higher priority which results in poor MLAT coverage and also in several cases bad ADS-B coverage on low levels too.
Since a lot of information about reciever location is given when setting up a station, FR24 could do a lot more with their software to ensure good data quality in the feed to their servers. But apparently there is little or no development of their feeder software, all energy seems to go to the website and some bells & whistles. Comparing with the service that the other major competitor gives to those who feed them they are way behind. And I am starting to wonder if it is worth the effort. Just like you I would love to have some feedback from staff on these thoughts.

[Kpin]

Khan Can you or anybody from the FR24 Team refute my claim that private T-xxxx receivers in reality are not contributing to MLAT calculations?

Or alternatively; It would be nice to get a more comprehensive description of how the MLAT calculations work including how F- and T-receivers are utilized. And how I as a T-receiver host can improve MLAT coverage in my local area.

Thanks in advance.

[Khan]

I can confirm that we use MLAT data from T feeds.

We only use MLAT data from raspberry Pis with Pi24 software having direct access to the dongle. In other words, if you use Pi24 image and don't modify the settings, it will contribute. Also, if you install it manually on a different image but still select DVB-T Stick (USB) during the setup, it will contribute. If it is anything else, it will not i.e if you have another decoder running, that gives out data on port 30002 or 30005 which Pi24 reads and uploads, those Pis are not contributing to MLAT. I hope that helps clearing the issue.

[wiedehopf]

Why would you even do the MLAT stuff then, just keep it disabled in the feed software ...

[Kpin]

I can confirm that we use MLAT data from T feeds.

We only use MLAT data from raspberry Pis with Pi24 software having direct access to the dongle. In other words, if you use Pi24 image and don't modify the settings, it will contribute. Also, if you install it manually on a different image but still select DVB-T Stick (USB) during the setup, it will contribute. If it is anything else, it will not i.e if you have another decoder running, that gives out data on port 30002 or 30005 which Pi24 reads and uploads, those Pis are not contributing to MLAT. I hope that helps clearing the issue.

Thank you Khan for your quick response. We will soldier on an try to lower the altitude where non-ADS-B aircraft are seen around EKRD.

Still it would be very motivating for all receiver hosts if one of you could describe the MLAT calculation process in more detail. For example how are receivers selected for the calculation of a specific aircraft and what disqualifies a receiver from contributing? I think your description of MLAT on www.flightradar24.com could benefit from a review and rewrite.

[Kpin]

Why would you even do the MLAT stuff then, just keep it disabled in the feed software ...

Not sure I understand your question. I DO want to contribute to MLAT. I just got the impression that my data was not actually used anyway. Khan sort of cleared that up.

[wiedehopf]

I meant if DVB-T is not selected which is the case for quite a few people who don't want to be at the mercy of fr24feed to get the raw data out of their SDR ...

Not using MLAT if DVB-T isn't selected .... well FR24s loss or not i'm sure they have their reasons.
But why display stuff about MLAT working then in fr24feed-status.
It's also definitely doing calculations which are completely unnecessary if it's not being used.

[hansp]

Well I visited my rarely visited :8754 and indeed, in large lettering after MLAT running is says NO. Edit: removed rant.
Not very pleased with how FR24 has chosen to work with this. Yes, you could argue that other feeders and services is not their business. But you have to be blind to disregard how the community works and what users are doing. Maybe fr24feed should only be available to those who use the image, and that image only configurable by fr24 staff... see how that goes. Darn, rant afterall.

[Kpin]

Well I visited my rarely visited :8754 and indeed, in large lettering after MLAT running is says NO. Edit: removed rant.
Not very pleased with how FR24 has chosen to work with this. Yes, you could argue that other feeders and services is not their business. But you have to be blind to disregard how the community works and what users are doing. Maybe fr24feed should only be available to those who use the image, and that image only configurable by fr24 staff... see how that goes. Darn, rant afterall.

Well - If it says NO then you opted out on MLAT. You can change that. It is not FR24 rejecting your data.
What Khan is saying is that they want the data directly from the DVB-T receiver, and not handed down for some other decoder software. This probably has to do with data quality and the risk of latency.
But that does not exclude you from delivering data to other networks, as fare as I understand. They can access on the same terms. But I'm no technical expert, so I might wrong.

[hansp]

Well - If it says NO then you opted out on MLAT.

I can assure you that I have not. But things can be messed up so I'll look into it. Then, on the other hand, whats the use in doing so since I am using, and will continue using, dump1090-fa because it is superior to the dump1090 that is supplied with the fr24feeder.

[Oblivian]

Well - If it says NO then you opted out on MLAT.

Possibly misunderstanding. There is 2 places. Status WEB page enable/participate yes/no.

And fr24feed-status command working yes/no.

I have a beast receiver primary. Mlat on, status says 'OK' .

I have a 2nd unit which normally can be reconfigured to using beast-tcp:30005. And status also says OK/running

We have posters posting asking how to ensure status says OK when they added it to other provider setups already in place, and help them get it to say OK because they see it as a fault.

But as you say, because it's not clear, people won't ignore it as it's a big red error. Even though you can get a working status, and not in their preferred configuration.
False sense of security. And aches teaching people how to readjust their setups for no gain.

[Kpin]

Possibly misunderstanding. There is 2 places. Status WEB page enable/participate yes/no.

And fr24feed-status command working yes/no.

I have a beast receiver primary. Mlat on, status says 'OK' .

I have a 2nd unit which normally can be reconfigured to using beast-tcp:30005. And status also says OK/running

We have posters posting asking how to ensure status says OK when they added it to other provider setups already in place, and help them get it to say OK because they see it as a fault.

But as you say, because it's not clear, people won't ignore it as it's a big red error. Even though you can get a working status, and not in their preferred configuration.
False sense of security. And aches teaching people how to readjust their setups for no gain.

So, what Khan is is saying is that if dump1090 deliverd by FR24 is switched to dump1090-fa then we are no longer contributing to MLAT om FR24, but you can trick it to accept MLAT data anyway?
I only use vanilla FR24 software, but i suspect this is new to a lot of FR24-hosts.

[Oblivian]

No, you can't trick it.
Well. We don't know because it's so limited.

But the interface tells you it's been accepted/working by means of a big green status line rather than a red ERROR one. Even if it isn't it seems.

And people see the error, as an error. And strive to correct it regardless as a service to the community. Often wasting hours reconfiguring and teaching themselves ssh, editing commands and frustration. Breaking working setup etc.

To the point where people have scripted fix-it scripts to allow this and take care of not needed to know, just automatically fix the error. Or modify the image feeder to enhance or allow other feeders to be added

What we're now being told. Is everyone is wasting their time despite that. Because the majority like to do a service and feed multiple (sure, lots just to get free subs but not all).


hanging off the feeder that crashes and restarts to update, or reset ports (I've experienced this myself capturing 24/7 logging data) isn't always fun so will use more stable separate dump1090 for it's better features and stability.

So wiedehopf is basically saying why make status say it is, no matter the format/feeder. If it really doesn't. Clean the instructions, And leave it to the image feeder.

I think we will find, people will just deflect any mlat status issues now. And forward them to the FA image, where the data is not only useful, but is fed back too.

[Oblivian]

It does however raise another question. And something doesn't make sense.

And makes me less able to understand the statement of being locked down purely to DVBT+ dump1090-mutability and the raw out of box image setup only.

Because Radarcape/F- decoders. Are mode-s beast in disguise. They are an FPGA chip. NOT an SDR. And yet they're the ones doing the majority of the work. They don't run dump1090 - it's native data decoded from the feeder, just like my mode-s beast USB mlat status changing... Yet beast-tcp data from other feeds or via TCP at all can't be used (even though the status says it is?)

Obj decoded the initial release. Possibly Explains why using :30002 is flakey to this date-

https://forum.flightradar24.com/foru...9974#post79974

I can understand that. He later says they mangled the 30002 output format from the bundled -mutability to suit the FR24 servers directly. But then....

One of the Developers. Even saying it was later modified so you can use other ones to feed MLAT and increase their input data!!

https://forum.flightradar24.com/foru...1575#post81575

Only to slightly change that tune later.. https://forum.flightradar24.com/foru...1620#post81620

/sing like sesame street/ One of these claims is not like the other.

I'm more and more inclined to remove all traces of MLAT information relating to feeders who don't have a Radarcape or F- box. And advise them to move along/ignore.
We get no gain, and if server gets no gain other than those solely using modified -mutability. Not a lot of point trying to achieve a 'good' feed state.