The hidapi-hidraw variant of the hidapi library needs access to the
specific /dev/hidraw* device nodes. The existing udev rules for the USB
devices don't apply to the hidraw device nodes.
On Linux, the hidapi library is usually available in two variants:
hidapi-libusb and hidapi-hidraw. By default, the autotools build system
won't be able to detect those variants (due to the difference in the
name) and will automatically fallback to the libusb implementation
instead.
If for some reason the hidapi library should be used, the preferred
hidapi variant can now be specified during configuation with a
parameter:
./configure --with-hidapi=hidapi-libusb|hidapi-hidraw
The default value for the parameter remains 'hidapi'.
The bookmark value is a bitfield indicating the type of bookmark:
1 - Pressed the bookmark button during a dive
2 - Reset the stopwatch
4 - Unknown
8 - Unknown
The hidapi based implementation returns as soon as the first packet is
received, while the libusb based implementation tries to read the
requested number of bytes. That fails with a timeout if the requested
number of bytes is larger than the size of a single packet and no
further packets are received.
Avoid this problem by limiting the size to the maximum packet size.
At the moment, trying to download an old dive for which the profile data
has already been overwritten with newer data fails. This used to work
fine, but around hwOS firmware v3.10, the behaviour described in commit
76187c550a806fe422920eb8795fa687244513f1 changed.
When downloading the compact/full headers, the firmware always sends the
headers without inspecting their content. Next, libdivecomputer uses the
length field in these headers to determine how many bytes to expect when
downloading the dive. However, when downloading the entire dive, the
hwOS firmware now checks whether the profile data of the dive is still
available. If that's no longer the case, the firmware sends a modified
dive header (with the begin/end pointer fields reset to zero, and the
length field reduced to 8 bytes), along with an empty dive profile.
Since libdivecomputer expects to receive the full profile as indicated
in the original header, the download fails with a timeout.
To workaround this problem, download the dive data in two steps. First,
download the 256 byte header and check whether it has been modified. If
that's the case, reduce the length to that of the 5 byte empty profile.
The header check is also updated to exclude the modified fields. For the
progress events, just pretend the full profile has been downloaded.
Not only the two byte end-of-profile marker 0xFDFD is a valid empty dive
profile, but also a profile with the length field present and set to 8
bytes. In that case the actual length will be just 5 bytes.
When downloading the compact headers (which is the default for recent
hwOS firmware), it's not possible to compare the entire dive header, but
we can at least the check the fields that are available.
Also return an error if the verification fails.
The Aqualung i770R appears to have 6M instead of 4M (high) memory.
Confirmed by trying to read past the 6M limit, which fails with a NAK
response. This amount also matches with the capacity stated in the
manual (6553 hours of profile data at a 60 second sample rate).
The memcpy and related functions expects a valid pointer, even if the
size is zero. Most libc implementations will handle a NULL pointer just
fine, but that's not guaranteed.
Simply skip the call when there is nothing to copy.
The maximum depth value is stored in the dive header. There is no need
to parse the profile data to obtain it. This also avoids returning a
zero depth when the profile data is no longer available.
A few other fields (e.g. average depth, atmospheric pressure and
temperature) are also present in the dive header.
For dive computers where the reference time (epoch) of the device is
unknown, libdivecomputer uses the current time of the device (devtime)
and the host system (systime) to synchronize both clocks.
Currently, both timestamps are passed directly to the constructor of the
parser. With the new public function, the application can adjust the
timestamps afterwards.
Some dive computers store the depth as an absolute pressure value (in
bar). To convert to a depth value (in meters), the atmospheric pressure
and water density are required. For dive computers that do not have
those values available, libdivecomputer uses a default value. With the
new public api functions, applications can adjust those default values.
Some dive computers already provided a backend specific calibration
function. Those functions are now deprecated. They are kept around to
maintain backwards compatibility for now, but they will be removed in
the next version.
Report the decompression algorithm (Buhlmann, VPM, RGBM or DCIEM), and
if available also the parameters. For now only the conservatism setting
is supported, and for the Buhlmann algorithm also the Gradient Factors
(GF).
For dives with a timestamp that is larger than the current device time
(e.g. in the future), the clock synchronization produces incorrect
values. In that case, the time difference suddenly becomes negative,
which corresponds to a large positive value as an unsigned integer.
Under normal circumstances, this scenario can't happen. But sometimes
actions such as battery replacements or firmware upgrades can cause the
internal clock to reset.
The Reefnet devices shouldn't need this fix, because their internal
clock can't be changed, but it doesn't hurt either.
Since the clock synchronization has been removed (see commit
a1962558412b8c89a79656992c8e7f4d001065c2 for the details), those
parameters serve no purpose anymore.
The command to change the OSTC settings has a variable length payload (1
to 4 bytes). Therefore, the expected number of bytes is only know after
evaluating the first option index byte. Due to the limited UART buffer
in the OSTC, sending the remainder of the packet immediately after the
first byte, can cause the OSTC to get out of sync.
Introduce a small delay between sending the option index and the
remaining parameters to avoid this problem.
The latest firmware does store some additional information for each
tank. Right now it's not really used for anything yet, but it's
available for future use.
In the older Predator-like data format, the 4th opening/closing record
is the last one. To avoid accidental use of the higher ones, leave them
undefined.
During the download, the model number is obtained from the hardware type
because the model number isn't available before downloading the first
dive. Since the list with available hardware types is incomplete, the
correct model number is not always available. However, during parsing
the correct model number is available in the final block.
