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
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.
Also update and fix the hardware IDs based on the latest information
from Shearwater.
Two of the hardware IDs that we supported before are not listed in the
current docs. In an abundance of caution I'll leave them in the code.
No harm done if they don't exist in real life.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There appear to be newer models in the wild with a different model
number, but labeled as i200C.
To avoid confusion, this calls the new model i200Cv2.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Merge Jef's upstream updates:
- Add support for Seac Screen and Action
- Add support for Cressi Michelangelo
- misc small fixes
* https://github.com/libdivecomputer/libdivecomputer:
Add support for the Seac Screen and Action
Add an address parameter to the memory dump helper function
Ignore invalid gas mixes
Add support for the Cressi Michelangelo
Move the C_ARRAY_SIZE macro to a common place
Fix the timezone offset in the xml output
Emit a devinfo event when downloading a memory dump
Read the info and more info data during startup
Use helper functions to decode multibyte values
Fix changing the OSTC settings
This should always be tested for - the only other user of the generic
helper currently didn't test for it, either.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The generic function already handles all the cases (treating gasmix and
tank count as being the same and responding UNSUPPORTED to the same set
of types). The only thing missing is the check of the value parameter
and the extraction of the cache pointer from the context.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The code used sub_sport to figure out if this was a dive in the first
place, but then never reported back the specific dive mode, leading to
all dives being interpreted as open circuit.
Reported-By: Anton van Rosmalen
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When downloading heart rate data from a chest strap the Descent MK2i
uses a more compact format, like C4ND0302.fit. If any such dives have
been downloaded then newer dives in long format won't be detected and
requires downloading all dives and picking the right ones.
Instead parse this short format and ensure that these dives end up in
the correct order.
Format information found here:
https://gist.github.com/waywardone/fa8cb01462790aa8a26fab97477b80e1
Signed-off-by: Michael Andreen <michael@andreen.dev>
In the most recent merge deco model (byte 79) was swapped for divemode
(byte 82). This caused all OC dives to be classified as the older
algorithm without gradient factors.
Signed-off-by: Michael Andreen <michael@andreen.dev>
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.
Merge Jef's upstream into the Subsurface branch:
- support for new dive computers: Mares Pick Pro+, Deep Six Excursion,
Crest CR-4, Genesis Centauri and Tusa TC1.
- support freedive mode on Mares Smart Air
- work with Oceanic dive computers regardless of whether they need the
BLE handshake or not
- OSTC updates: support bigger BLE packets in newer versions, fix
setpoint in SCR mode
- Shearwater updates: full dive mode parsing, correct timezone handling
on Teric, support up to four transmitters on newer log versions.
* git://github.com/libdivecomputer/libdivecomputer: (26 commits)
Read the extra tank information
Add support for transmitter T3 and T4
Limit the number of records for the Predator
Report the timezone offset for the Teric
Use the correct model number from the final block
Use the dive mode stored in the header
Report the correct dive mode for SCR dives
Increase the size of the BLE packet cache
Add support for the Genesis Centauri and Tusa TC1
Read the hardware and software version
Report the initial setpoint in SCR mode
Add the divemode to the layout descriptor
Re-order the fields in the layout descriptor
Show the correct help message for the scan command
Add support for the Crest CR-4
Add udev rule for the Suunto EON Steel Black
Ignore unsupported BLE handshake
Detect NAK response packets
Remove the initial gas switch
Restore the original standard gravity factor
...
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.
