The Cressi Leonardo does store an indicator for the ascent rate (e.g.
the number of arrows) in the upper two bits. This results in 4 possible
values, ranging from 0 to 3, with the following interpretation:
0.0 - 3.9 m/min No signal
4.0 - 7.9 m/min 1 Arrow
8.0 - 11.9 m/min 2 Arrows
12.0+ m/min 3 Arrows (with STOP icon)
Reported-By: Nick Shore <support@mac-dive.com>
When using up to 14 bits for the depth, the resulting values are too
large in some cases. Most likely the upper bits are used to store
something else. Even with only 11 bits, the resulting depth range
(0-204.7m) should still be more than sufficient.
Currently, each backend has it's own function to verify whether the
object vtable pointer is the expected one. All these functions can be
removed in favor of a single isintance function in the base class,
which takes the expected vtable pointer as a parameter.
Functions which are called through the vtable, don't need to verify the
vtable pointer, and those checks are removed.
The term "backend" can be confusing because it can refer to both the
virtual function table and the device/parser backends. The use of the
term "vtable" avoids this.
This is only a preliminary version. There is certainly some room for
improvement, but the basic functionality is already in place. That
should be sufficient for daily use, and possibles issues can always be
fixed when discovered.
