Page 36 of 91 FirstFirst ... 2634353637384686 ... LastLast
Results 351 to 360 of 901

Thread: Archived - Beta test MLAT software for Raspberry Pi

  1. #351
    Passenger
    Join Date
    Aug 2015
    Location
    Guernsey (T-EGJB6)
    Posts
    11
    Quote 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 at 19:30.

  2. #352
    First officer
    Join Date
    Mar 2013
    Location
    Arhus (T-EKAH3), Denmark
    Posts
    345
    Quote 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?

    atr no mlat6.png
    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."

  3. #353
    Flight attendant
    Join Date
    Apr 2015
    Location
    Sydney, Australia
    Posts
    68
    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 at 08:22. Reason: fixed up the link for the other post
    T-YSBK22

  4. #354
    First officer
    Join Date
    Mar 2013
    Location
    Arhus (T-EKAH3), Denmark
    Posts
    345
    Quote 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.

  5. #355
    Passenger
    Join Date
    Nov 2014
    Posts
    31
    Quote 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 at 14:02.

  6. #356
    First officer
    Join Date
    Mar 2013
    Location
    Arhus (T-EKAH3), Denmark
    Posts
    345
    Quote 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?

  7. #357
    Passenger
    Join Date
    Nov 2014
    Posts
    31
    Quote 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.

  8. #358
    Flight attendant
    Join Date
    Apr 2015
    Location
    Sydney, Australia
    Posts
    68
    Quote 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

  9. #359
    Super Moderator
    Join Date
    May 2011
    Location
    T-NZCH1, PP:PH New Zealand
    Posts
    5,057
    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

  10. #360
    Passenger
    Join Date
    Sep 2015
    Posts
    2
    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 at 20:50.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •