MLAT and Piaware

FlightAware ADS-B Flight Tracking
1

I currently have one ADS-B receiver setup using a raspberry pi and PIAware. I’ve been trying to read up about MLAT and how it works with PiAware.
So, If I were to install 3 more ads-b across my area MLAT then would be enabled and this would improve the accuracy and reporting of all 4 receivers.

That then means 3 more raspberry pi’s all with their own unique setup and webservice being broadcasted.

Does this mean each raspberry pi’s webservice will display a corrected map for all flights in my area?

I’m currently making use of the data stream from my single localhost:8080/data/aircraft.json

Does that mean all raspberry pi’s will not broadcast an updated values with MLAT taken in account? If not is there a similar stream that is available?

Or is this something only flight aware will benefit from and my 4 raspberry pi’s will only display what they each individually see? Further, does MLAT work with other peoples devices in my area? Or just ones registered with my account.

2

Actually having more than one MLAT receiver in the same location can actually degrade MLAT positions. MLAT sychronizes with other receivers. Look on your FA stats page. Here is a line from my stats page:
Multilateration (MLAT): Supported / Enabled (synchronized with 270 nearby receivers)

3

Wat?

On the topic:
Depends on the current coverage of the area.

Well even if there already is good coverage having more receivers increases the likelihood that at least one of your receiver gets used for at least one MLAT calculation for each aircraft.
To take advantage of that you’ll have to combine the MLAT results (and ADS-B messages while you’re at it) into an extra dump1090-fa / readsb instance running in net-only mode.

If coverage is lacking, adding receivers will improve MLAT signifantly.

1 Like
4

Do you know of any good guides or documentations?

I found this GitHub - wiedehopf/combine1090: Combine data from multiple ADS-B receivers into one readsb decoder / tar1090 webinterface

1 Like
5

I was told by FR24 support that multiple receivers at the same location can actually degrade MLAT accuracy. I have 5 receivers two of which are at the same location. Thus the email from FR24 support.

6

Sounds like a problem with FR24’s implementation. There’s no inherent reason why it’s a problem.

FlightAware’s mlat will not treat them as distinct receivers for the purposes of the number of degrees of freedom in the solution, but it’ll use the data - essentially, for receivers with the same location, this ends up averaging the receive time.

7

FR24 have a strange requirement as shown inside red rectangle in screenshot below.

This requirement means that if instead of their bundled dump1090-mutability (EB_VER), another decoder such as dump1090-fa or modeSDeco2 is installed and DVB-T is used by it, and fr24feed gets data from it, their MLAT wont work !!!

image

1 Like
8

The really strange thing is that they don’t automatically disable it if you use another source.
Also the logs look normal with beast input, while they don’t look normal when you for example give them AVR.
It’s completely nonsensical.

9

My fr24feed uses avr-tcp from a PiAware image. (What is AVR, anyway?) I saw logs like the following

2020-11-06 09:33:59 | [mlat][i]Waiting for MLAT configuration
2020-11-06 09:34:07 | [mlat][i]MLAT configuration received, service ENABLED
2020-11-06 09:34:07 | [mlat][i]Starting MLAT with preconfigured position: x
2020-11-06 09:34:07 | [mlat][i]MLAT bandwidth reduction active, level 1
2020-11-06 09:34:07 | [mlat][i]Configuring UDP connection udp://usa-2.fr24.com:19788
2020-11-06 09:34:07 | [mlat][i]Registering MLAT station
2020-11-06 09:34:07 | [mlat][i]Registering MLAT station: SUCCESS
2020-11-06 09:34:10 | [mlat][i]No ADS-B time reference available (0/0)
2020-11-06 09:34:21 | [mlat][i]Received ADS-B time references AC:
2020-11-06 09:34:21 | [mlat][i] AD6EC5
2020-11-06 09:34:21 | [mlat][i]Pinging the server
2020-11-06 09:34:21 | [mlat][i]Stats 6185942/6185942
...
2020-11-06 09:36:00 | [mlat][i]Received ADS-B time references AC:
2020-11-06 09:36:00 | [mlat][i] AD6EC5
2020-11-06 09:36:00 | [mlat][i]Pinging the server
2020-11-06 09:36:00 | [mlat][i]Stats 6185957/0
2020-11-06 09:36:20 | [mlat][i]Pinging the server
2020-11-06 09:36:20 | [mlat][i]Stats 6185957/0
2020-11-06 09:36:40 | [mlat][i]Received ADS-B time references AC:
2020-11-06 09:36:40 | [mlat][i] A14C53
2020-11-06 09:36:40 | [mlat][i] AD6EC5
2020-11-06 09:36:40 | [mlat][i]Pinging the server
2020-11-06 09:36:40 | [mlat][i]Stats 6185966/9
2020-11-06 09:37:01 | [mlat][i]Pinging the server
2020-11-06 09:37:01 | [mlat][i]Stats 6185992/26
2020-11-06 09:37:20 | [mlat][i]Pinging the server
2020-11-06 09:37:20 | [mlat][i]Stats 6185992/0
2020-11-06 09:37:30 | [mlat][i]Received ADS-B time references AC:
2020-11-06 09:37:30 | [mlat][i] A14C53
2020-11-06 09:37:40 | [mlat][i]Pinging the server
2020-11-06 09:37:41 | [mlat][i]Stats 6186026/34
2020-11-06 09:38:00 | [mlat][i]Pinging the server
2020-11-06 09:38:00 | [mlat][i]Stats 6186026/0
2020-11-06 09:38:10 | [mlat][i]Received ADS-B time references AC:
2020-11-06 09:38:10 | [mlat][i] A14C53
2020-11-06 09:38:20 | [mlat][i]Pinging the server
2020-11-06 09:38:20 | [mlat][i]Stats 6186061/35
2020-11-06 09:38:40 | [mlat][i]Pinging the server
2020-11-06 09:38:40 | [mlat][i]Stats 6186061/0
2020-11-06 09:38:50 | [mlat][i]Received ADS-B time references AC:
2020-11-06 09:38:50 | [mlat][i] A14C53
2020-11-06 09:38:50 | [mlat][i] AD6EC5
2020-11-06 09:39:00 | [mlat][i]Pinging the server
2020-11-06 09:39:00 | [mlat][i]Stats 6186096/35
2020-11-06 09:39:20 | [mlat][i]Pinging the server
2020-11-06 09:39:20 | [mlat][i]Stats 6186133/37
2020-11-06 09:39:40 | [mlat][i]Received ADS-B time references AC:
2020-11-06 09:39:40 | [mlat][i] A14C53
2020-11-06 09:39:40 | [mlat][i]Pinging the server
2020-11-06 09:39:40 | [mlat][i]Stats 6186133/0

These suggest to me that MLAT is working with the server. Or am I missing some cues? fr24feed.ini reads

receiver="avr-tcp"
fr24key="0123456789abcdef"
host="127.0.0.1:30002"
bs="no"
raw="no"
logmode="1"
logpath="/var/log/fr24feed"
mlat="yes"
mlat-without-gps="yes"
10

Lost to the mists of time, but it’s probably from a hex file format used with AVR microcontrollers.
(these formats are similar in that they’re typically a series of text records, one per line, each with a preamble then some data, as ASCII hex)

1 Like
11

It doesn’t include timestamps like beast does.
The timestamps are not absolute but relative and follow the rtl-sdr oscillator (the clock is increased for each sample by dump1090-fa).

There are some more messages in the fr24feed log sometimes about MLAT but they aren’t really clear.
I’m not 100% certain this makes a difference … one wonders if they really do MLAT without those timestamps (which would be extraordinaly imprecise).

12

There are some sort of timestamps in messages.

$ nc localhost 30003
MSG,8,1,1,A4009E,1,2020/11/06,11:57:03.456,2020/11/06,11:57:03.473,,,,,,,,,,,,0
MSG,8,1,1,A4009E,1,2020/11/06,11:57:03.470,2020/11/06,11:57:03.520,,,,,,,,,,,,0
MSG,8,1,1,A4009E,1,2020/11/06,11:57:05.150,2020/11/06,11:57:05.164,,,,,,,,,,,,0
MSG,4,1,1,A4009E,1,2020/11/06,11:57:06.430,2020/11/06,11:57:06.471,,,266,252,,,-1216,,,,,0

Does this imply that ADS-B itself doesn’t transmit source timestamp?

13

That is not AVR output.

ADS-B has never transmitted timestamps, nobody has claimed it does, where did you get that idea from?

14

As of a couple of years ago, at least, they didn’t use any of that data anyway - rtlsdr sourced data was just thrown away entirely because they were relying on system clock measurements and, unsurprisingly, that was just garbage. It may have changed since then.

15

Back to the original poster’s question. Seems to be a misunderstanding about how PiAware MLAT works.

Piaware MLAT will work with other people’s devices in your area (I think that is the usual situation). You do NOT need to have more than one device at your location. Basically you share your data with others via the Piaware server. The combined data allows MLAT calculations.

If you are in a remote location without anyone else in the vicinity, then your own network of RPi (at some minimum distance apart?) might be an option.

16

The Radarbox24 feeder is better in this respect. Its integral dump1090 is encapsuled in the rbfeeder package, and by default it remains inactive. It becomes active only when the user intentionally changes setting network_mode=true to network_mode=false. Even when it starts, it has no conflict with any other existing dump1090 as they have changed all port numbers as follows. The only problem is that the two dumps fight a duel at boot, and the winner grabs the Dongle.

The rbfeeders default setting are:

[client]
network_mode=true

[network]
mode=beast
external_port=30005
dump1090 fa/mut dump1090 rb
Beast 30005 32457
Basestation 30003 32459
Mlat Results 30104 32004

 

Although their dump1090 does not not have a GUI/Map, they have covered it by making available data in special format for their Windows Software for Map display “AirNav RadarBox ver 6.02”
IP = IP-of-PI
Port = 32088

pi@raspberrypi:~ $ nc localhost 32088
FmJyZxQFBgoGAwQGBAQOAwYJAQ==~*FmRjdBR2A30PdQYYBQUKBwcJBgUDAAcFCQEaFBofHhgbGRQbGhQaHw==~*FmRjdBR0Bg1zdgcYBQUKBwcJBgUDAAcFCQEaFBofHhgbGRQbGhQGHx4=~*FmRjdBR0Bg4DdgIYBQUKBwcJBgUDAAcFCQEaFBofHhgbGRQbGhQaHw==~*FmRjdBR0Bg0HBHcYBQUKBwcJBgUDAAcFCQEaFBofHhgbGRQbGhQGHx4=~*FmRjdBR2Ag11AXcYBQUKBwcJBgUDAAcFCQEaFBofHhgbGRQbGhQaHw==~*FmRjdBR0Bg8HB3cYBQUKBwcJBgUDAAcFCQEaFBofHhgbGRQbGhQaHw==~

 

AirNav RadarBox 6.02
AirNav RadarBox 6.02590×706 17.8 KB

 

AirNav RadarBox 6.02-b
AirNav RadarBox 6.02-b851×682 166 KB

17

If you install it without having data available or use the wrong options it uses the internal one i believe.
But whatever …

18

I am not 100% sure, but I think it does not use the internal one without user explicitly changing settings, even if no data source is available.

However I will check tonight by writing a fresh raspbian image on a spare microSD card, and installing only rbfeeder and will not make any changes to its default setting and will see what happens.

By the way I have always wondered about the strange output at rbfeeder’s port 32088. Only yesterday someone in FR24 forum said that he can see the RPi’s planes using Windows softwsre AirNav RadarBox ver 6.02 by using data from rbfeeder’s port 32088. I tried it and found this is possible even if rbfeeder’s internal dump is not working, and it gets data from dump1090-fa at port 30005. Apparently it converts the beast data it gets from dump1090-fa to their custom format and makes it available at port 32088, from where their Windows software grabs it through LAN.

The map in their Windows software resembles that of Planeplotter or Basestation map, but is more colorful (please see my last post above)

19

From my overly imaginative lump over my shoulder? I was reasoning that, given 1 light ms = 300km, brute-force MLAT will require time accuracy to be sub-ms as average amateur receiver range is <100km. (I remember one FA document says >30 km station spacing.) Yet most Raspberry Pi will perhaps not get sub-ms time drift. (PiAware image, for example, doesn’t run chronyd. On its own, the CPU only has 1,400 cycles before 1 ms elapses.) wiedehopf explained that the SDR chip (receiver board?) has its own clock. This helps timing precision, but still requires accuracy of calendar time on the OS side for MLAT to be practical using amateur nodes.

In a different application, I know of RF time-of-flight measurement/MLAT using sequence number. So I am trying to deduce whether ADS-B MLAT relies on sequencing. (Timestamp is just one possible sequence.)

20

Lost half my drink after I read that. Well played. The noggin is the source of all evil.

1 Like