-
Notifications
You must be signed in to change notification settings - Fork 137
Don't emit non-ICAO addresses in SBS output #9
Comments
Also probably need to do the only-after-2-messages thing |
This also applies to the TCP raw output, as I'm seeing the 7-digit ICAO codes there as well. Edit: Never mind; I meant the SBS output rather than the very-raw output. |
I'm almost tempted to leave SBS emitting non-ICAO addresses (at least as an option) as it looks like consumers of that data are handling it OK. The real fix is to suppress the bad messages that are causing them to be generated in the first place - which is a little more involved than just checking a flag unfortunately. |
Can't you just check to see if |
Well, test for the MODES_NON_ICAO_ADDRESS bit, yes. That's what I mean by "checking a flag". But the problem is more involved: this is actually just a more visible manifestation of an older problem. So some messages with garbage data get through. Previously, these would appear as garbage 24-bit ICAO addresses. Now that we flag some messages as being non-ICAO, some subset of the garbage messages will appear as non-ICAO, depending on if they happen to look like e.g. a TIS-B message. So suppressing non-ICAO addresses doesn't fix the real problem, it just hides the most visible manifestation of it. |
And the right way to fix this is most probably to apply the filter that dump1090 applies elsewhere to all emitted messages (perhaps "unless --net-verbatim is in effect"). The filter is simply that you don't forward messages for a particular address until you've seen 2 messages from the same address - this is very effective at removing the garbage. However, it requires that we hook into the aircraft state tracking code. So some rearrangement of the output & tracking code is needed. |
Ah, ok. |
Two bugs fixed
http://discussions.flightaware.com/post156117.html#p156117
Shouldn't emit non-ICAO addresses in SBS format output.
The text was updated successfully, but these errors were encountered: