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)
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.
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.
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.
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!
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!
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.
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! 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.
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.