MLAT questions re: approaching planes

FlightAware ADS-B Flight Tracking
1

Hi,
This question relates to MLAT aircraft approaching the local airport. As the planes typically get to about 1 runway length (approx 2 miles) the MLAT positioning (Lat/Long display) stops updating. (ADSB goes to the ground…I have a station 1 mile away and it picks up signals from ground level fine). However, the altitude continues to show decent until it gets to GRD. Why does the horizontal positioning stop updating?

The second part of this question is: Is the fix to add yet more stations (only 11 houses close to this airport, so options for siting a FF/Pi close to the airport is limited)? More can be added, but due to geography surrounding the airport, I have only located two other spots that will pick up ADSB signals at ground level.

Anybody have any thoughts on this situation and what might be done to improve things?
thanks

2

yep - as the aircraft comes lower less other stations get the signal and that’s why mlat stops working.
more stations from different angles and ground-view to airport/runwaycould solve this …

3

Yes, that seems the logical step to go. We definitely need to get three more stations established to see ‘to the ground’ to even think of getting ground-level mlat working. That is going to be quite difficult, but we’ll work towards that.

I am curious why the altitude continues to count down to GRD at the same time that the location stops changing. I added a couple of local sites (but can’t see ground level) and that seemed to make no difference at all…I would have thought that it would get a 'little bit better…but no!

Also, one other question about MLAT calculations. How long does it take the servers to get to a ‘first fix’ state. I notice that departures can take a while longer and get further from the runway than when arrivals usually stop updating. Is this a normal server-related condition…I expect it is.

thanks for the response…

4

The Mode S broadcasts include the altitude so you can get altitude from a single receiver; only the lateral position requires multilateration.

First fix can happen on the order of 10 seconds. Departure vs arrival differences may be due to receiver locations around the field if the traffic flow direction is consistent. Also for error reduction we require more receivers to start an MLAT track than to maintain one.

5

Ahhh…excellent explanation. That answers my questions. So in order to have a timely MLAT upon wheels up, we really need to get MLAT coverage right to the ground then. Due to the limited number of spots where a Pi station can be set up close to the airport, and the fact that a couple of sites higher than the tarmac will be located quite some distance away…I can see that some high gain antennas (like DPD Productions) will likely have to be employed.

Thanks so much for the response mduell!

6

this is what i did a while ago to get better reception to a runway despite of having no direct view. worked quite well: http://www.amateur-radio-antenna.com/ism-aeronautical-antenna/secondary-radar-1090/index.php

ads-b_site_l
ads-b_site_l1925×500 618 KB

7

Hi Tom,
Thanks for that info & links. I just measured one spot I had identified from my vehicular setup as able to pick up craft on the ground. The spot is 10.0 miles from the middle of the airfield. It is 200’ higher than the airport, so across most of the airfield I could track aircraft with ADSB no problem. I had a couple of issues with building shading, but not too serious. I am using one of the FA antennas for my mobile setup.One of those high gain Yagi’s might make things close to 100% ground-level reception.

If I can get someone in one of those 11 dwellings close to the airport to host for me, then I just need to find a fourth site. Will be difficult for sure as I’ll have to go knocking on business’ doors…but who knows? There may be an enthusiast in one of those buildings…

I’m looking at that FLU-SR/Y13 in your link. Is that the antenna that I see in the second picture? I guess you’re having good luck with it? I have been using POE installs now so that the cable lead is less than 18". I think a high gain yagi might just be the ticket fo that site. Did you purchase yours from the site in the link (German?) or do they have a North American distributor.

Thanks for the info

8

Hi Tom,
Oh, one other question. The three antennas in your attic…are separately feeding dedicated hardware from different companies (FlightAware / FlightRadar24 / Plane Finder) or are you feeding your own Pi’s for various projects?

9

hi blacktop,

yes it’s the cheaper one for about 140$ that i have. and yes i was able to overcome a small hill that is about 100 feet higher than the one my house sits on top. so - without direct line of sight i was able to pick up signals from edmo (4 miles away) as soon as they pulled the aircraft out of the hangar :slight_smile:

i bought it at their shop over here in germany - and the antenna is a really good one, other good ads-b stuff you find here https://shop.jetvision.de but is again german.

the pictures were taken 2 years ago when i did all my testing (antennas, dongles, radarcape, airspy etc.) in my attic. today i have just one feed raspi2 with nooelec dongle, uputronics filter/amp and jetvision omnidirectional antenna (mounted on the roof) Post your PiAware setup - #158 by TomMuc

cheers
tom

adsb_mess
adsb_mess800×533 288 KB

antenna_04
antenna_04800×533 128 KB

3_adsb_l
3_adsb_l800×533 379 KB

10

but aren’t there mlat flights where also the altitude was just computed? i wonder because in aircraft.json i find two different behaviors - sometimes in key ‘mlat’ i can see the sub-key ‘altitude’ and sometimes not while sub-keys ‘lat’ ‘lon’ etc are always present???

11

There is insufficient precision and very unfavorable geometry for MLAT of altitudes.

Altitudes are directly provided by most transponders, though altitude reporting can be disabled and some old transponders do not have altitude reporting capability.

12

Mode-S MLAT only works while an ADS-B beacon flight is also being received, so a highly directional antenna might work against itself, if it doesn’t hear the beacons well.

13

Mode-S MLAT only works while an ADS-B beacon flight is also being received, so a highly directional antenna might work against itself, if it doesn’t hear the beacons well.

there is no ads-b antenna with such a tight beam that someone would get that scenario in reality. even the yagi above i used is very very wide reception-wise.

There is insufficient precision and very unfavorable geometry for MLAT of altitudes.
Altitudes are directly provided by most transponders, though altitude reporting can be disabled and some old transponders do not have altitude reporting capability.

thats what we see with gps often too. but i wonder what else could be the reason sometimes the aircraft.json mlat-subarray has the key altitude and sometimes not?

p.s. and this geometry and precision thing was exactly the reason for my question above. because then i’d know that these altitude data would be veeery swag :slight_smile:

14

The altitude is omitted when it is missing or not valid for a number of reasons.

No decent attempt can be made to MLAT the altitude … unless +/- 10 miles is good enough. :artificial_satellite:

15

The altitude is omitted when it is missing or not valid for a number of reasons.

are you just guessing - or do you have information from flightaware staff? in aircraft.json mlat aircrafts WITH altitude sometimes in mlat-array subkey there is an KEY altitude and sometimes not - have not seen a VALUE there up to now.

example with:
{"hex":"~2bbd80","type":"tisb_other","lat":51.357499,"lon":10.036774,"nucp":0,"seen_pos":22.8,"altitude":43025,"vert_rate":0,"track":14,"speed":519,"mlat":["lat","lon","altitude","track","speed","vert_rate"],"tisb":[],"messages":1170,"seen":22.8,"rssi":-49.5},

example without:
{"hex":"3c4a28","squawk":"2554","flight":"BER8680 ","lat":48.327414,"lon":10.582075,"nucp":0,"seen_pos":8.8,"altitude":25000,"vert_rate":0,"track":167,"speed":326,"mlat":["lat","lon","track","speed","vert_rate"],"tisb":[],"messages":24716,"seen":0.0,"rssi":-2.3},

No decent attempt can be made to MLAT the altitude … unless +/- 10 miles is good enough. :artificial_satellite:

+/- 10 miles precision in computed altitude is simply wrong in my opinion as the number of receiving sites increases with every feet - so just measuring which station in different range can receive a signal gives a much more precise altitude than +/- 10 miles because the earth is a ball and not flat and this frequency isn’t shortwave like radio amateurs use.

p.s. when above calculation is additionally assisted with runtime-data from signals and flightawares databases for flightlevels that are used for measured heading i’d say they are able to compute quite useful altitude numbers …

p.p.s. but by no means this is what i think that the derived altitude is from. just to explain that in my opinion +/- 10 miles is not the precision they could achieve if they would want to calculate mlat altitude they would be by far more precise. my simple question was and still is - ‘why is sometimes a sub-key (just the key - no value) in mlat sub-array of aircraft.json’ ?

16

MLAT, like GPS, suffer from GDOP/VDOP/HDOP. Dilution of precision (navigation) - Wikipedia

Better timing and site positioning accuracy improves the results.

Look at the clock timing differences between the radarcape and std dongles(BEAST) ~80 times better.
piaware.log.4:Jul 31 21:58:16 localhost piaware[562]: mlat-client(27552): Input format changed to BEAST, 12MHz clock
piaware.log.4:Jul 31 21:59:20 localhost piaware[562]: mlat-client(27552): Input format changed to RADARCAPE, 1000MHz clock
piaware.log.4:Aug 1 03:12:14 localhost piaware[562]: mlat-client(18008): Input format changed to BEAST, 12MHz clock
piaware.log.4:Aug 1 03:12:15 localhost piaware[562]: mlat-client(18008): Input format changed to RADARCAPE, 1000MHz clock

When we get Galileo, hopefully in around 2020, everyone should get better GPS accuracy.

If someone came out with a cheap dongle with a better internal clock, then ADS-B MLAT accuracy should benefit. Given the U.S. mandate for ADS-B of 2020, it may not help a great deal.

1 Like
17

The dump1090 code is the canonical place to look if you want exact details of when altitudes are included in the json output.

note that dump1090 will be processing both direct signals and mlat results in parallel so the altitude can come from either.

The altitude produced by the solver when there is no altitude input from the transponder is very very sensitive to small errors which is why it’s so unreliable in that case. There are usually a couple of stable solutions, one of which is wildly wrong. An analogy is bending a springy sheet of metal by squeezing in from the sides - there are two shapes it can take depending on which way the initial bend happens. I’m actually considering dropping the altitude output entirely in that case since it can be so wrong.

1 Like
18

FWIW the Radarcape is actually about 11x better (not 80x) than a dongle in practice - Radarcapes get around 45ns precision, dongles are around 500ns.

1 Like
19

The dump1090 code is the canonical place to look if you want exact details of when altitudes are included in the json output

had a brain freeze with this - found the aircraft.json explanation in dump1090 sources - as some fields (including mlat) there were not mentionend i then went to mlat-server sources to look for. but of course you are right aircraft.json is produced by dump and not mlat-server. so i go back into the dump code. but to be honest it is not trivial reading and (at least partly) understand the code for me and my skills as there happens a lot of ‘magic’ - one thing is trying to learn what the code does and the second is to understand the idea behind. i’ll try my best :blush:

note that dump1090 will be processing both direct signals and mlat results in parallel so the altitude can come from either.

aaah - finally got it!

The altitude produced by the solver when there is no altitude input from the transponder is very very sensitive to small errors which is why it’s so unreliable in that case. There are usually a couple of stable solutions, one of which is wildly wrong. An analogy is bending a springy sheet of metal by squeezing in from the sides - there are two shapes it can take depending on which way the initial bend happens. I’m actually considering dropping the altitude output entirely in that case since it can be so wrong.

if i understand correctly - this means my first guessing that there are two different flavors of mlat-altitude (and one is really just computed and there was no altitude in received aircraft data-set) was right? if so i further guess that these results are the ones where the ‘altitude’ sub-key is found in aircraft-key ‘mlat’ (“mlat”:[“lat”,“lon”,“altitude”,“track”,“speed”,“vert_rate”]). ok - so the math behind can plop to top or to bottom and in these cases the error might be quite large? anyways i’m very happy with the precision the mlat results have at the moment - and they would improve a lot in my neighborhood if there finally pop up more sites!

what i have learned is that the radarcape is really a great receiver in many ways - but for mlat despite of it’s much better timing it will always suffer from very few sites as the thing costs between 600-2000$. what i’m dreaming of (and already asked guenther from jetvision for) would be a beast receiver with built-in ublox gps in a small case for around 100$ that could then connect to raspberrypi running dump1090-mutability …

obj thanx for enlightening!

20

The mlat results currently always include an altitude. In the case where the transponder is sending altitudes the solver includes the transponder altitude as another input to the solver (with a small error estimate); that strongly pulls the solution close to the transponder altitude so the calculated mlat altitude will generally be very close to the transponder altitude. In the case where there’s no transponder altitude, that input is not present so the altitude in the result is much less reliable.

The “mlat” key in the json tells you which fields have data that came from a mlat result.

1 Like