Disable MLAT if sharing with other networks

[caius]

Yes, I realise they are talking about their own mlat network, but I don't see how running their mlat client alongside anyone else's would inherently cause problems, either for them or the other networks.

The only potential conflict I can see is if they are getting sent mlat results from other clients because their version of dump1090 is ancient and can't recognise them. For clients using an up to date dump1090 or readsb they'd have to be explicitly configured to forward those results and most people won't have done so.

[KarlNapf]

Well, aside from the fact that it would be nice to understand the issue technically, where is the problem?
They don't want MLAT data from me, they don't get MLAT data from me.

[simbloke]

Well, the "why" is not clearly explained but I've done it anyway.
I'm using dump-fa because of the many instructions I found at the time, that was the clearest.

[Ressy]

Yeah I don't get this either, surely most people receive and feed out, I feed fr24 and planefinder, but I feed them both like a diode, meaning one way feeding, I dont take back anything back from either of you and refeed it to the other, and you want me to turn off MLAT, bad news for you, here, dump1090 doesnt discriminate, it either uses or not at all.

I will continue to feed MLAT as disabling it disables globally, for fr24 and for planefinder - hardly fair to them is it.

If you dont like it, disable feeds from YBBN30
(which I'm sure would be little loss, the setup is unchanged for past 8 years, since installation, nearby trees have grown rather tall lol, I've been considering taking it offline and moving antenna to regain my distances, if you rather me bring it back up without fr24, just let me know)

[Rolz]

I have uninstalled other network sharing, sorry I didn't realise this was an issue.

[Derosoft]

Is it me or something else is wrong..? I have read all those posts and haven't found any answer to any of them... I have modified my feed parameters to remove MLAT as suggested - But I sure would appreciate some answers to all the good questions out there as to "Why do we really have to do this ?" Just curious!

[Oblivian]

I will continue to feed MLAT as disabling it disables globally, for fr24 and for planefinder - hardly fair to them is it.

I was going to stay quiet here and let the fire burn.

However this may not ring true depending on how you set it up.

From experience in the 'normal' world for most users who actually are feeding others, found how buggy it was with the default fr24feeder limiting inbound connections/ports, crashing, not restarting properly after updates of timeout restart

So usually followed multitude of how-to guides to make it happen more reliably - using say dump1090-fa as its own starting service to do the work, bypassing the start-as-needed version deployed with the fr24 install
- in that situation it shouldn't effect other feeds toggling the option off as it happily runs in the background with the open port supplying it and other feeders grabbing still.

The option in the settings appears to just trigger the main 'sender' binary to connect to a secondary MLAT remote server than normal and listen for/send stuff to it from a local port. And that's probably where the issue lies.
Wrong thing opening a port (or rather, not their own expected one), wrong data stamps. (others have joined forces avoiding this to a 'standard')

....unless you have 'dvbt stick(default)' set as the feed type (which launches their own modified dump1090 on demand each time you start it with commandline strings passed through)

If you change the option and restart with 'DVBT Stick' set, you see in the logs it appends an --MLAT flag when it starts it and does some MLAT server connection stuff.

Turning it off, seems to simply ignore doing that bit.

[Pariah Zero]

and you want me to turn off MLAT, bad news for you, here, dump1090 doesnt discriminate, it either uses or not at all.

I run dump1090-fa. My system has a GPS-disciplined Clock (and obviously a GPS receiver for position as well).

I ran fr24feed from July 2018 to early 2022 in a zero downtime streak with fr24feed configured to ignore MLAT and the GPS -- in spite of the fact that the system has a GPS that is in a stationary/timekeeping mode (and about 0.051 µs / 4.1 ppm accuracy).

PiAware had no problem using gpsd and MLAT.

A couple of months ago, I figured "Why not see if I can get fr24feed to use the GPS for position & time?" - so that's what I did. Now they've asked me to disable it again. OK.

PiAware still has no problem using the data from gpsd, and MLAT still works. The raw data from dump1090-fa (in /run/dump1090-fa/history_*.json) clearly shows that there is MLAT data being reported by dump1090-fa.

So in my case, it seems that changing the setting in fr24feed has no effect outside of fr24feed.

I'm OK with that.

Hopefully in the future there'll be a way I can let them make use of the more accurate GPS time & location that is already available on the system.

[SoNic67]

I will continue to feed MLAT as disabling it disables globally, for fr24 and for planefinder - hardly fair to them is it.
If you dont like it, disable feeds from YBBN30

That's so ignorant! Entitled much?
Disabling the MLAT on the fr24feed doesn't affect anything else, it has nothing to do with dump1090.

[bocachica@duck.com]

Only turn off when you have build your own feeder.
So (for example) Raspberry's turn MLAT off.

[Ressy]

I was going to stay quiet here and let the fire burn.

However this may not ring true depending on how you set it up.

exactly, a lot of people here profess to know how everybody else has their system setup, and you know what they say about assumers

[magnum]

So (for example) Raspberry's turn MLAT off.

Without explanation from FR24 it's hard to understand why this is required.

There is no logic how the FR24 feed can be impacted by data uploaded to other feeders.
All installed feeders are simply accessing the data provided on a specific port by the decoder. That should not impact each other

[Ressy]

That's so ignorant! Entitled much?
Disabling the MLAT on the fr24feed doesn't affect anything else, it has nothing to do with dump1090.

do you think I said it disables it globally just to be a rebel? dont answer that, it was sarcasim

I said it because thats what happens with this setup, and Im pretty sure I know my setup and you have NFI about it.

A wise man once gave me some advice so I will pass that on to you sonic67

IF you don't know what you are talking about sonic67, then S T F U

[Ressy]

I remember now why I stopped coming to these forums years ago... so many know it alls who know nothing.
fr24 know who I am, they can disable me, or ask me to shutdown my feeder any time they want, planefinder will still receive it (and I have my reasons for not touching "fa"

reploies will like;ly go unanswered until next time I end up here, in anotehr 5 years or so.

[Oblivian]

Without explanation from FR24 it's hard to understand why this is required.

There is no logic how the FR24 feed can be impacted by data uploaded to other feeders.
All installed feeders are simply accessing the data provided on a specific port by the decoder. That should not impact each other

Unless it is daft and by means of manual adaption of feeder input type/port and it is blindly using the wrong format it is told rather than detect/adapt.
(or doesn't even use dump1090 like the original developer post I found saying the direct SBS and ModeS Beast was capable...)

Then again, the latest tweet says there is nothing wrong with MLAT and is not any better explained

https://twitter.com/flightradar24/st...67442266873857
https://twitter.com/flightradar24/status/1529523442596212736

"MLAT data from other networks to FR24"

Which unless you go rouge. Doesn't really happen. Because the others have managed to adapt around the initial issue of it....