Skip to content
This repository has been archived by the owner on Sep 14, 2019. It is now read-only.

Don't emit non-ICAO addresses in SBS output #9

Closed
mutability opened this issue Feb 5, 2015 · 7 comments
Closed

Don't emit non-ICAO addresses in SBS output #9

mutability opened this issue Feb 5, 2015 · 7 comments
Labels

Comments

@mutability
Copy link
Owner

http://discussions.flightaware.com/post156117.html#p156117

Shouldn't emit non-ICAO addresses in SBS format output.

@mutability mutability added the bug label Feb 5, 2015
@mutability
Copy link
Owner Author

Also probably need to do the only-after-2-messages thing

@saiarcot895
Copy link

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.

@mutability
Copy link
Owner Author

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.

@saiarcot895
Copy link

Can't you just check to see if mm->addr >= 0x1000000 in the output method?

@mutability
Copy link
Owner Author

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.
Some combinations of demodulator settings produce a relatively large number of "correct CRC, garbage contents" messages - this is just a numbers game, if you're looking at 300M candidates an hour and only maybe 1M are valid, then 24 bits of CRC is not enough.

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.

@mutability
Copy link
Owner Author

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.

@saiarcot895
Copy link

Ah, ok.

toofishes pushed a commit to toofishes/dump1090 that referenced this issue Mar 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants