Announcement

Collapse
No announcement yet.

Archived - Beta test MLAT software for Raspberry Pi

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Have ordered a RPi2 to join the party and do some other tasks, you guys mostly running Raspbian or is there a slimmer/faster alternative I should look at. Not too afraid of a lack of gui if it comes to it.
    Posts not to be taken as official support representation - Just a helpful uploader who tinkers

    Comment


    • Originally posted by bhaal View Post
      Just put it in the startup script to modify the /etc/fr24feed.ini file with the correct coordinates before you start fr24feed...
      Can someone please write the correct syntax for these options????

      Gesendet von meinem HTC One mit Tapatalk

      Comment


      • Originally posted by Oblivian View Post
        Have ordered a RPi2 to join the party and do some other tasks, you guys mostly running Raspbian or is there a slimmer/faster alternative I should look at. Not too afraid of a lack of gui if it comes to it.
        Yup, just running Raspbian .... its all pretty easy if you're not afraid to get down and dirty at the command line :-) just be aware of the little quirks of running both both FR and FA on the one RPi (mainly to do with MLAT feedback from FA)
        T-YSBK22

        Comment


        • Originally posted by rodeo View Post
          Yup, just running Raspbian .... its all pretty easy if you're not afraid to get down and dirty at the command line :-) just be aware of the little quirks of running both both FR and FA on the one RPi (mainly to do with MLAT feedback from FA)
          FA gets mine from Planeplotter currently. Not sure I'll have the processing left over to do that anyway once I work out how to pipe some Pocsag and CCIR decoding through it
          Posts not to be taken as official support representation - Just a helpful uploader who tinkers

          Comment


          • I don't know why but I have the problem, that the DVB-T stick disconects again...since some days (maybe last 9th or 10th september...)

            dmesg looks like this, again:

            [ 418.294221] usb 1-1.5.4: new high-speed USB device number 7 using dwc_otg
            [ 418.406266] usb 1-1.5.4: New USB device found, idVendor=0bda, idProduct=2838
            [ 418.406291] usb 1-1.5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
            [ 418.406309] usb 1-1.5.4: Product: RTL2838UHIDIR
            [ 418.406325] usb 1-1.5.4: Manufacturer: Realtek
            [ 418.406341] usb 1-1.5.4: SerialNumber: 00000001
            [ 418.440797] usb 1-1.5.4: dvb_usb_v2: found a 'Realtek RTL2832U reference design' in warm state
            [ 418.496092] usb 1-1.5.4: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
            [ 418.496176] DVB: registering new adapter (Realtek RTL2832U reference design)
            [ 418.512063] i2c i2c-3: Added multiplexed i2c bus 4
            [ 418.512110] rtl2832 3-0010: Realtek RTL2832 successfully attached
            [ 418.512191] usb 1-1.5.4: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
            [ 418.512618] r820t 4-001a: creating new instance
            [ 418.524860] r820t 4-001a: Rafael Micro r820t successfully identified
            [ 418.546290] Registered IR keymap rc-empty
            [ 418.546863] input: Realtek RTL2832U reference design as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5.4/rc/rc0/input2
            [ 418.547189] rc0: Realtek RTL2832U reference design as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5.4/rc/rc0
            [ 418.548079] input: MCE IR Keyboard/Mouse (dvb_usb_rtl28xxu) as /devices/virtual/input/input3
            [ 418.548904] rc rc0: lirc_dev: driver ir-lirc-codec (dvb_usb_rtl28xxu) registered at minor = 0
            [ 418.548935] usb 1-1.5.4: dvb_usb_v2: schedule remote query interval to 200 msecs
            [ 418.557523] usb 1-1.5.4: dvb_usb_v2: 'Realtek RTL2832U reference design' successfully initialized and connected
            [ 418.557881] usbcore: registered new interface driver dvb_usb_rtl28xxu
            [ 500.992929] usbcore: deregistering interface driver dvb_usb_rtl28xxu
            [ 501.195585] r820t 4-001a: destroying instance
            [ 501.195962] usb 1-1.5.4: dvb_usb_v2: 'Realtek RTL2832U reference design' successfully deinitialized and disconnected


            I only did a "fr24feed restart" between the conect and the automatic disconect of the stick
            T-EDDC46

            Comment


            • Originally posted by Kpin View Post
              I have been following one aircraft I know not to be ADS-B equipped flying along the north coast of The Nederlands, and clearly some of the Raspberry Pi feeders are feeding Flight Aware calculated positions back into FR24.

              So fare I have seen T-EHAM63 and T-EHSB7 shown as the radar for this aircraft (OY-EUR). Something should be done to weed these position reports out.
              I've just seen another example of this with flight GR679 from Manchester to Guernsey which is operated by G-VZON, an ATR-72 - definitely MLAT only.

              However, I have just seen it supposedly tracked down the UK by no less than 6 T-xxxx feeders which are clearly pumping backfed MLAT data (presumably from FlightAware) into FR24:

              T-EGCC96
              T-EGGP49
              T-EGLK18
              T-EGSS27 (a feeder near Stansted favoured when the aircraft is almost over Southampton at FL150? Very dodgy!)
              T-EGHI61
              T-EGLK18 (again)
              T-EGHI62

              Tracking only changed to MLAT when it was mid-channel and presumably out of range of that last EGHI (Southampton) feeder contributing to the 3rd party MLAT feed.

              FR24, surely it is easy to detect this server side when you are getting ADS-B data for a particular aircraft from only a couple of feeders and the majority are picking up non-ADS data and either contact those concerned or disregard their feed data?

              Perhaps we should start a name and shame thread?

              atr no mlat6.png
              Last edited by cbgsy; 2015-09-15, 19:30.

              Comment


              • Originally posted by cbgsy View Post
                I've just seen another example of this with flight GR679 from Manchester to Guernsey which is operated by G-VZON, an ATR-72 - definitely MLAT only.

                However, I have just seen it supposedly tracked down the UK by no less than 6 T-xxxx feeders which are clearly pumping backfed MLAT data (presumably from FlightAware) into FR24:

                T-EGCC96
                T-EGGP49
                T-EGLK18
                T-EGSS27 (a feeder near Stansted favoured when the aircraft is almost over Southampton at FL150? Very dodgy!)
                T-EGHI61
                T-EGLK18 (again)
                T-EGHI62

                Tracking only changed to MLAT when it was mid-channel and presumably out of range of that last EGHI (Southampton) feeder contributing to the 3rd party MLAT feed.

                FR24, surely it is easy to detect this server side when you are getting ADS-B data for a particular aircraft from only a couple of feeders and the majority are picking up non-ADS data and either contact those concerned or disregard their feed data?

                Perhaps we should start a name and shame thread?

                [ATTACH=CONFIG]6438[/ATTACH]
                Name and shame might be a bit dramatic. However I suspect that many hosts does not even know that their FA data will end up on FR24 and how to avoid this. So name the receivers and then FR24 could contact them.

                I reported the problem to support and they are aware of this but apparently unable to fix it at the moment:

                "Yes, that is happening at the moment. Our developers are looking into it.
                At the moment the option is to completely block those feeds but they are not feeding bad data continuously. Well, our developers are looking into it and hopefully they will come up with a solution soon."

                Comment


                • Easy quick solution is what bhaal suggested in this post: http://forum.flightradar24.com/threa...ll=1#post68679

                  which is, to quote:

                  sudo piaware-config -mlatResultsFormat "basestation,listen,31003"

                  this will stop the FA mlat client sending mlat positions back to dump1090 (and therefore stop it screwing everything up for fr24feed) and also allow you to add the feed mlat position feed to VRS on port 31003.


                  This is what I have done and I believe it to be working, as a good stop-gap measure.

                  There is a few feeders here in Sydney suffering the same issue (hopefully I'm not one of them !!)
                  Last edited by rodeo; 2015-09-16, 08:22. Reason: fixed up the link for the other post
                  T-YSBK22

                  Comment


                  • Originally posted by rodeo View Post
                    Easy quick solution is what bhaal suggested in this post: http://forum.flightradar24.com/threa...ll=1#post68679

                    which is, to quote:

                    sudo piaware-config -mlatResultsFormat "basestation,listen,31003"

                    this will stop the FA mlat client sending mlat positions back to dump1090 (and therefore stop it screwing everything up for fr24feed) and also allow you to add the feed mlat position feed to VRS on port 31003.


                    This is what I have done and I believe it to be working, as a good stop-gap measure.

                    There is a few feeders here in Sydney suffering the same issue (hopefully I'm not one of them !!)
                    Brilliant, but the FA/FR24 feeder has to be told that they are doing something wrong.

                    Comment


                    • Originally posted by cbgsy View Post
                      FR24, surely it is easy to detect this server side when you are getting ADS-B data for a particular aircraft from only a couple of feeders and the majority are picking up non-ADS data and either contact those concerned or disregard their feed data?
                      It is trivial to detect and discard these messages in the feeder. The synthetic mlat position messages are deliberately easy to recognize because, given all the different possible setups, there's no way that mlat-client can guarantee that the data won't go somewhere it shouldn't.

                      Note that the standard FlightAware/piaware sdcard images, which is the large majority of installs, do not forward mlat outside their own systems unless explictly told to. mlat-client sends synthetic position messages to dump1090, but dump1090 is configured not to forward those messages further (e.g. it will not send them back out on port 30005). They can only escape if the user explicitly asks to forward them, or if piaware is installed on top of an existing system that forwards them.

                      I contacted FR24 / Planefinder / VRS at the time I developed this to let them know they may start seeing these messages, with details on how to recognize and discard them as needed.

                      Planefinder had it supported in a matter of hours.

                      VRS added support for marking mlat messages as such, and has gone through a whole release cycle with that support now.

                      I have had no response from FR24 at all, so I suppose it's not really important to them. If it is important to them.. perhaps they can reply to my email.
                      Last edited by obj; 2015-09-16, 14:02.

                      Comment


                      • Originally posted by obj View Post
                        I contacted FR24 / Planefinder / VRS at the time I developed this to let them know they may start seeing these messages, with details on how to recognize and discard them as needed.

                        Just so I understand: You are the developer behind dump1090, and those feeder hosts cross feeding from FA to FR24 must be doing this deliberately, because dump1090 would not normally do this?

                        Comment


                        • Originally posted by Kpin View Post
                          Just so I understand: You are the developer behind dump1090, and those feeder hosts cross feeding from FA to FR24 must be doing this deliberately, because dump1090 would not normally do this?
                          I maintain a fork of dump1090, work on piaware, and wrote mlat-client / mlat-server and the variants of those that Flightaware uses. See https://github.com/mutability/

                          The cross-feeds may be accidental, but a vanilla Flightaware sdcard image will not do this by default - it requires reconfiguration before it will forward mlat data. This filtering happens within the version of dump1090 provided on the image. Current development versions of dump1090-mutability behave in the same way, you must explicitly pass --forward-mlat before they will forward it. Other dump1090 versions may forward mlat data regardless - if you install the piaware feeder manually into an existing system, this could happen if the user doesn't take care.

                          It's also possible that the cross-feeds are actually nothing to do with Flightaware, and they're coming from another multilateration source such as mlat-radar.net (which also uses mlat-server / mlat-client) which has fairly complete UK coverage.

                          Part of the problem is that there is a huge variety of different bits of software involved, and it's not at all practical to require that only particular software is used. That's why the approach is to make the positions easily identifiable so when they do, inevitably, leak out, you can detect that and ignore them. The lack of an ADS-B data exchange protocol that can also carry metadata doesn't help here.

                          It would be great to have a better, more robust way of doing this. But it requires coordination between all the bits of software involved, and despite my efforts that has not happened.

                          Comment


                          • Originally posted by obj View Post
                            Other dump1090 versions may forward mlat data regardless - if you install the piaware feeder manually into an existing system, this could happen if the user doesn't take care.
                            I think you've nailed it obj .... it appeared to start when FR24 started the MLAT beta trials using their own version of dump1090. If you had piaware installed as well then it would happen, hopefully now that they have removed that restriction the occurances of it happening will decrease. I noticed that it stopped happening for me after I got around to (finally) installing mutability (thankyou BTW !!). The main reason for doing that - I like your version of the local web view amongst other things.

                            Obviously, someone who is not prone to tinkering like me will leave things as installed and thats where the problems are starting. There's a couple of feeders here in Sydney that obviously have stock installs.

                            Cheers.
                            T-YSBK22

                            Comment


                            • The simplicity of the how-to may also hamper that.

                              Most people are happy to share data here and there to multi sites to increase the coverage of not 1 in particular. And at the same time may only visit support/forums when they have to if it just 'works' by following a guide.
                              Of course many of these users will have done the setup and not updated versions since, nor have the one capable of self-updating (or may not even know the commandline to pull from the repository as a couple of low-posters have asked for assistance for here)

                              Catch22 really. Add features to make stuff better, hampered by first editions. Like we are seeing with web development now. Older platforms requiring early IE versions, now don't support the new browsers. Update browser, find it doesn't work with older web server code they have not updated elsewhere to support Web3->HTML5 ARGH
                              Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                              Comment


                              • I like to setup different Raspberry pi's in this region to see all the General Aviation flying around here using the mlat capabilities of FR24, also at low altitude's.
                                On the forum I read a lot about this topic and so far I understood a non ADS-B plane should be seen by minimal one FR24 (F) feeder and three Raspberry pies. They all should see an ADS-B plane as reference.
                                In this region I see local mlat planes above 3000ft. At lower altitudes they disappear. During the same flight of those local planes, I see the radar changing from mlat into T-feeders. The T-feeders are all the time of the same four feeders. If the radar is changing from mlat to a T-feeder the plane is jumping to another position (1-2 km) So it's not very accurate.
                                Last week I set up my first pi and it's running well.

                                My question is: Will a Radarcape receiver be seen as a F-feeder from FR24? So if I use that feeder together with some Rasberry Pi's in the region will I see alle the planes at low altitude?
                                Last edited by Cooler; 2015-09-19, 20:50.

                                Comment

                                Working...
                                X