Nobody is contributing to MLAT (?)

[hansp]

Hi everyone,

My name is Gaelan and I'm one of the Product Owners here at FR24. I wanted to just follow up on my colleagues Khan's post and the continuing thread here.

I can confirm that we do indeed use MLAT data from T feeds, however it's also not 100% of the data provided.

Whilst I'd like to share all the details regarding our MLAT calculation process and all the behind the scene's 'stuff' this is proprietary information and something that we are continuing to work and improve these constantly. I can however say one particular reason why we use less T Feed data in MLAT is due to the less reliable and precise timestamps often provided by the systems. We do endeavour to use as much data as possible, with obvious limits to ensure accuracy.

We do appreciate your feedback, comments and suggestions as always!!

Also thanks for responding. Well, first of all a lot in this thread is feedback enough, I think. For starters you can be a lot clearer on when MLAT is possible from dump1090, as Khan writes anyone who opts for another device than the DVB-stick or dump-instance is not contributing to MLAT. For years I for one have been sure that I did because it was written bold "YES" in the config interface. Don't do that. You just end up with confused users who has spent a lot of time, energy and money setting up feeders believing that MLAT coverage would improve. This can also be improved with better guidance and manuals. Tell users what they should do! Is it required that a real-time clock is added to the RBPi? Many people would gladly do that, instead of buying expensive antennas, filters and such for "no gain" (pun intended).

Most important is: dump dump1090-mutability. It is ancient in comparison. Set a goal to write the best decoder there is with settings to cater for both the beginner and the enthusiast (and other feeding software). I just spent a couple of hours downgrading a fully capable reciever to your dump1090 but could not make site position and range rings work, if it was added to the settings page as a procarg MLAT would not work.

[Oblivian]

Have not used it much myself but from what I can see it shows the aircraft tracked by a specific reciever, but the data is derived from several recievers and not only "my data". So it is not really a radar as much as it is a list of aircraft that can be seen by my (and others) reciever.

Echos this users findings that lead me to my replys conclusion.

https://forum.flightradar24.com/forum/radar-forums/flightradar24-web-page-and-apps/201507-another-filter-issue-webpage#post203118

I don't personally use it, Seeing 'my data' online isn't such a gain as leaving it alone, monitoring my own local movements for out of the ordinary contacts and supplying the community the remainder. It's been stable since 2012. And feeding prior so nothing more to gain or a feature I need above that really.

As with the previous stance of 'its random' all along, I just keep a pure local data eye rather than any potential pre-filtered or merged data one.

[Kpin]

Gaelan Agree with hansp. The most frustrating things is not to know if what you do is helping or not. Except it is even more frustrating to learn that you have actually done counterproductive things rendering your data worthless.

I think you could improve MLAT enormously if you gave the hosts a clearer idea of what is productive or counterproductive in optimizing reception.

[TheMarcel]

Just got one of these...this just confirms the prior conversations regarding the MLAT feed, especially when I/we are feeding other sites and FR24 is not the Main Data Source via DVB-T stick.

---

Dear volunteer,

We write to you with important information concerning the set-up of your receiver.
Firstly, we would like to thank you for your continued support as a volunteer feeder. We depend on volunteers such as yourself for ADS-B data from around the world and your data feed is much appreciated by the Flightradar24 community.

Important information
If you intend to share data to networks alongside Flightradar24, in your Flightradar24 receiver please disable MLAT to the following settings: MLAT=“no”and MLAT-without-gps=“no”. This is to ensure the quality of the data we receive and use and to reduce incompatibility with other services.

If you need any help optimizing your setup or have any questions, please contact support@fr24.com. Thanks again for your support!

Best regards, The Flightradar24 team

Thus again confirming the prior discussions regarding the MLAT information

[WalkyFlyer]

Hi all, Newby here.
Raspberry pi 4 with Raspbian + FR24 data sharing app (only sharing to FR24)
RTL-SDR v3 Spider made out of 8 gauge fencing wire.

Should I leave MLAT running?
Earlier in this thread it suggests one must be running Pi24 for MLAT to work. Therefore having mine active with Raspbian + FR24 data sharing app is a waste of time is this correct?

I could flash Pi24 pretty easily. If I did this, approx how close would other FR24 stations need to be with it active for MLAT to work? I am in a somewhat isolated area in southern Australia.

Do I need to add a RTC to my Raspberry for MLAT to work?

If MLAT was working would I see anything to indicate this on the FR24 webpage when I look at an aircraft?

Old thread I know, but seems relevant...

[Oblivian]

You would only see mlat 'ok' like status.

Their use of it is different to everyone elses. You don't sync with peers etc. You don't get mlat traffic back to display

You simply contribute packets with ntp stamp and reference aircraft who have full Adsb and they do the rest server side. if there are others doing the same it may help. It may not

The don't feed us if you feed anyone else thing we presume is due to not being able to properly filter the data provided. Some users were injecting, knowingly or otherwise bad data. (See an224 spoofing...)

To eliminate delays or that bad data their preference is direct stream as a source ('dvbt' direct using their decoder) vs UDP/tcp/already processed.

[WalkyFlyer]

OK thanks for the reply.... a bit HI brow for me I am afraid.

So if I use Pi24 it is direct using their decoder, whereas using their FR24 data sharing app in Raspbian it is indirect using UDP?

Is there any point having [ MLAT running: YES ] set in my current config?

Raspberry pi 4 with Raspbian + FR24 data sharing app (only sharing to FR24)
RTL-SDR v3 Spider made out of 8 gauge fencing wire.

[Oblivian]

No..if you install your own dump1090 decoder and set the receiver type as network. That's not direct

If you used the install script and your receiver type is configured as 'dvbt'. That's the same as what the image does.

We dont know if its any point enabling as we dont see the visibility of other feeders around us to know if the sent data actually is used or helps.

The only thing certain is the mlat hits dropped considerably when they told everyone to turn it off.

[WalkyFlyer]

Aha that makes sense to me now - Pi24 image & script install of their FR24 data sharing tool achieves the same outcome - I had missed the significance in your post of where you mentioned 'dvbt'.
Yes mine shows [ Receiver: dvbt, Connected ] and I used the install script to load it in default Raspbian.
I think I will just turn it off, as I can see no point in having it on then.
Thanks for taking the time to reply.

[abcd567]

Output of following command will confirm if your receiver is set to dvbt or something else

grep receiver /etc/fr24feed.ini

[WalkyFlyer]

Output of following command will confirm if your receiver is set to dvbt or something else

grep receiver /etc/fr24feed.ini

Cheers thank. My RaspberryPi is running headless atm and I don't have the skills to remotely login into it with terminal or whatever u call it. But http://192.168.1.222:8754/index.html works fine and gives me FR24 Feeder status page, where it displays the aforementioned

Receiver:

dvbt, Connected

BTW thanks for your simple Spider ANT guide. Was running for the first week on a Discone that was atop my roof. It has lots of gaps in reception. I removed its 2' long antennas and replaced them in its hub with 67mm lengths of fencing wire, bent them down 45degrees and added a vertical. Working much better. Gaps filled in and max range went up from 120 to 170nm. Will suffice until a dedicated outdoor ads-b ant arrives next week