Some iX3M models support a dual mode Buhlmann and VPM decompression
algorithm. Currently libdivecomputer is only capable of reporting one of
those two algorithms, but that's still better than returning an error.
The garmin FIT file parser verified that a string entry fit in the field
size, but it turns out that the check is wrong: a FIT file string field
is not necessarily NUL-terminated at all, and it's ok to have a string
that fills the entire field.
We never actually then use the string length we just checked, so with
the checks being bogus, all of this code just goes away. But let's
update the debug printout to follow these rules.
This makes parsing the example FIT file that Cédric sent us work just
fine (at least superficially, in that I don't see anything obviously
wrong with the result: I don't actually know what Cédric's dive was
supposed to look like to verify).
Reported-by: Cédric BAREYT <bareytcedric@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The getopt function is defined in the unistd.h header file. This header
file is only available on posix compatible systems. For example, on
Windows it's not available when building without mingw.
Also improved the display of setpoint information - switch mode is shown, and auto switch depth is only shown in auto mode.
All of this has been tested.
Signed-off-by: Michael Keller <github@ike.ch>
When no dives are present, the maximum value for the progress events is
set to zero, which triggers an assert. Fixed by letting the progress
events reach 100% instead.
In the latest G2 firmware v2.0, the size of the BLE packets increased to
101 bytes (with a one byte header and 100 bytes of actual payload). This
caused the download to fail, because the internal buffer was suddenly
too small for those larger packets.
These larger packets are most likely due to an update in the BLE stack
of the dive computer. Originally, the maximum BLE packet size was just
20 bytes (excluding the 4 byte L2CAP header and 3 bytes GATT header),
but BLE 4.2 increased the maximum packet size to 244 bytes (or 251 bytes
with the headers).
The USB HID code path keeps using the same fixed size packets as before.
The first byte of the BLE packets does no longer contain the size of the
payload. Since BLE supports variable sized packets, we can simply ignore
this byte and obtain the payload size from the BLE packet size.
When compiling a 32bit dll with the mingw-w64 compiler, some 64bit
integer arithmetic operations are implemented using functions from
libgcc (e.g. __udivdi3 and __umoddi3 from libgcc_s_dw2-1.dll). This
unexpected dependency is inconvenient for applications.
The run-time dependency can be avoid by linking statically.
The current hidapi version (v0.10.1) fails to build with newer autoconf
versions (v2.70) due to a duplicated AC_CONFIG_MACRO_DIR macro in the
configure.ac file. This is fixed in newer versions.
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'.
This is adding support for parsing the setpoint information in logfiles downloaded from Garmin Descent devices.
The Garmin devices do not have support for ppO2 sensor input, so they only work in 'fixed setpoint' mode for CCR dives, and dive data records do not contain actual ppO2 values.
The ppO2 values are retrofitted to the dive data based on 'setpoint change' events reported by the device. With this change CCR dives downloaded from a Garmin device are correctly classified as CCR dive, and the calculated ceiling / tissue loading graphs are accurate and match the deco stops reported by the device.
Before this change, CCR dives were classified as open circuit dives, often resulting in a massively overstated calculated ceiling.
This has been tested for logs with only automated setpoint changes - more test dives are needed to reverse engineer the log file format for manual setpoint changes, as the setpoint fields are not documented in Garmin's documentation for the FIT file format.
Signed-off-by: Michael Keller <github@ike.ch>
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).
It looks like the Scubapro G2 firmware update to v2.0 ended up
increasing the BLE packet size, which broke our downloader.
The logic is shared with the USB HID code, and the way USB HID works is
that the packet is fixed at 64 bytes, and the first byte contains the
actual payload size. So you could have up to 63 bytes of actual data
per packet, and that used to be the limit for the BLE side too.
However, now that the BLE side has bigger packets, using a 64-byte
packet buffer broke horribly, and caused the new 101-byte BLE packets
(one byte of odd data, and 100 bytes of actual payload) to be read as a
64-byte packet followed by a 37-byte one, and that just didn't work at
all.
At the same time, we cannot just increase the receive packet size,
because that makes src/usbhid.c very unhappy at least for the USE_LIBUSB
case, because using a bigger buffer for "libusb_interrupt_transfer()"
will then wait for more than one packet to arrive. Which obviously
doesn't happen when you only get a small reply, and so it all goes
south.
Fixing src/usbhid.c to only ever ask for 64 bytes at a time is probably
the right thing to do, but this instead just makes the Uwatec downloader
look at what protocol it uses instead. So if it's USB HID, we use a
64-bit buffer, and for BLE we use a maximum buffer size that then gets
filled in with whatever the actual packet size was.
Reported-by: <jmejul13@gmail.com>
Link: https://groups.google.com/d/msgid/subsurface-divelog/5d653bbd-5cad-4522-bb46-9e0319e465bbn%40googlegroups.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
The only examples I have seen so far are small incomplete files that
don't contain the dive profile, so I'm unsure if this is sufficient (and
why there are big endian files in the first place).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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).
Start looking for fit files in the normal Garmin/Activity sub directory,
but if that doesn't exist look directly in the specified directory.
Signed-off-by: Michael Andreen <michael@andreen.dev>
Merge upstream changes from Jef Driesen:
- New dive computer support:
- Ratio iX3M 2
- Sherwood Amphos Air 2.0
- Cleanups and fixes
* https://github.com/libdivecomputer/libdivecomputer:
Add support for the Ratio iX3M 2 models
Add support for the Sherwood Amphos Air 2.0
Replace switch statements with an array lookup
Add Shearwater Perdix 2 and Petrel 3
Update the Shearwater hardware IDs
Fix the clock synchronization
Remove unused time parameters
Add support for a new Aqualung i200C variant
