This way BLE dive computers that are otherwise conditional on USBHID will be
built on platforms that support them but don't have USBHID (like iOS).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Most of the new warnings due to compiler flags are just unnecessary
noise, but let's clean up at least the obvious and unquestionably valid
ones.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sync up with upstream cersion 0.6.0.
Annoying merge, mainly because a lof of the changes Jef had done are
actually changes that came from our Subsurface branch, but in a
different form, because Jef doesn't actually take patches directly from
us.
Why? I don't know.
* tag 'v0.6.0' of git://git.libdivecomputer.org/libdivecomputer:
Release version 0.6.0
Fix some potential buffer overflows
Fix some casts with constant pointers
Enable some useful compiler warnings by default
Generate html documentation from the manpages
Fix the decoding of the ndl/deco information
Decode the firmware version for the iDive series
Add support for the Suunto Eon Core
Locate the most recent dive
Add EON Steel time sync capability
Improve the progress events
Detect the model number using the hardware type
Shearwater: add support for remaining gas time
Shearwater: extract tank sensor data for log version 7
Shearwater: extract log version from header
Because some of those compiler warnings are GCC specific, they should
only be enabled if the compiler actually supports them. This is take
care of with some macros from the autoconf-archive.
To avoid breaking the build on systems that don't have those macros
installed (e.g. Mac OS X), they are included in the project.
Nick Shore reports that it seems to act exactly like an EON Steel, just
with a different USB device ID.
Acting like the EON Steel is not a surprise: it does seem to be the same
dive computer, just in a smaller and lighter package (same screen size,
but more compact body and without the stainless steel to make it less
than half the weight). Looks like the battery is smaller, but the
electronics are likely the same.
We probably really should have some way to add new device ID's without
having to add whole new model numbers etc. It's not the first time this
happens (see the Scubapro Aladin Square vs the G2), and it's likely not
the last time.
Reported-by: Nick Shore <support@mac-dive.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
With the new APOS4 firmware, both the tts and the duration of the first
deco stop are recorded while in deco. But compared with the older
firmware, the tts field has moved to a slightly different offset. And
contrary to the new documentation, it seems that the value for invalid
or infinite has also changed from 0xFFFF to 0x7FFF,
Note that for dives recorded with an older firmware version, the
duration of the first deco stop isn't available, and libdivecomputer
reports the tts instead. This is the same behaviour as before.
Reported-by: Janice McLaughlin <janice@moremobilesoftware.com>
The Suunto Eon Core uses a different USB PID, but otherwise it's
compatible with the Eon Steel. It's probably an Eon Steel internally,
but with a smaller form factor.
To be able to distinguish between the two models and use the correct USB
PID, each model is assigned a different (artificial) model number.
Reported-by: Nick Shore <support@mac-dive.com>
The Suunto Eon Steel seems to have a limit of maximum 400 dives. Once
that limit is reached, the oldest dives get overwritten with newer
dives. But the order in which the dive entries are downloaded isn't
changed, and thus the most recent dive is no longer the last entry.
For the first 400 dives, the order is always straightforward:
D001 D002 ... D399 D400
The most recent dive is always the last entry, and no special processing
is necessary. But once the limit is reached, the next few dives will
start to overwrite the oldest dives, but the order remains unchanged:
D401 D402 ... D399 D400
Thus in order to return the dives in the correct order (newest first),
we can no longer assume the most recent dive is the last entry, and thus
we need to locate it manually.
The new algorithm is based on the assumption that the most recent dive
will have the hightest timestamp. And to be able to walk backwards
through all the entries, the list is assumed to be a circular list.
The EON Steel can use the new 'timesync' interface to set the time
automatically from the computer it is connected to.
This also regularizes the EON Steel command names a bit, and adds a few
new commands (you can also read the time etc, which this doesn't
actually use).
[Jef Driesen: Modified to follow the existing naming conventions, return
the correct error code and avoid arithmetic operations with signed
integers.]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
At the moment the progress events are reported for each download
operation separately. Combined with the fact that the size of the dives
isn't known in advance, and thus the progress events are based on a
worst case value, the user experience is far from optimal. In practice,
the progress goes from 0 to 100% for every manifest, and it stays close
to zero while downloading the dives.
This is improved by combining the individual progress events into a
single progress for the entire download. This global progress simply
counts the number of individual download operations. Since each
operation is now subdivided into a fixed number of steps, regardless of
the size of the transfer, the perceived speed is no longer constant.
The model number is stored in the final block of each dive. But for an
efficient implementation of the fingerprint feature, the devinfo event
should be emitted before downloading the manifests or the dives. Thus
reporting the correct model number is problematic.
Currently the model number is simply hardcoded to the value of the
Petrel. This is sufficient for the parser, because there the model
number is only used to distinguish the Predator from all the other
models. Now, because the petrel backend doesn't support the Predator,
and the predator backend (which supports both the Predator and Petrel)
can obtain the correct model number from the final block, the hardcoded
value works fine. Except of course for identifying the actual model!
Allthough there doesn't seems to be a command to retrieve the model
number directly, we can retrieve the hardware type and map that to the
model number.
The first dive computer to support this is the Perdix AI. Interestingly,
this keeps track of two sensors at all times. I haven't seen data with
two sensors active, yet.
[Jef Driesen: Update to the latest documentation.]
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The earliest document I have references log version 6. There are
apparently older versions, but I don't know what the differences
are. Before version 7, the log version wasn't always reliably
stored, so we assume 6 is the minimum and use 7 (or later) if we
find it.
[Jef Driesen: Initialize and reset the cache correctly.]
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Sync with the upstream version of the Aladin Square.
This picks the same model name that Jef picked in uwatec_smart_parser.c.
* jef/master:
Add support for the Scubapro Aladin Square
It works like the G2, but has a different model number, and different USB device ID.
Lots-of-testing-by: Vincent <vavincavent@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The communication protocol is identical to the G2 protocol, but with a
different USB VID/PID (c251:2006).
Note that unlike the G2, the Aladin Square seems to support only 33 byte
USB HID packets (1 byte report id and 32 bytes payload), even when the
actual command is much smaller. Without padding the commands, the dive
computer doesn't reply at all. Because the padding is already there, to
support the Windows api, no further changes are necessary.
Merge with Jef's upstream libdivecomputer:
- some OSTC parsing fixes, including getting the initial CNS into the
first sample
- syntactic cleanups to the Scubapro Aladin Sport Matrix support to
match upstream
* git://git.libdivecomputer.org/libdivecomputer:
OSTC: initialize initial CNS from header
Use an out-of-range value as undefined
Support for the Scubapro Aladin Sport Matrix.
It turns out that the Scubapro G2 itself does not care at all, but
apparently some of the other dive computers that use the same protocol
do).
In particular, Vincent reports that his Scubapro Aladin Square downloads
ok with the USB ID's switched to c251:2006, but only if we send 32-byte
USB HID payload packets, even though the command itself is much smaller.
Otherwise it will simply not reply at all.
To actually download correctly, we'll still need to do some model-
specific USB ID updates, and there will be some model changes for the
Aladin Square, but this at least fixes the transport side.
Jef had actually already done this because of the Windows behavior side,
I just hadn't thought it could possibly matter. Mea Culpa.
Reported-and-tested-by: Vincent <vavincavent@gmail.com>
Cc: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Cc: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As the OSTC does not report a CNS value on the first sample, we need to
initialize it differently. This can be solved by using the initial CNS
value form the dive header, and storing that value in the first sample.
The resulting patch is very similar to 44f629f03a91a3b3.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The main purpose of the magic value UNDEFINED, is to indicate that a
value isn't present in the data. But since the value 0xFF can actually
be stored in the data, we can't distinguish between those two cases.
This ambiguity can be avoided by using a magic value that lies outside
the valid range for 8 and 16 bit fields.
Note that an initial gas mix value of 0xFF remains interpreted as
UNDEFINED, but this is now made explicit.
The code relied on the dives being ordered by date in the directory
listing, which is normally true. But once the dive computer fills up
(after 400 dives or so), it starts re-using entries in the dive list,
and the dive directory is no longer ordered by date.
This matters because we want to download the latest dives first, since
subsurface will generally stop downloading once it finds an existing
dive.
NOTE! If you screw up the date on the dive computer, the old behavior
was possibly more to your liking, since - as long as the dive list
hadn't filled up - it wouldn't really order by date, but by dive
creation.
However, I don't see any way to get that information once the dive list
has filled up, so "order by dive date" is as good as it gets.
If you do screw up dates, and you want to download new dives that are
"older" than the dives you already have, you will need to basically set
the "download all dives" flag, and then select the new dives manually.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The model number was wrong. Mea culpa.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull Uwatec date handling fix from Jef Driesen.
This merges with upstream libdivecomputer, where Jef fixed the overly
complicated and fragile date parsing of the Uwatec smart backend.
It used to try to guess the base epoch of the dive computer by comparing
current time on the dive computer with the current time on the
downloader, but if the time and date of either was wrong (and the date
on dive computers often is) that would get the wrong answer.
* git://git.libdivecomputer.org/libdivecomputer:
Replace the clock calibration with a fixed epoch
The protocol is identical to the G2 protocol, with the exception of a
missing handshake.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently the date/time parsing assumes the reference time (epoch) of
the device clock is unknown. Hence we retrieve the current time of the
device (devtime) and the host system (systime) during the download.
Since both timestamps represent the same instant in time, but with a
different reference time, we can calibrate the device clock as follows:
ticks = parser->systime - (parser->devtime - timestamp) / 2
But this produces wrong results once the device clock has been adjusted
manually. Adjusting the device clock will suddenly increase (or
decrease) the devtime, while the systime continues ticking forwards
normally. Hence all dives recorded before the time adjustment will get
an incorrect date/time value.
Fortunately all devices appear to use a fixed epoch (2000-01-01 00:00:00
UTC) and we can simply replace the calibration with a hardcoded value.
Reported-By: Linus Torvalds <torvalds@linux-foundation.org>
Merge with upstream libdivecomputer: USB HID fixes.
* git://git.libdivecomputer.org/libdivecomputer:
Make the initialization thread-safe
Initialize the usb library only once
Perform the initialization inside a critical section.
Unfortunately Windows critical sections, which are the simplest
synchronization mechanism available on Windows, do not support static
initialization. A call to InitializeCriticalSection is required.
Therefore a simple spinlock, with an implementation based on atomic
operations, is used as a workaround.
Initializing the hidapi library more than once is tricky. The hid_init()
function can be called multiple times, but the the hid_exit() function
will free the resources unconditionally, regardless of how many times
the hid_init() function has been called. The consequence is a premature
termination of the library.
To avoid this problem, the calls are reference counted. Note that this
workaround can't protect against calls made outside the libdivecomputer
code!
The libusb library doesn't suffer from this problem, because each
initialization returns a new context pointer. But for consistency, we
now also use a single reference counted libusb context.
Merge with upstream libdivecomputer:
- workarounds for Windows libusb and hidapi issues
- misc random cleanups/noise
- rename DiveSystem to Ratio
- make Cochran with better with FTDI
- new support for: Suunto D4f, Ratio idive tank pressure, and Sherwood
Insight temperature and Oceanic ndl/deco sample.
* git://git.libdivecomputer.org/libdivecomputer:
Workaround for a Windows libusb issue
Use a fixed size packet for sending
Replace the size macro with the sizeof operator
Use the correct printf format for the size_t type
Move platform specific macros to a common header file
Use the correct data type for the return value
Rename the DiveSystem vendor to Ratio
Fix the Sherwood Insight temperature
Implement the ndl/deco sample
Change communication parameter to work better with FTDI
Retry read operations on failure
Add support for the Suunto D4f
Implement the tank pressure
When libusb uses the Windows HID api internally, it does automatically
prepend a zero report ID to the data for devices which support only a
single report. But apparently it also returns a size of one byte extra!
As a workaround, the number of bytes is limited to the actual size.
See commit c9ed92d3f55c259931527a27d018eb5791a176dd for a similar issue
in the hidapi library.
The Windows HID api always expects to receive a fixed size buffer
(corresponding to the largest report supported by the device). But
unlike the hidapi library, the libusb library doesn't automatically pad
the buffer to the expected size when trying to send less bytes. Thus
when trying to submit the transfer, the underlying Windows api call
immediately fails with ERROR_INVALID_PARAMETER.
To workaround this problem, pad the data packet with zeros manually and
always send the entire packet (1 byte report ID and 32 bytes payload).
At the time support for the Orca and iDive series was implemented, they
were being sold under the "DiveSystem" brand. But nowadays, the newer
iDive and iX3M series are being sold under the "Ratio" brand. Since this
frequently confuses end-users, let's rename the libdivecomputer vendor
name as well.
The Orca and the original iDive series remain under the DiveSystem
brand.
