The current processing of values that need to be scaled or offset to yield "useful" values introduces some hardships for code that's trying to use the returned values.

Example AIS 8:1:21 message

Air Temperature is documented in the standard (IMO SN.1-Circ.289 - Guidance on ASMS.pdf) as follows:

Dry bulb temperature in degrees Celsius (as per 2's complement), in 0.1 degree steps.
-60.0 to +60.0 degrees
-1,024 = data not available = default
601 - 1,023 (reserved for future use)
-1,023 to -601 (reserved for future use)

The current code always divides the 11-bit value by 10.0, which results in a floating-point number. However, if the original value was one of the "special" values, such as -1,024, it will also be converted. So, the client code, when checking to see if the value is available, has to do a floating-point compare to -102.4 (actually "-102.4000015258789" in my testing).

This is not good.

An improvement would be the following:

• Have the bit-extraction routines, like in ais8.cpp, only extract signed and unsigned integers.
• Move all scaling and offsetting code to the ais_py.cpp routines.
• Have the ais_py.cpp routines check for the N/A values, and set the field to Py_None if so.