coverage-3A

Discussion in 'Feeding' started by Humphrey, Sep 14, 2019.

  1. Humphrey

    Humphrey New Member

    I don't understand this map.
    Previously I had an experimental feed that produced a lot of green coverage on the map.
    I have now installed ADSBx on my normal PiAware machine (with a different feeder name) and I get much less coverage reported.
    Does the map represent new points from a feeder2 combined with my IP so the previous green points reported by feeder1 are not displayed?
     
  2. Humphrey

    Humphrey New Member

    Update.

    Restarted both feeds, now I have no data and no MLAT sync listed.

    In case it is relevant regarding the initial question, feed 1 is a PiAware SD card installation, feed 2 is a Buster lite installation with FlightAware package install.
     
  3. wiedehopf

    wiedehopf Administrator Staff Member

    If i'm not mistaken the 3A MLAT server is regularly overloaded and refuses new connections.
    Thus let MLAT do it's thing, don't worry about it.

    All MLAT stuff, be it coverage or sync is managed by username you give when configuring the feed.

    The beast feed (ADS-B) should work regardless.
     
  4. James

    James Guest

    Give it time to sync up. The heatmap is a heat map, colors on that say nothing about quality of MLAT.

    And it's only updated hourly.


    If you are referring to:
    http://adsbx.org/sync/

    Then those colors mean something.
     
  5. Humphrey

    Humphrey New Member

    Am I providing useful data in the meantime when MLAT is not synchronised?
     
  6. wiedehopf

    wiedehopf Administrator Staff Member

    Well if you're not connected to the MLAT server, you are not providing useful data obviously.
    But it's not like you can do anything about the server being overloaded.

    Which username did you chose when running the setup script?

    You can also just post the output of this command, it'll show you configuration:
    cat /etc/default/adsbexchange

    Or check the local log for the mlat client:
    journalctl -eu adsbexchange-mlat

    Both commands will only work if you installed quite recently as the scripts have changed.
     
  7. Humphrey

    Humphrey New Member

    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    ADSBx-feeder-01 and 02 if i recall correctly

    RECEIVERPORT=30005

    -- Logs begin at Sat 2019-09-14 09:03:54 BST, end at Sat 2019-09-14 23:24:41 BST. --
    -- No entries --


    Edit:
    Just checked, both connected now.
    Faith now fully restored in patience.
     
    Last edited: Sep 14, 2019
  8. Humphrey

    Humphrey New Member

    Rather frustrating that this project is overloaded with data contributor, my feeders seem to be of use about 10% of the time.
    Shutting down one in the hope the other may be of use, and it is feeding other projects.
     
  9. James

    James Guest

    No, just because MLAT is flaky. That's very very small portion of your data.

    MLAT is JUST MLAT.

    If your feeder is connected to 30005, which is a total separate connection from the MLAT - then you are sending good data.

    MLAT is MLAT.

    I really need to turn off all these logs, so people stop starting at the connection and think they know what the hell they are talking about.

    I don't know how many posts there are about MLAT, with the same answers. Don't stare at the logs, Just let it do it's thing.

    If it needs to reconnect and stabilize then it needs to reconnect and stabilize.

    FlightAware, FlightRadar24 has the same issues they just hide it from feeders and then there is no log staring and mental illness about it.

    Let it do it's thing. Do not stare at the logs and panic every second that the MLAT client is attempting to sync.

    Don't stop feeding just because MLAT is reconnecting or doing things. <face palm>
     
    Last edited by a moderator: Sep 15, 2019
  10. James

    James Guest


    The heat map is updated hourly.

    If your feeder as lower coverage, look at your local dump1090 map, then you will have less MLAT syncs and therefor less heatmap.

    Figure out what changed with feed install if it suddenly gets less range. Is it a coax/connector issue? Is there a new RF source nearby? etc etc ...
     
  11. wiedehopf

    wiedehopf Administrator Staff Member

    -.-
    The logs were mostly the reason i changed everything to systemd.
    People have been complaining about not being in the sync page even without the logs.

    It's natural to check MLAT sync after running the install scripts.
    Maybe just add something to the MLAT sync reference that some servers are overloaded and it may be a couple of days before you see that it's syncing.

    Generally add a remark that one should wait at least a day and check if it's working after a day.
    People will always want to check that the feed is working, that's just how it is.
     
  12. Humphrey

    Humphrey New Member

    Hello
    -------------------------------------------------

    Thank you James
    Sorry
    I'm just frustrated with the mixed messages I have been receiving on the forum and the disappearance of feeds on the heatmap.
    I think this is a valued project that I'm not trying to undermine in any way.
    As a (in my opinion) helpful suggestion could the heatmap page be altered so that it does not remove the visibility of feeders without current MLAT synchronisation?

    This may not be anywhere as simple to achieve in reality, but may remove some confusion for people?
     
  13. James

    James Guest

    I don't have time to alter the heatmap that mlat-server creates. It's a mess and we've done the best we can with it without a complete rewrite. You can thank FlightAware for shutting down development on it.

    Taner has put a bunch of time into it to make it improved.
    https://github.com/TanerH/mlat-server

    The heatmaps are going away once I get 'status' script done that will install beside the feeder / mlat.

    The heatmap is created every hour from 'currently synced feeders' and it really isn't great how it does it. So I don't want to waste the time making it 'static' , but like I said the map is going away and will be replaced by adsbx.org output and status direct from the Pi.

    http://adsbx.org/sync polls every 30 seconds, direct from the mlat-server status json.

    Truthfully MLAT is going away in the next few years as people switch to ADS-B out.
     
  14. James

    James Guest

    Is the range lower in feeder-02?

    Sometimes they will be dropped if they don't have any synced aircraft for long periods of time.
     
  15. James

    James Guest

  16. James

    James Guest

  17. Humphrey

    Humphrey New Member

    01 is offline, as in shutdown. I was initially experimenting with a cheap dongle.
    02 is online, but not showing up most of the time.

    Edit due to grammatical gibberish.
     
    Last edited: Sep 16, 2019
  18. Humphrey

    Humphrey New Member

    feeder-02 has more aircraft tracked per day and more messages too. Yesterday, with the same setup, FlightAware was showing >3,000 aircraft and >1,000,000 positions, >20,000 of them MLAT.
    I was only running feeder-01 to get some confidence in the ADSBx installation, before risking trashing my main feed.
    It was then that I noticed that feeder-01's heatmap was showing a lot more coverage than feeder-02 on ADSB exchange
     
  19. fvance

    fvance New Member

    Understand the desire to phase out the heatmaps. One useful aspect of the maps I would like to see an alternative for is seeing (approximately) where feeders currently exist, and where there may be gaps in coverage.