Announcement

Collapse
No announcement yet.

Disable MLAT if sharing with other networks

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Disable MLAT if sharing with other networks

    This only relates to volunteer receivers and NOT Flightradar24 equipment.
    No action needed if you have receiver provided by Flightradar24.



    Hi guys,

    As a lot of you have seen, we sent out an email requesting that MLAT be disabled if sharing with other networks.

    There is a lot of confusion revolving around this so this post is to add a little clarity.

    If you are sharing with other networks ie. FlightAware, Radarbox, ADS-B Exchange etc please follow the below guide:


    Please disable MLAT on either your fr24feed.ini configuration file.


    Open Command Prompt (windows) or Terminal (MacOS/Linux) and enter the following.

    ssh receiver@ipaddress


    Once you are at the command line,

    sudo nano /etc/fr24feed.ini

    receiver="avr-tcp"
    fr24key=" "
    host="127.0.0.1:30002"
    bs="no"
    raw="no"
    logmode="1"
    logpath="/var/log/fr24feed"
    mlat="no"
    mlat-without-gps="no"




    Or on the Web UI

    http:// your receivers IP address:8754
    ie. 192.168.123.456:8754





    As per the initial email,

    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.


    Thanks,
    Flightradar24 Team


  • #2
    Well I'm quite shure, that almost every volunteer feeder is feeding one or another network too.
    If all these feeders switch MLAT off, in which way will the low altitude MLAT capability/performance of FR24 be affected?

    BTW: You need a microscope to see the content in the picture provided within the sent email (The picture is way to small).
    Last edited by neroon79; 2022-05-25, 14:22.

    Comment


    • #3
      Quite a large portion of feeders only share to FR24. Those in which only share to FR24, MLAT is fine to keep enabled. The issues begin when foreign MLAT is received as our backend formatting isn't compatible, which creates large issues within the network.

      The email was refined and resent to add a lot more clarity.

      Comment


      • #4
        Presumably if we know what we're doing, we can keep MLAT enabled if our infrastructure is sufficiently isolated that FR24 is only fed a shared raw data stream from readsb which doesn't contain any MLAT data from other providers...?

        Comment


        • #5
          I don't quite understand why i get the e-mail in first place, since i don't share data with other services.
          So I assume there is a problem with my feed?

          Comment


          • #6
            FR24_Gordon can you please elaborate on the, "The issues begin when foreign MLAT is received as our backend formatting isn't compatible, which creates large issues within the network."

            Does RPI have real time clock?

            To keep costs low, the Raspberry Pi does not include a Real Time Clock module. Instead, users are expected to have it always connected to WiFi or Ethernet and keep time by checking the network.

            How does the RPI maintain accurate time?

            The Raspberry Pi sets its time over the network with NTP, a protocol for clock synchronization between computers. This protocol is widely used over the Internet to make sure the computers have the same time and is highly reliable since some machines are dedicated to the time calculation with atomic clocks.

            Hmmm...

            RPI-Clock.jpg

            Network Time on: YES
            NTP synchronized: YES

            pi@RaspberryPi1:/etc $ service ntp status
            ● ntp.service - LSB: Start NTP daemon
            Loaded: loaded (/etc/init.d/ntp; generated; vendor preset: enabled)
            Active: active (running) since Wed 2022-05-18 11:54:35 EDT; 6 days ago


            RPI-Clock-1.jpg

            Thus, MLAT data should and would be very accurate when received by FR24, as the same DVT-B stick is being used on the RPI.
            You do not have permission to view this gallery.
            This gallery has 2 photos.
            Last edited by TheMarcel; 2022-05-25, 16:37.

            Comment


            • #7
              I'm unclear as to why this is being asked. Is there a concern that MLAT data from other providers is being sent to FR24 in a format FR24 doesn't understand?

              There should be some better detail on how to tell if there's even a problem with multi-provider feeds. Can I verify if MLAT data from "another popular ADS-B provider" is even being sent to FR24?

              Comment


              • #8
                I'm both showing data on my personal website and sharing it to FR24, do I have to switch MLAT off?

                To be honest, I've never understood if the MLAT thing is working properly. Are the plane detached without position the one used for MLAT? How can I know if the fr24feed is receiving the data also for MLAT and then forwarding it to the servers or it is just processing the ADSB one?
                Sorry if I'm making confusion, but I don't have a clear picture on how MLAT works and if it is different from "normal" data.

                Comment


                • #9
                  I only share data with FR24.
                  Should MFLAT be ON or OFF ??
                  Raspberry Pi 2 | ADS-B USB Dongle | ADS-B Collinear 5/8 Antenna

                  Comment


                  • #10
                    Originally posted by FR24_Gordon View Post
                    Those in which only share to FR24, MLAT is fine to keep enabled.
                    Gordon, I only share with FR24.
                    So I can leave it as it is?

                    Comment


                    • #11
                      Why doesn't FR24 simply ignore the MLAT data?

                      Comment


                      • #12
                        Very confusing..!

                        Is the issue sharing MLAT data FROM non-local receivers with FR24?

                        MLAT data generated by the local receiver and shared with FR24 is fine, surely?

                        Maybe you mean "if you are sharing data _FROM_ other networks as well", not "with" ??

                        Maybe you could filter the data at your end?

                        Surely you need the MLAT data otherwise non-ADSB flights will disappear from the map?? 327 out of 16720 flights are MLAT looking at the live map - that's almost 2% of active flights.

                        Comment


                        • #13
                          You don't want my MLAT data from the 4-5 feeder stations that I manage? Oh well, your loss. I'll be happy to continue feeding MLAT to the other services, who also provide useful MLAT results back to me so my map shows an unfiltered view of the sky.

                          I get it -- most planes for which we need MLAT to calculate their location are on your filtered list, so the value of MLAT isn't that great to begin with. However, the technical issue of receiving rebroadcast MLAT is something that all the "other services" have been able to solve on their back-end. I think that rebroadcast MLAT data has a flag or something in the BEAST format data.

                          Separately -- only for those who use the SDR-Enthusiasts containerized (docker) feeder for fr24 (edited on May 26 with new information):
                          • Since 100% of the container users feed multiple services, we have removed MLAT from the container.
                          • Please pull the latest version of the ghcr.io/sdr-enthusiasts/docker-flightradar24 container.
                          • The command below will do this for you: it will stop MLAT feeding to FR24. Docker container users don't need to do anything else.
                          • Alternatively, if you have watchdog running in your container stack, watchdog will take care of this for you next time it runs (default: every 24 hours)
                          Code:
                          cd /opt/adsb ; docker-compose pull fr24 ; docker-compose up -d
                          Last edited by kx1t; 2022-05-26, 17:52. Reason: (updated with a new info for users of docker containers)

                          Comment


                          • #14
                            Just a suggestion, if you ask the people to change their ini file or the web UI, they also have to restart the software (webui) or the service (SSH style) in order to activate the new configuration.
                            SSH style the appropriate command would be "sudo service fr24feed restart" (without the exclamation marks off course).
                            That would give a complet set of instructions and a correct activation of the new configuration.
                            Last edited by f14driver; 2022-05-25, 16:42.

                            Comment


                            • #15
                              So the help text for MLAT says "requires at least Raspberry Pi B+ or later". I'm running the FR24 feeder on a Pi 1 B Rev 2, should I turn it off?
                              T-EDDS235

                              Comment

                              Working...
                              X