Feed 1090ES + 978UAT to Different Sites

abcd567 · January 5, 2020, 2:10am

I have prepared a script which installs ModeSMixer2 on Raspberry PI, and configures it to receive data from dump1090-fa and dump978-fa, combine it and then serve it on port 32005 in beast format.

Copy-paste following command in terminal, and it will install ModeSMixer2, and configure it as combiner.

sudo bash -c "$(wget -O - https://raw.githubusercontent.com/abcd567a/combine-1090-978/master/install-combiner.sh)"

.

combiner-1

.
.
Once you have installed the combiner and it is running, you change port number from 30005 to 32005 in various feeder’s ini file as shown below:

Flightradar24 feeder

sudo nano /etc/fr24feed.ini

receiver=“beast-tcp”
host=“127.0.0.1:32005”

Planefinder feeder

sudo nano /etc/pfclient-config.json

{“tcp_address”:“127.0.0.1”,“tcp_port”:“32005”,“select_timeout”:“10”,“data_upload_interval”:“10”,“connection_type”:“1”,“aircraft_timeout”:“30”,“data_format”:“1”,“latitude”:“xx.xxxx”,“longitude”:“xx.xxxx”,“sharecode”:“xxxxxxxxxxx”}

Radarbox24 feeder

sudo nano /etc/rbfeeder.ini

[network]
mode=beast
external_port= 32005
external_host=127.0.0.1

.

Adsbexchange feeder

while sleep 30
do
/bin/socat -u TCP:localhost:32005 TCP:feed.adsbexchange.com:30005
done

.

MISCELLANEOUS

(1) To see map, charts, flight table etc, generated by ModeSMixer2 at this address in your browser:

IP-of-Pi:8787

(2) To see status and to restart ModeSMixer2

sudo systemctl status combiner
sudo systemctl restart combiner

(3) To view/edit config

sudo nano /usr/share/combiner-1090-978/combiner.conf

--inConnectId 127.0.0.1:30005:ADSB
--inConnectId 127.0.0.1:30978:UAT
--outServer beast:32005
--web 8787

NOTE: You can add following line below the last line to show station marker and range plot
--location xx.xxxx:yy.yyyy
Replace xx.xxxx by your latitude and yy.yyyy by your longitude

TO UNINSTALL

sudo systemctl stop combiner

sudo systemctl disable combiner

sudo rm /lib/systemd/system/combiner.service

sudo rm -rf /usr/share/combiner-1090-978

obj · January 5, 2020, 4:14am

Does modesmixer2 understand/convert UAT now then?

abcd567 · January 5, 2020, 6:45am

Not sure as unfortunately the UAT traffic in Toronto is only occasional, so I could not test it. At locations with substantial traffic, this can be easily tested by stopping dump1090-fa, and watching the output of port 32005 of ModeSMixer2 (or by watching it’s map).

I will now post this method in Russian forum ModeSMixer2 - Windows/Linux COM-TCP mixer and transcoder for ModeS, where Sergsero visits regularly, and will ask this question.

markrrichardson · January 5, 2020, 12:22pm

Newest version changed some locations, changed the port here:

sudo nano /etc/default/adsbexchange

Change this line:
INPUT="127.0.0.1:32005"

Then restart:
sudo systemctl restart adsbexchange-feed

Older versions had that in:
sudo nano adsb-exchange/adsbexchange-netcat_maint.sh

wiedehopf · January 5, 2020, 12:36pm

If you want to feed 978 to adsbexchange, you can also use this: GitHub - wiedehopf/adsbexchange-978: The ADS-B exchange UAT/978 feed client for use with dump978-fa

It will use an extra beast connection but adsbexchange doesn’t mind that.
Of course you’ll have to use other means for a combined map.

But it doesn’t really do anything majorly different to the stuff described here.
So no need to change.

Well actually changing that INPUT line also changes the input for MLAT, not sure if the mlat server will mind.

markrrichardson · January 5, 2020, 12:53pm

I see that now, I had not restarted MLAT service. I’ll check as soon as a couple of Southwest planes fly nearby, they don’t seem to all been converted to ADSB. Seemed to sync up.
EDIT: Confirmed two aircraft that are MLAT do show that I am feeding them to ADSBx. So, it appears MLAT works even with changing from 30005 to 32005.(Not a lot of MLAT planes anymore!!)

lines out output: 15

Data incoming from: 71.xx.xx.xx
Route: beast_front Port: 30005
Backend: beast_back
Connected: merge-3-7
Age: 1h32m

Data incoming from: 71.xx.xx.xx
Route: MLAT_front Port: 31090
Backend: MLAT_back_2B
Connected: mlat-b-2
Age: 4m5s

abcd567 · January 5, 2020, 6:36pm

Last night I asked this in Russian forum, and Sergsero promptly replied as below:
http://forum.adsb.in/f25/modesmixer2-windows-linux-com-tcp-mixer-transcoder-modes-1451/index129.html#post48026

abcd567 · January 5, 2020, 7:38pm

@obj
Thanks Oliver for pointing this out.
Based on Sersero’s reply, I will have to insert uat2esnt in the link between dump978-fa and mosesmixer2, as shown in green in the revised block diagram below… now I have to do some study, as I have absolutely no idea of uat2esnt

combiner-2

wiedehopf · January 5, 2020, 8:07pm

Compile it:

if ! [ -f $ipath/uat2esnt ]; then
	rm -rf /tmp/dump978 &>/dev/null || true
	git clone --single-branch --depth 1 --branch master https://github.com/flightaware/dump978.git /tmp/dump978
	cd /tmp/dump978/legacy
	make uat2esnt
	cp uat2esnt $ipath
fi

Use it:

	socat -u "TCP:$SOURCE,forever,interval=15" STDOUT | "$IPATH/uat2esnt" $CONVERT_OPTIONS | socat -u STDIN "TCP:localhost:$AVR_IN_PORT"

Excerpts from GitHub - wiedehopf/adsbexchange-978: The ADS-B exchange UAT/978 feed client for use with dump978-fa

SweetPea11 · January 6, 2020, 12:56am

I may be a bit confused as we (fortunately) don’t have UAT in Australia.

My understanding is that UAT is not as accurate nor reliable as ADS-B Extended Squitter.

Assuming that is the case, would converting UAT to ES lower the reliability of the data passed to the various aggregators?

Would it not be better to wait until Planeplotter, Planefinder, FR24 etc gear up to handle UAT as UAT and the users able to treat the various plottings with the appropriate confidence?

The reason I ask is that someone in my neighbourhood is feeding MLAT aircraft to ADSBexchange and it is being shown MLAT=No implying ADS-B ES accuracy which is obviously incorrect and the aircraft trail is quite misleading.

As I said, I am just guessing.

S.

obj · January 6, 2020, 3:11am

This is not true AFAIK.

The main issue is that the conversion loses some detail that’s present in the original messages. This is why piaware wants to directly process the original messages.

That’s the ideal case but it may not be a priority for them. I’d like to retire uat2esnt entirely but until the rest of the world catches up it’s still going to be needed in some places.

This may be an adsbexchange issue more than anything. mlat-client goes to some trouble to try to mark any position messages it generates as being synthetic messages generated by mlat. It’s possible to mangle the data in such a way that this marker gets lost, but it requires unusual setups and it seems fairly rare (we’ve seen maybe half a dozen cases ever)

Also “ES accuracy” is fairly meaningless unless you’re actually looking at the accuracy indicators contained in the messages. A 1090ES position message can potentially have an accuracy varying from “I have no idea, maybe >10NM error” to “accurate to within single-digit meters”. Mlat-generated messages set the worst possible accuracy (“I have no idea”) there. dump1090 decodes these fields if you’re interested (look for nac_p, pos_rc, etc)

SweetPea11 · January 6, 2020, 3:47am

Thanks @obj

I really do appreciate you taking the time to explain.

I did start off by expressing that “I don’t know what I don’t know” (with due deference to Donald Rummsfeld.

This is the point that I was trying to get to and my follow up which is;

Does this lost detail degrade the quality of the data for those aggregators for whom the priority is not yet to deal natively with UAT data?

If so, in that case would it not be better to refrain from sending UAT data dressed up as something more accurate rather than sending somewhat degraded data?

What I see here is that ADSBexchange flags every aircraft as MLAT=No so somewhere along the line the synthetic messages generated by mlat information is lost and ADSBexchange data reliability is questionable.

Once again, thanks for you explanation.

S

obj · January 6, 2020, 4:16am

The quality will be somewhat worse than processing the messages natively, but this is mostly about answering specific questions like “what transponder type / version is installed?” or “what are the current autopilot settings?” or “what are the aircraft dimensions?”. The position/groundspeed information should be about the same quality.

PiAware definitely wants the original data, not the translated data, because the original detailed data is useful to FA. It may be less useful to other aggregators; I don’t know exactly what they’re capturing/using and whether they’d rather have translated data or no data at all. It would be a good idea to check with them before feeding translated data.

abcd567 · January 6, 2020, 6:38pm

The Radarbox24 map NOW has , so it appears they are geared to receive UAT. However they have not yet announced their configuration method to feed UAT.

.

abcd567 · January 8, 2020, 12:07am

@obj : FYI

Additional reply by Sergsero about ModeSMixer2 handling UAT978 messages:

http://forum.adsb.in/f25/modesmixer2-windows-linux-com-tcp-mixer-transcoder-modes-1451/index130.html#post48041

obj · January 8, 2020, 5:03am

As sergsero is the only one who can fix modesmixer, I’m not sure there’s much I can do with that.

This is the relevant bit of the spec:

The corresponding uat2esnt code selects:

(CF=6, IMF=0) for direct UAT from the aircraft
(CF=2, IMF=0) for UAT TIS-B with an ICAO address (this also includes 1090->978 ADS-R)
(CF=2, IMF=1) for UAT TIS-B with a track file identifier (this should perhaps be CF=5 IMF=0; the UAT spec describes the address in this case as “TIS-B target with track file identifier” but doesn’t specify the format of the address)
(CF=1, IMF=1) for anything else (this should perhaps be CF=6 IMF=1)

Also uat2esnt should probably suppress address_qualifier=6 messages (“ADS-R target with non-ICAO address”) to avoid loopback. The legacy dump978 code doesn’t actually understand AQ=6 properly as it was written before I had access to the latest UAT spec.

github.com

mutability/dump978/blob/master/uat2esnt.c#L226


      
              double Dlat = 360.0 / (odd ? 59 : 60);
              int YZ = floor(NbPow * cprMod(lat, Dlat) / Dlat + 0.5);
          
          
    double Rlat = Dlat * (1.0 * YZ / NbPow + floor(lat / Dlat));
              double Dlon = (360.0 / cprN(Rlat, odd));
              int XZ = floor(NbPow * cprMod(lon, Dlon) / Dlon + 0.5);
          
          
    return XZ & 0x1FFFF; // always a 17-bit field
          }
          
          
static int encode_cf(struct uat_adsb_mdb *mdb)
          {
              // Encode the CF field for DF 18; this says whether this
              // is a TIS-B message, an ADS-B rebroadcast, etc
              switch (mdb->address_qualifier) {
              case AQ_ADSB_ICAO:
                  return 6; // ADS-B rebroadcast, will use IMF=0
              case AQ_TISB_ICAO:
                  return 2; // Fine TIS-B message, will use IMF=0
              case AQ_TISB_OTHER:
                  return 2; // Fine TIS-B message, will use IMF=1

sergsero · January 8, 2020, 11:56am

Hello,

Indeed, it would be a good idea to establish some unified approach to 978UAT message rebroadcast.

In my opinion, it is sufficient to use the standard formats and coding of ADS-B Rebroadcast Service (ADS-R) if we consider 978UAT as an alternative form of ADS-B in relation to 1090ES, just as it is done in the documentation. In other words, we can use only CF=6 with the ICAO/Mode A Flag (IMF)=0/1, because ADS-B rebroadcast information is transmitted using the same 112-bit Mode S DF=17 format.

As the documentation reports this one-bit field (bit 8) should indicate the type of identity associated with the aircraft data reported in the TIS-B message. IMF=0 indicates that the ADS-B Rebroadcast data is identified by an ICAO 24-bit address, IMF=1 indicates that the ADS-B rebroadcast data is identified by an anonymous 24-bit address.

I don’t know if the 978UAT messages are transmitting information that is received from a primary radar, if yes, that the TIS-B report on that target should indicate a “Mode A” code of all zeros.

For example, format of Airborne Position Message will be identical the same DF=17 (1090ES) except that “ME” bit 8 is redefined to be the ICAO/Mode A Flag (IMF) and Airborne Velocity Messages will be with the redefined bit " ME " 9 and so on for other types of data.

But, in reality, we can leave everything as it is and use the fundamental uat2esnt’s algorithm.

Best regards,
sergsero

obj · January 8, 2020, 1:58pm

I don’t think it’s sufficient to use only CF=6 if you want to distinguish e.g. TIS-B Mode A radar vs. TIS-B Mode S radar vs ground vehicles vs. 1090ES-equippped aircraft. The existing mapping tries to map all that detail to 1090 (though it probably gets a couple of things wrong)

sergsero · January 9, 2020, 1:24pm

I was looking at the task of how to expand an airborne traffic situational awareness exclusively to the user of the ‘Mode S + 1090ES’ system by adding only the missing data from the 978UAT channel.

And to avoid duplication of identical data when combining the two datalinks.

If I understand correctly ADS-R is ground based service that relays ADS-B messages on one datalink to another. Since the only country with two datalinks today is the US, that’s the only place we will see ADS-R messages. For 1090ES, it also uses DF=18. It can be distinguished from TIS-B by the address type field.

If set the task of transforming all the information from the UAT978 channel to the 1090ES format, then of course you are right and you need to use the maximum possible species identification of the data by CF and IMF.

Unfortunately, I am not able to receive UAT978 live data channel and see what kinds of messages are actually present there and how much they duplicate the 1090ES channel.

obj · January 9, 2020, 1:32pm

In theory all the TIS-B data is duplicated between 978 and 1090 (though it somewhat depends on what the FAA is doing - they only send TIS-B for an area when there is an aircraft that they can hear that advertises the right capabilities - but I don’t know if they make that decision separately for 1090 vs 978 or not).

uat2esnt actually has a -t option to suppress all the 978 TIS-B for that reason.

Topic		Replies	Views
Feed trought PI ADS-B Flight Tracking	19	1367	January 19, 2023
Lost it! ADS-B Flight Tracking	7	2946	February 7, 2016
Combining multiple receivers into one map - Combine1090 ADS-B Flight Tracking	66	9369	January 23, 2023
Sharing my data ADS-B Flight Tracking	9	2093	July 27, 2019
Piaware Issues ADS-B Flight Tracking	2	1425	July 17, 2015