What is the Maximum Range I can Get?

Yeah, I’ll probably need to see the raw data.

That particular case involves mlat though. I think what happened here is:

The filter doesn’t count mlat positions as a trigger for ignoring altitudes from DF0/4/16/20 (maybe it should) so in this case what’s probably happened is that you saw a single stray damaged message that attributed the altitude of something nearby @ 5000ft to the distant aircraft shortly after you stopped receiving mlat positions. The “27 consecutive packets” with an increasing “seen” value is actually just reporting the effects of the same single packet with nothing to supersede it (“seen” is how old the reported data is)

Do you see any non-mlat cases?

Not yet. I’ve now added a filter to exclude mlat data. I don’t see much traffic overnight, so I’ll leave it running and see if I capture anything tomorrow morning.

Thanks lignumaqua.

This is what scares me about “messing” with the code. There is always more than one way to make a change. Sadly, if one way “breaks” it, that will be the one I chose.

Phill

Took a while to find a candidate, I only see 20% or less of feeds as non-MLAT, but just got a hit.


altitude: 8000
category: "A0"
flight: "UAL1063 "
hex: "a0ad24"
lat: 27.470718
lon: -96.713527
messages: 9638
nucp: 7
rssi: -24.9
seen: 1.1
seen_pos: 25.8
speed: 403
squawk: "2640"
track: 204
vert_rate: 0


Timestamp: 1455037244.3 (Tue, 09 Feb 2016 17:00:44 GMT)

Followed by many repeats of the same message until seen time reached 19.2 seconds.

This flight was actually at 40,000 ft at the time. Location is correct:


How would I go about finding the original message for you. Turn on ‘All logs’ and then grep it out of the logs? Or is there a better way?

OK, so in that case it is probably the same damage scenario. The filter only applies if dump1090 heard a ADS-B position in the last 15 seconds. In this case you haven’t heard a position for 25 seconds… Picking a universal value for this timeout is going to be tricky, since it’s a tradeoff between throwing away good data and not accepting bad data.

Maybe a simple fix is to ignore anything with seen_pos > 5 when updating the range rings.

Thanks, I’ll try that. That could work for mlat as well.

Unfortunately, we still get erroneous altitudes in MLAT data, even limiting to 5 seconds or less seen_pos.

This flight today was actually at 43,000 ft at this moment. Position etc is basically correct but altitude is way off.

flightaware.com/live/flight/N888 … X/tracklog


altitude: 3550
flight: "N888XY "
hex: "ac3db1"
lat: 31.950989
lon: -99.66752
messages: 16545
mlat: "lat", "lon", "track", "speed", "vert_rate"] (5)
nucp: 0
rssi: -40.1
seen: 2.6
seen_pos: 3.1
speed: 451
squawk: "6414"
track: 270
vert_rate: 0


Wed, 10 Feb 2016 20:42:42 GMT

I’ll turn MLAT off again and see if ADS-B only data is good with the same limitation on 5 seconds.

Can we edit out the 10k range ring in the associating file? Mine seems very inaccurate also. how would this be done?

Yes, just edit the config.js file and remove/add the rings that you want. I also strongly suggest setting the UseMlatDataForRange option to false. I will hopefully release a more accurate range system soon that filters out these bogus readings.


// Set Altitudes and Colors for Range Rings
// RangeAltitude is an array of altitudes in feet
// Use 99999 for range at any altitude
// RangeColor is a corresponding array containing the color values of the rings
RangeAltitude  = new Array(99999,30000);
RangeColor     = new Array('#008000','#000080');

// Allow use of MLAT data for the range poly
UseMlatDataForRange = false;


For now I think you do want to avoid using mlat data for range vs. altitude plots. The positions should be OK-ish, but the altitudes can be wrong for a couple of reasons.

When mlat is seeing transponder altitudes, generally the mlat position altitude will be OK as (a) it needs to see the same message from multiple receivers before accepting the altitude, so address corruption is much less likely and (b) the solver is strongly biased to produce a position that is close to the reported altitude.

However if there is no transponder altitude available then mlat can compute altitudes that are wildly wrong, because the receivers are approximately all on the same geometric plane as the aircraft so the solution is not very stable on the altitude axis.

And current dump1090 continues to accept locally-received altitudes even if a mlat position is available (I might change this, but I’m not 100% convinced it is the right thing to do) so they’s still vulnerable to address corruption.

All makes perfect sense, thanks for taking the time to explain. It’s really a matter of perspective, we know that MLAT can have errors of a few miles at long ranges. That doesn’t worry us when it comes to position estimates, but a few miles in altitude estimation is significant! :laughing:

So far so good with ADS-B only data and seen_pos <5 …

obj - this is a really interesting set of data. I received two different messages of this type from this flight, both with very low seen_pos and, as far as I can tell, everything in them is correct!


altitude: 9750
hex: "ac85c6"
lat: 32.970669
lon: -96.769316
messages: 5
nucp: 5
rssi: -23.2
seen: 0.3
seen_pos: 0.3


Fri, 12 Feb 2016 13:35:53 GMT

flightaware.com/live/flight/N906 … L/tracklog

This was a Delta flight, aircraft N906DE, from DFW to ATL. Data was captured as it took off from DFW. At 175 miles from me I shouldn’t really be able to see it at this low altitude. What do you think? Freak reception? I imagine you can get occasional reflections of the signal off the ground or buildings.

In Amateur radio they often bounce signals off aircraft to increase range. It doesn’t last long but maybe it is happening here.
Maybe the signal bounce off a higher aircraft and back to your receiver.

There is also “Tropo” Tropospheric ducting. It can happen at 1Ghz frequencies.
google it or see en.wikipedia.org/wiki/Tropospheric_propagation for more info.

Yes, thanks, that’s very interesting. If that’s what happening here (and it could well be) then this would be a legitimate reception. It shows that trying to get a ‘range’ polygon could be both fascinating and futile at the same time! :laughing: What does ‘range’ mean in these circumstances?

The “HeatMap” may be more helpful in working out your actual range. Maybe a height related one would be better.
It would show anomalies better, I expect.

Yes, I agree, the only issue would be that limiting it to 1) ADS-B only, non-MLAT, data and 2) Only points with small seen_pos will mean that it will take a very long time to build up into something meaningful, particularly in the US where we get relatively little ADS-B traffic.

Today I received data from an aircraft over Poland about 450 nm away and when I looked it up in FA and FR24 this aircraft really has been there. Made a long spike in my rangeline, otherwise I wouldn’t have noticed it. I had that before, but it happens only on rare occasions.

The heatmap gives more information about areas with reception, but the actual implementation (or how Google is rendering it) is not optimal, if the heatmap builds up over a long period (10+ hours). Every heatmap-cell has a value and after some hours some cells have a value of more than 200 (I wrote a DumpHeatmap-function to see the values) and areas with less, but also regular traffic have maybe 10 and are barely visible on the heatmap. I played around with the heatmap-code (f.e. with a cap for the cell-value), but without much improvement.

Yes, I had already set the cap values to what seemed to be optimal. I had considered using log values as the weighting. That would tend to flatten out these extremes, however it would be slower to build up. I’ll take another look at that. As always, compromise is needed. :smiley:

Realistically a heatmap only shows about ten or so distinguishable colors. I know there are really a lot more, but they blur together. The current implementation dynamically assigns the colors depending on total accumulated traffic all the time. So, a route that is heavily traversed at one time, and shows red, may eventually fade away if the wind changes and traffic patterns shift. We aren’t mapping a fixed situation, so any long term mapping will always tend to flatten out.

I hope you did not misunderstand me, I did not want to criticize your code, I just wanted to start a discussing about the general problem with heatmaps. I live in an are were I see lots of traffic from northwest (London, Amsterdam, Frankfurt) to southeast (Vienna, Istanbul, Dubai) on several - up to 10 - tracks in parallel. That gives me a huge red strike across the map and most other traffic is just pale green or yellow. I tried several things, but nothing really worked much better than what you implemented.

One approach I tried a while back that worked OK-ish was to use the position rate per aircraft as a proxy for signal strength.

e.g. you count position messages into geographic cells and once every 30 seconds for each cell you take the number of position messages in the 30 second interval divided by the number of aircraft that were seen in that cell, and add that to your heatmap.

Theoretically each aircraft (in the air) should be transmitting position messages at a constant rate (2/second), so this gives you an estimate of what fraction of position messages you are hearing in a particular area.