Merge upstream libdivecomputer changes from Jef Driesen.
* https://github.com/libdivecomputer/libdivecomputer:
Add Travis CI integration
Fix the transport command-line parameter
Document dc_descriptor_get_model
Include stddef.h in iostream.h
Add support for the Mares Smart Air
Fix the average depth for older OSTC dives
Add support for the Oceanic Pro Plus X
For older OSTC dives, using logbook format version 0x20, the average
depth is not available in the dive header. It's only available since
version 0x21, which increased the header size from 47 to 57 bytes.
This adds the string field interface to the HW OSTC family, including
the proper serial number handling.
The deco model information was done by Anton Lundin in the original
subsurface branch, and the salinity, serial number, battery voltage and
desat information was added by Dirk Hohndel. Jan Mulder added the
battery percentage.
[ The sign-offs have been taken from the original commits in that old
subsurface branch, and I'm marking Dirk as the main author because on
the whole most of the lines come from him - Linus ]
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add a new type to distinguish between closed circuit (CCR) and
semi-closed circuit (SCR) diving. Some dive computers from HW and
DiveSystem/Ratio support this.
Because the CCR/SCR abbreviations are more commonly used, let's take the
opportunity to also rename the existing DC_DIVEMODE_CC. To preserve
backwards compatibility, a macro is added to map the old name to the new
one.
Reported-by: Jan Mulder <jlmulder@xs4all.nl>
The OSTC3 stores the dive headers and profile data in two separate
memory areas. There is a header area with fixed positions and a profile
area which is used as a ring buffer. Each dive header stores the
position of the profile data in the ring buffer.
Now, once there are more dive headers then room for the profiles, the
oldest profiles (but not the headers) are overwritten with new data.
Because the dive headers are not updated when their profile data gets
overwritten, they will now point to data that is no longer available.
The internal logbook detects this situation and does not display the
profile. But during the download, there is no such check, and the OSTC
will send invalid profile data.
This invalid profile data should be dropped on the receiver side.
Unfortunately implementing the exact same check as is done by the OSTC
itself isn't possible, because the OSTC doesn't send the 6 byte internal
header on which the check is based. As a workaround, the two byte
end-of-profile marker and the length field in the profile header is used
to detect overwritten profiles.
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.
Allthough most dive computers always use local time and don't support
timezones at all, there are a few exceptions. There are two different
sources of timezone information:
- Some of the newer Uwatec/Scubapro devices use UTC internally and also
support a timezone setting. This UTC offset is currently taken into
account to obtain the dive date/time, but the UTC offset itself is
lost.
- Uwatec/Scubapro and Reefnet devices rely on the clock of the host
system to synchronize the internal device clock and calculate the
dive date/time. The consequence is that the resulting date/time is
always in the timezone of the host system.
In order to preserve this timezone information, the dc_datetime_t
structure is extended with a new "timezone" field, containing the UTC
offset in seconds. Devices without timezone support will set the field
to the special value DC_TIMEZONE_NONE.
The dc_datetime_localtime() and dc_datetime_gmtime() functions will
automatically populate the new field with respectively the local
timezone offset and zero. The dc_datetime_mktime() function will take
into account the new timezone field for the conversion to UTC. The
special value DC_TIMEZONE_NONE is interpreted as zero.
In CCR fixed setpoint mode of the OSTC3, the initial setpoint at the start
of the dive was not set. This fix adds the initial setpoint based on
the data in the fixed setpoint table (ie, the first fixed setpoint is
the initial one).
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The vendor_product_parser_create() and vendor_product_device_open()
functions should be called indirectly, through the generic
dc_device_open() and dc_parser_new() functions. And the
vendor_product_extract_dives() functions are internal functions that
should never have been part of the public api in the first place.
In the public header files, all symbols are marked extern C. When using
a C compiler, there is usually no problem if the header isn't included
in the C file. But the msvc build system uses the C++ compiler (due to
the use of some C99 features not supported by the msvc C compiler).
Due to a firmware bug, the deco/ndl info is incorrect for all OSTC4
dives with a firmware older than version 1.0.8. Since it's not possible
to correct the info again, it's ignored and not returned to the
application.
To be able to pass the OSTC 3 model number to the parser, and preserve
backwards compatibility, we need a new function. The new function should
also be used for the Frog, by passing zero as the model number.
Using the hw_ostc_parser_create() function with the hwos parameter set
to one, is now deprecated but will remain supported for backwards
compatibility.
The frog parameter and field are not only used for the Frog, but also
for all hwOS based models. Therefore, using the more generic hwos as the
name is more meaningful.
For the OSTC3 compatible devices, a missing initial gas mix (e.g. no gas
marked as the first gas) leaves the initial gas mix index at its default
value of zero. This is different from the OSTC2 compatible devices,
where a missing initial gas is stored as the value 0xFF.
By initializing the index with the value 0xFF, the existing detection
works for both variants.
Both the allocation and initialization of the object data structure is
now moved to a single function. The corresponding deallocation function
is intended to free objects that have been allocated, but are not fully
initialized yet. The public cleanup function shouldn't be used in such
case, because it may try to release resources that haven't been
initialized yet.
Instead of freeing the object data structure in the backend specific
cleanup function, the memory is now freed automatically in the base
class function. This reduces the amount of boilerplate code in the
backends. Backends that don't allocate any additional resources, do no
longer require a cleanup function at all.
The new gasmix sample contains the index of the active gas mix.
This new sample is intended as a replacement for the existing gas change
events (SAMPLE_EVENT_GASCHANGE and SAMPLE_EVENT_GASCHANGE2). To maintain
backwards compatibility, the legacy events are marked as deprecated but
not removed yet.
In CC mode, only the diluents are stored in the header. The list with
the OC gas mixes, which are used for bailout, are not stored in the
header. In order to retrieve the bailout mixes too, we need to parse the
profile and add them to the manual gas mixes.
In some rare cases, the initial gas mix contains the value 0xFF. This
value is obviously outside the expected range (1-5), and therefore
causes the parsing to fail. It's not really clear how this can happen.
As a workaround for the fatal error, we now ignore the invalid value and
simply proceed without a gas mix.
Even if there are no O2 sensors connected (for example in auto or fixed
setpoint mode), the device records a ppO2 sample with all three values
set to zero. Such samples are now ignored, as if there was no ppO2
sample present.
Reported-by: Anton Lundin <glance@acc.umu.se>
When the PPO2 sample was introduced, we didn't take into account the
fact that rebreathers usually support multiple O2 sensors. The HW OSTC
supports for example three sensors. In order to support multiple values,
without having to introduce a new data structure with an additional
sensor id field, we simply relax the assumption of allowing only one
DC_SAMPLE_PPO2 value per sample. Applications that are not prepared for
multiple values, will automatically use only one of them (probably the
last one).
The DC_FIELD_GASMIX api doesn't support the 6th manual gas very well.
Manual gas mixes are either not taken into account at all (OSTC3), or
only the last value is returned (OSTC2).
We now parse the profile data in order to retrieve all the manual gas
mixes too. Note that manual gas mixes are only included when they are
actively used during the dive. This is a small change in behaviour for
the OSTC2.
To simplify the implementation, there is an upper limit of 10 manual gas
mixes (or 15 gas mixes in total). This is an arbitrary choice, which
should be more than sufficient in practice. If it turns out to be too
small, we can always increase the number, or even make it truely
unlimited.
With the exception of the different event mask (single byte 0x80 vs two
byte 0x0100), the OSTC3 bailout event is identical to the OSTC2 variant.
Just as before, the new bailout event is reported to the application as
a normal gas change event.
Currently, the buffer overflow checks take into account the size of the
entire dive. But since the length of the extended sample is stored in
the data, we can actually check for overflows in each sample. The main
benefit is that errors will be caught much earlier now.
An additional advantage is that we can now easily skip any remaining
sample bytes. Normally such bytes are not present, unless a firmware
update introduces a new feature which our parser doesn't support yet.
In the OSTC3 data format, the 7th bit of the event byte is used to
indicate whether another event byte is present or not. For the OSTC2,
this 7th bit remained unused, and I assumed it would eventually get used
in the same way as the OSTC3 does. But that assumption turns out to be
wrong. Starting with firmware v2.66 the 7th bit is used for a new
bailout event.
This patch leaves the existing logic intact, but except for the OSTC3
format (version 0x23), the maximum number of events bytes is now limited
to just one byte.
Although the communication protocol of the OSTC3 is nearly identical to
that of the Frog, the different size parameters make it hard to share
the code easily. On top of that, if we ever implement native bluetooth
communication support, we'll need a completely separate backend anyway.
Therefore the Frog backend is simply duplicated, with a few OSTC3
specific changes applied here and there.
The existing ostc parser is upgraded to support the new OSTC3 data
format.
The Frog stores the index of the initial gas mix at the same location
as the OSTC, but the gas mix percentages are at a different offset, and
the number of gas mixes is different too. Parsing all the gas mixes in
advance makes the code easier to read and more future proof.
With the layout descriptors, most hardcoded constants are now in a
central place, which will make it easier to add support for new data
format variants.
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.
Two issues:
- the OSTC counts its gases 1-based, not 0-based
- dives don't always start with the first gas. Simply create a gas change
event right after the first time sample that informs the application what
the first gas mix is
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The recently introduced CNS support caused a regression for older
firmware versions. If a firmware doesn't support a certain sample
yet, the corresponding sample divisor and size are both equal to
zero (the default value for unused bytes). However, because the
size was always checked, regardless of whether the sample is
actually present or not, this zero size caused the parsing to fail.
To fix the regression, the size is now only checked when the
divisor indicates the sample is actually present.
Having these as events seems less useful since for many dive computers
there are data with every sample - so it makes much more sense to have
these as part of the sample.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
