Announcement

Collapse
No announcement yet.

Nobody is contributing to MLAT (?)

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

  • #16
    And just for kicks. Since those dev messages look like it needs to be a fork that supports --mlat. I fired it up to compare the difference on my test stick.

    Dump1090 windows compile Ver : 1.09.0608.14

    ./dump1090.exe --help
    --mlat display raw messages in Beast ascii mode

    When run with --mlat --net:
    30002 format:
    @00000224999A8DC8276C2204E6B3DF5360F845A4;
    @000002F62ACA02A186111F58FA;
    @000003357F0002A186111F58FA;

    30005 format: (certainly binary)
    ÛCì╚'lÛÞê0å3xÂ░\Nì╚'lÖÆô8H
    ┴~╠2yÛF┴åö(~3y-ènMì╚'l°#I©hM3y4█ÄJì╚'lX5GO╠ÛL┌3yfKÿKì╚'lÖæô8 H ─a×3yv╚Æ=ì╚'lß║ØBY3y█}Gì'lÛÞê0å2yß▀ªRÑåô/%3z¦{■Bì╚'lÖæôH

    When run with only --net:
    30002 format:
    *02A184B6FA5473;
    *8DC827B1EA30E894013C08F9A8A6;
    *8DC827B19908602610540C7CE0EA;
    30005 format:
    28ê2b─2ì3¿2ÿ"ì╚'▒t­╠
    ô2®]ý5]╚'▒ç═3®ÃS┬)ì╚'▒uð
    ╔ÎJ3¬┐ýì╚'▒XË<à¹W3¬═(ý%ì╚'▒uÈ

    Guess that's why it's always preferred avr/30002 then?
    Though I would have thought with it happy with Binary Beast format (just like the Radarcape and F- produce) it shouldn't be as clear cut as 'only use DVBT with direct connection'

    Here's my current status (mode-s beast behind beast-splitter, And fr24feed is using one of beast splitter ports on beast-tcp even!)

    Figure this one out.. (beast-tcp like this is malformed essentially the same no matter the receiver?)

    pi@raspberrypi:~ $ sudo fr24feed-status
    [ ok ] FR24 Feeder/Decoder Process: running.
    [ ok ] FR24 Stats Timestamp: 2021-04-29 06:42:20.
    [ ok ] FR24 Link: connected [TCP].
    [ ok ] FR24 Radar: T-NZCH1.
    [ ok ] FR24 Tracked AC: 14.
    [ ok ] Receiver: connected (5494652 MSGS/0 SYNC).
    [ ok ] FR24 MLAT: ok [UDP].
    [ ok ] FR24 MLAT AC seen: 13.


    mlatbeast.JPG

    fr24feed 27037 27067 th_master fr24 29u IPv4 1091682373 0t0 TCP localhost:43918->localhost:30005 (ESTABLISHED)
    fr24feed 27037 27068 th_reader fr24 29u IPv4 1091682373 0t0 TCP localhost:43918->localhost:30005 (ESTABLISHED)
    fr24feed 27037 27069 th_socket fr24 29u IPv4 1091682373 0t0 TCP localhost:43918->localhost:30005 (ESTABLISHED)
    fr24feed 27037 27070 mlat_thre fr24 29u IPv4 1091682373 0t0 TCP localhost:43918->localhost:30005 (ESTABLISHED)
    Attached Files
    Posts not to be taken as official support representation - Just a helpful uploader who tinkers

    Comment


    • #17
      beast just isn't meant to be printed to the console, it doesn't change with the --mlat switch, only the AVR output changes (and the stdout when quiet isn't specified might also change).

      The beast coming from Radarcape (and derived custom boxes for FA / FR24) output a different clock in the beast output, it's using an integrated GPS clock that is synced with the FPGA.
      With dump1090 you only get a relative clock.
      I have no idea how the FR24 MLAT system works and what is required and why. The only logical conclusion is that they somehow use system time stamps and don't go the synchronization via ADS-B messages that mlat-client uses. Then the networking due to the way it's coded in dump1090 and dump1090-fa would add unacceptable clock issues.
      But that doesn't really make sense as there is one chunk of data from USB every 50 ms .... so you'd need to use the timestamps emitted by dump1090 even when directly connected somehow and do an offset using the timestamp somehow.
      I suppose there were issues with the network settings of dump1090 often being set to only emit messages basically every second in low traffic situations or some issue like that.
      The software might be able to correct for the 50 ms chunks coming via USB but isn't able to compensate any more.
      They want to avoid those issues. (wouldn't be impossible to detect such configurations that cause issues but it's extra coding and that's not cheap)

      I'm almost curious if the issues could be circumvented by using a UNIX socket instead, but that would need to be implemented for both fr24feed and dump1090-fa / readsb.
      I digress: They test one configuration because that's what a lot of people run.

      Still confusing that you can have bad and good MLAT status even when using the beast-tcp mode ..... as in why would it show MLAT status if the data is being discarded anyway.

      Comment


      • #18
        mmmHmm. I gathered as much. A binary signal is generally that. Unreadle without decode.
        Just goes out window when you consider they need(ed) a custom malformed 30002/AVR. (which we have found in the past is about as reliable as a 1 legged sheep dog)
        But then you can see there a post saying it was opened it up to non malformed as long as it had --mlat change. Kinda contradiction.

        Most decoders now don't bother?

        Almost needs some logic added to the status output.

        If receiver set != DVBT then FR24 MLAT = "N/A - DVBT only"

        (or simply.. don't display/use cycles for it at all)

        Oddly, my beast - saying it's producing 14 MLAT data hits above.. no GPS. And it's beast-splitter modified/passed through. Unless the native read can figure it out and still use it, while if you consider DVBT and DVBT alone it's a no. *shrug*

        At least I can see GND has since been enabled. This use to be off
        And more details about what is sent appears present..

        [/cod2021-04-29 19:33:56 | [main][i]Version: 1.0.27-2/generic
        2021-04-29 19:33:56 | [main][i]Built on Mar 25 2021 14:17:10 (HEAD-76766f9.git/Linux/static_armel)
        2021-04-29 19:33:56 | [main][i]Running on: raspbian10

        2021-04-29 19:33:58 | [reader][i]Connecting to unknown receiver via (tcp://127.0.0.1:30005) <- pfft
        2021-04-29 19:33:58 | [main][i]Socket server started
        2021-04-29 19:33:58 | [main][i]MLAT data feed started
        2021-04-29 19:33:58 | [bs][i]Initializing server
        2021-04-29 19:33:58 | [bs][i]Starting server on :::30003
        2021-04-29 19:33:58 | [mlat][i]Waiting for MLAT configuration
        2021-04-29 19:33:58 | [reader][i]Connected to the receiver, configuring
        2021-04-29 19:33:58 | [reader][i]Configured, processing messages
        2021-04-29 19:33:58 | [reader][i]Timestamp source changed from UNKNOWN to SYSTEM-UNCERTAIN
        2021-04-29 19:33:59 | [time][i]Synchronizing time via NTP
        2021-04-29 19:34:00 | [time][i]Time synchronized correctly, offset +0.020 seconds

        2021-04-29 19:34:02 | [feed][c]Max range AIR: 350.0nm
        2021-04-29 19:34:02 | [feed][c]Max range GND: 100.0nm

        2021-04-29 19:34:02 | [feed][i]defined 3 servers
        2021-04-29 19:34:02 | [feed][c]Timestamps: optional

        2021-04-29 19:34:02 | info | Configured ReceiverACSender: 185.218.24.22:8099,185.218.24.23:8099,185.218.24.2 4:8099, feed: NZCH1, send_interval: 5s/1s, max age: 15s, send metadata: true, mode: 0, filtering: true

        2021-04-29 19:34:02 | [mlat][i]MLAT configuration received, service ENABLED
        2021-04-29 19:34:02 | [mlat][i]Starting MLAT with preconfigured position:
        2021-04-29 19:34:02 | [mlat][i]MLAT bandwidth reduction active, level 1

        2021-04-29 19:34:02 | [mlat][i]Registering MLAT station
        2021-04-29 19:34:02 | [mlat][i]Registering MLAT station: SUCCESS

        2021-04-29 19:34:09 | [mlat][i]Received ADS-B time references AC:
        2021-04-29 19:34:09 | [mlat][i] C818DB
        2021-04-29 19:34:09 | [mlat][i] C81A91
        2021-04-29 19:34:09 | [mlat][i] C81B24
        2021-04-29 19:34:09 | [mlat][i] C81BB3
        2021-04-29 19:34:09 | [mlat][i] C81C56
        2021-04-29 19:34:09 | [mlat][i] C81CB1
        2021-04-29 19:34:09 | [mlat][i] C82081
        2021-04-29 19:34:09 | [mlat][i] C8276C
        2021-04-29 19:34:09 | [mlat][i] C822ED
        2021-04-29 19:34:09 | [mlat][i] C8244B
        2021-04-29 19:34:13 | [feed][i]sent 12,0 AC
        Last edited by Oblivian; 2021-04-29, 07:46.
        Posts not to be taken as official support representation - Just a helpful uploader who tinkers

        Comment


        • #19
          AVR (tcp) with --net.
          Code:
          2021-04-29 08:45:04 | [mlat][i]Registering MLAT station
          2021-04-29 08:45:04 | [mlat][i]Registering MLAT station: SUCCESS
          ...and so forth.

          Comment


          • #20
            wiedehopf and Oblivian Thank you for taking an interest in this subject. Most of the technical stuff goes right over my head, but that is fine.
            My main interest is better MLAT coverage in my local area. I only use vanilla FR24 software so it should work, but some of my local friends may unknowingly have sabotaged their MLAT feed to FR24 by changing the dump1090 software and/or starting feed to other networks. I can't really get a clear picture.

            BTW: A related issue. I have observed that some aircraft that I know for sure are only MLAT and NOT ADS-B equipped nevertheless are shown as ADS-B aircraft. I see that they are always attributed to one of two receivers and my conclusion is that these receivers are feeding other networks (FA or PA or ?) with their own (better) MLAT calculation which is then fed back to the receiver and then passed on to FR24 as ADS-B. I have tried to raise this with FR24 support but nothing has changed. It must be unsatisfying for both FR24 and competing networks to have this spilover - I would think.

            Comment


            • #21

              Originally posted by hansp View Post
              AVR (tcp) with --net.
              Code:
              2021-04-29 08:45:04 | [mlat][i]Registering MLAT station
              2021-04-29 08:45:04 | [mlat][i]Registering MLAT station: SUCCESS
              ...and so forth.
              So no --mlat too?
              And yet, apparently.. According to above. It NEEDs dump1090-mutability. 1.14. And --mlat (the default cmd line passed)..

              Go figure huh.

              This is my VM with default.

              2021-04-29 20:34:08 | [main][i]Reader thread started
              2021-04-29 20:34:08 | [main][i]MLAT data feed started
              2021-04-29 20:34:08 | [master][i]Starting processing thread
              2021-04-29 20:34:08 | [reader][i]Initializing reader
              2021-04-29 20:34:08 | [reader][i]Connecting to DVBT receiver via (exe:///usr/bin /dump1090-mutability --raw --mlat)
              2021-04-29 20:34:08 | [reader][i]Connected to the receiver, configuring
              2021-04-29 20:34:08 | [reader][i]Configured, processing messages
              2021-04-29 20:34:08 | [mlat][i]Waiting for MLAT configuration
              Posts not to be taken as official support representation - Just a helpful uploader who tinkers

              Comment


              • #22
                > Most decoders now don't bother?

                What do you mean?
                dump1090-fa and my readsb fork both have the --mlat option to modify the AVR output, it's just not enabled by default.
                And i don't see a reason to enable it, fr24feed if it wants timestamps should just parse the beast output, they can obviously already parse it somehow ... why not the timestamps, so this modified AVR seems kinda unnecessary to me except --mlat --raw which prints all the messages directly to the console output of the decoder ... this also works.
                So you could probably use either binary and replace the respective dump1090 binary and run it in the DVB-T mode ... not that i would suggest doing that as really why would you?

                > But then you can see there a post saying it was opened it up to non malformed as long as it had --mlat change. Kinda contradiction.
                Maybe they were getting bad data and disabled it server side.
                Being able to maybe enable it without changing the client code? I don't know ....

                > My main interest is better MLAT coverage in my local area. I only use vanilla FR24 software so it should work, but some of my local friends may unknowingly have sabotaged their MLAT feed to FR24 by changing the dump1090 software and/or starting feed to other networks. I can't really get a clear picture.

                Well the other networks show flexibility in regards to MLAT and have a solution that doesn't require their feed software occupying the SDR.
                (mind you, it needs changing the configuration that fr24feed even offers beast data which is what the other networks require for their feed clients so occupying the SDR like that just to have MLAT is not acceptable in my book)
                As you can see the answer from Khan in this thread was very limited and there seems no be not interest to find a solution.

                Other networks that do MLAT on RPis are Flightaware, ASDBExchange and Airnav.
                When using default configurations, none of them will spill MLAT results into fr24feed using either AVR or beast ouptut.
                Even with non-default settings there won't be MLAT results on AVR, there can be on beast but they have a special timestamp which could easily be detected and ignored by fr24feed.
                Then there are things like modesmixer ... there you could quite easily get AVR output of MLAT results that can't be distinguished from ADS-B.
                Only solution would be to remove their feeds / ban them from sending data.
                Last edited by wiedehopf; 2021-04-29, 08:58.

                Comment


                • #23
                  Originally posted by Oblivian View Post

                  So no --mlat too?
                  And yet, apparently.. According to above. It NEEDs dump1090-mutability. 1.14. And --mlat (the default cmd line passed)..

                  Go figure huh.
                  Just because you send it, does not mean they read it. That is really the geist of all this, no where is there any sign of FR24 telling the user that no, we do not accept your data because it is not good enough. Which would be a fair thing to do I think. Mind you, this is a company that last year made a profit of over 130000€ (or was it 1300000€?), so any argument that development of a better feeder would cost to much just falls flat.

                  I like FR24, and my friends do to. The end user interface is top notch. My mom can use it on her phone. It really bugs me though when time and effort just is ignored.
                  Last edited by hansp; 2021-05-03, 19:24.

                  Comment


                  • #24
                    Originally posted by hansp View Post

                    Just because you send it, does not mean they read it. That is really the geist of all this, no where is there any sign of FR24 telling the user that no, we do not accept your data because it is not good enough.

                    I like FR24, and my friends do to. The end user interface is top notch. My mom can use it on her phone. It really bugs me though when time and effort just is ignored.
                    Well aware of your points. And half the time people ask things it's the ideal that has to be pushed across. And often not believed. Off they go to FA forums saying I (we) are rude and unwilling to help etc.

                    The cumulative number of hours a few of us have put in to help people posting here in a timely manner to help rectify errors or feed dropping off because the way its setup is unique is huge.

                    It's generally not people that like the interface you see here to comment though. It's people trying to get a free subscription, or fix an error they see. (Outside dbase posts) or make sure what they're doing is working as it should

                    The pure number of 'mlat' and 'down' search hits in threads in the feeder section is a good indicator of how much people try to achieve it based on status.

                    Yet if it was hidden, poof. Dry up or wouldn't have existed.

                    Just like the years of 'my feeder ID doesnt show' that people have finally seem to have accepted is bung (despite adding a radar filter that appears to be not working..)
                    Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                    Comment


                    • #25
                      Yours, and other well known contributors efforts, are highly appreciated and the community would not be the same without you. Kudos for this.
                      Now, as painful that it might be, how does one go about replacing dump1090-fa with fr24 dump1090 without re-installing all other feeds that I have on my setups - FA, RB, OpenSky, ADSBx etc? Purge -fa and "just" install fr24feeder? Normally the questions in the forums are the other way around...

                      Comment


                      • #26
                        It hurts to explain this, it's such a bad design ...

                        In short you need to change the receiver type to dvb-t in fr24feed.ini and it will install its thing automatically.
                        Then configure --net via procargs in the fr24feed.ini .... make sure the raw and sbs output of FR24 are disabled otherwise the ports will clash with dump1090 using --net.

                        But again i really wouldn't recommend it.

                        Comment


                        • #27

                          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!!

                          @oblivian: I'm a little lost what you meant by this?
                          Just like the years of 'my feeder ID doesnt show' that people have finally seem to have accepted is bung (despite adding a radar filter that appears to be not working..)
                          What appears to be the issue with the Radar filtering? All user now should be able to filter for their own respective Feeder ID/Alias and see it on the main map screen.
                          Flightradar24.com Support

                          Follow us on Facebook and Twitter.

                          Please visit About Us, How it Works, FAQs, Blog and Forum for more information about Flightradar24.

                          Comment


                          • #28
                            Originally posted by Gaelan View Post
                            What appears to be the issue with the Radar filtering? All user now should be able to filter for their own respective Feeder ID/Alias and see it on the main map screen.
                            The 'filter by radar callsign' is working fine. It's cool to see what my receiver is doing on the FR24 front end screen. I don't see what the problem is.


                            F-KDAG1

                            Comment


                            • #29
                              Originally posted by Gaelan View Post
                              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!!

                              @oblivian: I'm a little lost what you meant by this?


                              What appears to be the issue with the Radar filtering? All user now should be able to filter for their own respective Feeder ID/Alias and see it on the main map screen.
                              Gaelan, thank you for responding.
                              I appreciate that you can not disclose proprietary information, but I think you maybe could give everybody a better understanding of how MLAT works beyond 'needing four or more receivers'. Like how is the timestamp relevant?

                              Especially what I as host can do to improve the data quality for MLAT. Is it specific configurations that are problematic?

                              Comment


                              • #30
                                Originally posted by Gaelan View Post
                                What appears to be the issue with the Radar filtering? All user now should be able to filter for their own respective Feeder ID/Alias and see it on the main map screen.
                                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.

                                Comment

                                Working...
                                X