I experienced that after I increased -e to 15 in the few days before RC16 with the introduction of -P released. If you try -e 5 or 6, you might see “Other” positions decrease vs a high -e. It doesn’t seem like using something like -P 5 should reduce “Other” positions with high -e, but in my case it does appear to. But using -P 5 does seem to resolve more positions to ADS-B Mode S stats row. So maybe the improved data quality changes stats a bit. Small percentage so it is hard to prove without testing on two stations with a splitter.
As for “Other” aircraft, my numbers are now same or a bit lower than nearby stations. Pretty sure high -e no longer risks creating bogus aircraft stats. I never see them in TAR1090 history like we used to with the older airspy_adsb at high -e values.
I’ve tested -t 90 to 900 over the past couple days. I can no longer see any statistical difference (with -P 5 to 7 anyway). With -P 10, it looked like Other positions might have creeped up.
Yes, I had some pretty high other position counts in the few days before RC16 released. Those were the first few days where I also ran high -e all day (15). Always with -t 900 until recently realizing 900 was probably a bit excessive.
-w 5 seems perfect. Not seeing any bogus aircraft. And with current -p -e -t I’m seeing close to zero bogus altitude and abnormal other position counts.
Why is it that -t can change some stats/metrics like bogus other positions or even bogus altitudes? I’ve never understood that one. I understand why you might want to use a high-ish -t setting, but not the other potential side effects.
-t affects the timeout of the whitelist (-w), so the higher -t you set the longer time the current -w score is kept. And if there are bad decodes for an icao they are passed on if the icao has been whitelisted.
I don’t know how the decode-enginge works, perhaps it tries to do some matching agains known icaos (from previous good decodes) and do some probability matching of dubious decodes and assign them to one of the known icaos if some tests are successful?
Or perhaps just the sheer volume of decodes are so high that a high -t will lead to a bunch of messages that seem legit (they decode to the same icao, that happens to be invalid). Matching decoded icaos against a database of known icaos is probably to costly to do directly in the decoding process (by airspy_adsb) and is better done in the presentation layer (readsb/tar1090 or by FA when the data is delivered).
But I’m not 100% sure, but I’m sure @prog or @wiedehopf has a much better answer
There are enough cases of miscoded aircraft, thus you can’t check against a database as you want to display miscoded aircraft as well.
non-CRC frames are only use if the icao is on the whitelist.
Now if you keep aircraft on the whitelist longer you have higher the chances for a bogus altitude to come in via a non-crc frame.
The bogus altitudes would be coming in all the time but you wouldn’t notice them until you’re not receiving the aircraft anymore.
Because as long as the you’re receiving the aircraft, you either have the altitude from a CRC frame which means readsb/dump1090-fa won’t even consider the altitude from non-CRC frames.
Or you get a bogus altitude and in usually less than a second you get a proper altitude message from the same plane overriding the bogus altitude.
How planes get on the whitelist was explained a couple of posts above.
I’ve seen, when running high -t, that some aircrafts showing up in tar1090 (with flag, question-mark as icao, an empty callsign, with or without any height, speed, squawk or distance and with mode-S as source) can accumulate up to 15-20 messages.
These seem to be either bogus or very far away (or with a low signal). Some change into a real, existing icao but when clicking on the link to FA, the often come back as non-existant flights or some small aircraft from a different part of the world with flight information that is hours or days old and it’s obvious that it’s not likely that a bushplane from Australia is active in my area a couple of hours after it landed in Australia according to FA.
Reducing -t from say, 900 to 300 seem to mitigate many of them. Still makes me wonder how that happen, both from a technical point but also if I’m having some gremlin acting up in the signal chain that make this happen.
I’m still producing a fair share of bogus icaos (not as many as before that increased the message rate in readsb/tar1090 to never-before-seen levels) but there are still a bunch being produced and forwarded to the sites I feed. Currently I’m having a discussion with Planefinder about this since they seem to be stricter about bad icaos than the other I feed.
Well you could achieve the same with a lower -C setting. I was just pointing out that for reducing “other” positions, a lower preamble value should work, probably at little cost to other metrics. Lower -P is another option (I think), and apparently lower -t can influence other positions as well!
Yes, I’m going to adjust it a bit further, now running with 6, I’ll try 7 or 8.
That may be a solution, but I guess that there are good reasons for the current implementation as well. Perhaps a slight tweek of the points would suffice? Maybe the new filters/algorithms have some effect on the whitelisting that makes it less effective/behave slightly different if it was designed for 1.X-version?
It was just a value I picked from one of my tests I did a year or so ago. It’s interesting to see how things change when you start using more extreme settings. Often it is not beneficial, but you really don’t know until you’ve tried. Local conditions can have rather large effects on reception and may require other solutions/settings than those sites with clear 360-degree view and close to major airports.
But if you want a scenario here is one:
A site that has parts of the sky blocked by large, close up trees that will make aircrafts fade in and out when passing by.
Keeping the aircraft whitelisted for longer would lower the requirements of picking up the track when the aircraft fades in and out. It would probably be better to keep a lower value, like 180, or perhaps cut down the tree and go back to the default
To me it is annoying to have all those planes “stuck” on the map for more than 1 minute after I lost them.
If is a tree or small obstacle that blocks a real signal, the airplane will be picked back pretty fast anyway.
At least that’s what happening at the edge of my range, when the planes “toggle” on-off faster than 1 minute:
