Support Request: MLAT Aircraft Not Showing on tar1090 Map

[maidl]

First of all my setup:
Four ultrafeeder container (one "collector"/master and three which have access to their own SDR/Antenna). All four on the same host (defined in one compose yml).
Why four and not three? I like the idea to see which data comes from which antenna. This would not be possible with only three ultrafeeders, IMO.
Every antenna container sends it's data to the collector container via

- ULTRAFEEDER_CONFIG=
    adsb,ultrafeeder,30004,beast_reduce_plus_out;
    mlathub,ultrafeeder,31004,beast

The collector container sends data to adsbx (for now - I find this the easiest for dev, because e.g. no extra sign up needed,...):

- ULTRAFEEDER_CONFIG=
    adsb,feed1.adsbexchange.com,30004,beast_reduce_plus_out;
    mlat,feed.adsbexchange.com,31090

This works great so far, however I do not quite understand what to do, so MLAT results are also getting displayed on the tar1090 map when trying to follow the documentation for this part which states:

Note - due to design limitations of readsb, the tar1090 graphical interface will by default ONLY show MLAT results from the aggregators/MLAT sources that were defined with the MLAT_NET_CONNECTOR parameter. If you want to show any additional MLAT results (for example, those from piaware), you should add a separate READSB_NET_CONNECTOR for them. Adding these sources only to MLATHUB_NET_CONNECTOR will make the data available on the MLATHUB, but won't display them on your tar1090 map.

I couldn't find any examples for exactly this use case. Are there any?

My goal is to see the MLAT results on the main map (collector container) as well as on the maps of the antenna containers, if possible.

In this context: What exactly does READSB_FORWARD_MLAT_SBS and READSB_FORWARD_MLAT do? I'm currently using READSB_FORWARD_MLAT=true on my antenna containers and READSB_FORWARD_MLAT_SBS=true on the collector container. And I'm not banned from adsbx's MLAT network, yet. 😅

Thanks in advance =)

[kx1t]

Hi, what you are trying to do should be possible with this config. First, let's assume that your receiver ultrafeeder instances are called ultrafeeder-1 ultrafeeder-2 etc., and the "main" ultrafeeder instance is ultrafeeder-main.

Each Receiver Instance (ultrafeeder-1 ultrafeeder-2 etc.)

For your receiver instances (ultrafeeder-1 ultrafeeder-2 etc.), you should set up feeds like this:

      - ULTRAFEEDER_CONFIG=
          adsb,feed1.adsbexchange.com,30004,beast_reduce_plus_out;
          mlat,feed.adsbexchange.com,31090,39000
      - UUID=unique_UUID_for_this_container

This will:

• feed ADSB to adsbexchange on port 30004
• it will send MLAT data to adsbexchange on port 31090
• it will make the MLAT results available internally on port 39000.

The MLAT results will be picked up automatically by the MLATHUB instance, aggregated if you have multiple MLAT targets in this container, and then the aggregated MLAT results are available on port 31005 in Beast format. About that last one -- we'll use that below.

Make sure that your UUID is unique for each of the receiver instances -- the MLAT servers really don't like (as in -- they'll reject your connection) multiple connections with the same UUID.

If, in the future, you add additional MLAT targets, make sure that you increment the 39000 port for them. Here's an example of my setup for my Trenton feeder (https://kx1t.com/trenton-tar1090):

      - ULTRAFEEDER_CONFIG=
          adsb,dump978,30978,uat_in;
          adsb,feed.adsb.fi,30004,beast_reduce_plus_out;
          adsb,in.adsb.lol,30004,beast_reduce_plus_out;
          adsb,feed.airplanes.live,30004,beast_reduce_plus_out;
          adsb,feed.planespotters.net,30004,beast_reduce_plus_out;
          adsb,feed.theairtraffic.com,30004,beast_reduce_plus_out;
          adsb,data.avdelphi.com,24999,beast_reduce_plus_out;
          adsb,skyfeed.hpradar.com,30004,beast_reduce_plus_out;
          adsb,feed.radarplane.com,30001,beast_reduce_plus_out;
          adsb,dati.flyitalyadsb.com,4905,beast_reduce_plus_out;
          adsb,feed1.adsbexchange.com,30004,beast_reduce_plus_out;
          mlat,feed.adsb.fi,31090,39000;
          mlat,in.adsb.lol,31090,39001;
          mlat,feed.airplanes.live,31090,39002;
          mlat,mlat.planespotters.net,31090,39003;
          mlat,feed.theairtraffic.com,31090,39004;
          mlat,skyfeed.hpradar.com,31090,39005;
          mlat,feed.radarplane.com,31090,39006;
          mlat,dati.flyitalyadsb.com,30100,39007;
          mlat,feed.adsbexchange.com,31090,39008
      - UUID=${ULTRAFEEDER1_UUID}

Repeat this for each of the ultrafeeder receiver instances.

Getting all your data to your main ultrafeeder

Your main ultrafeeder only collects data from each of the receiver instances. You do that by simply ingesting ADSB from each of them, and then also connecting its MLAT hub to the MLAT data available at each of the receiver instances:

      - ULTRAFEEDER_CONFIG=
          adsb,ultrafeeder1,30005,beast_in;
          adsb,ultrafeeder2,30005,beast_in;
          mlathub,ultrafeeder1,31005,beast_in;
          mlathub,ultrafeeder2,31005,beast_in

Please study this architecture diagram carefully -- it shows how things work inside the ultrafeeder containers and which are the default ports available for each:

Specifically, you don't have to change any of the READSB_FORWARD_MLAT/READSB_FORWARD_MLAT_SBS style parameters to make this all work!

Let me know if this makes sense, and if so, please feel free to close the issue.

[maidl]

Thank you for your detailed reply!

After some more reading and some input on the SDR Enthusiasts Discord, I came to the conclusion, that it is not possible what I'm trying to achieve here: Having a central container/service which collects ADS-B and MLAT data from multiple SDRs (on the same machine) and send it to different services (from this centralized instance).
At least when it comes to MLAT, which data can not be "aggregated" to be sent to an MLAT service. The cause of this restriction is briefly explained here.

ADS-B data, on the other hand, indeed can be forwarded "aggregated" because there is no precise timing involved.

So, to conclude with a concrete example: If we take the statistics of FlightAware, with my three antenna approach, at least three sites would show up on the platform, because every receiver has to feed MLAT data by its own and every receiver is automatically considered a site.