Operational Status Messages: inconsistent checks

[mrksngl]

Overall

The checks on Operational Status Messages are inconsistent.
All messages have different subfields that may contain a "class" of data. The handling of those classes however, is inconsistent.

On V0

In OperationalStatusV0Msg, the enroute_capabilities are extracted which has two bits defining a "class".

Now that class is actually checked, but in the getters (keep that in mind!).

So for example we have

public boolean hasOperationalCDTI() {
	// status of 4th bit when first two bits zero
	return (enroute_capabilities & 0xd0) == 16;
}

So the answer we get from this function is "is the code 00 AND cdti set"?

But: if the code is NOT 00, we can actually give no meaningful answer to "does this aircraft have CDTI?".
Yet the library just guesses "no".

On V1+

In SurfaceOperationalStatusV1Msg, we have a "capability class" and an "operational mode code". Both form subfields with their classes.
The capability class is checked in the constructor: if it is unknown, the constructor throws because it does not know how to handle the message. Fair enough.
However, the class of the operational mode code is never checked.

Now we have

public boolean hasTCASResolutionAdvisory() {
	return (operational_mode_code & 0x2000) != 0;
}

which is correct if and only if the operational mode code class is 00.

Same is true for the Airborne counterpart messages.

Assessment

So overall we have 3 different ways of dealing with classes:

• check on ctor
• check on accessor (with limited validity)
• no check at all