At some point (possibly around v71 of their firmware), Shearwater implemented
PNF for the Petrel and Petrel 2. Those are of course not air integrated, and
apparently don't support adjustable sample rate, so the log data doesn't include
opening and closing record 5. Instead of failing when those aren't found, we
should simply only access those when they actually exist.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Some of the newer Shearwater dive computers support up to 2 tank
pressure sensors. The tank pressure samples were already reported, but
the tank field with the corresponding begin/end pressure was still
missing.
To be able to collect the tank begin/end pressure, the log version needs
to be available earlier, because it's needed for parsing the tank
pressure data in the samples. Therefore, extract the log version
immediately after locating the opening record.
This will allow parsing dives from the Shearwater Teric, but depending on the
firmware could also be used on older models.
Based on ideas and code from Dirk Hohndel
The warning about disabling the O2 sensors due to factory default
calibration values, applies only if there is at least one calibrated O2
sensor present.
This has no effect on the calibration bits, because those are already
zero if there are no calibrated O2 sensors present.
If all (calibrated) sensors still have their factory default calibration
values (2100), they are probably not calibrated properly. To avoid
returning incorrect ppO2 values to the application, they are manually
disabled (e.g. marked as uncalibrated).
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 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>
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.
The O2 sensor millivolt values are only valid if external O2 sensor
monitoring is enabled.
Note that the interpretation of the PPO2 status bit appears to be
reversed (0=external and 1=internal).
Reviewed-by: Anton Lundin <glance@acc.umu.se>
Correcting the Predator calibration value with a scaling factor produces
even more reasonable ppO2 values compared to using a constant offset.
The scaling factor of 2.2 is based on a linear regression between the
average ppO2 reported by the dive computer, and the average ppO2
calculated over all (calibrated) sensors using the raw calibration
value.
Reviewed-by: Anton Lundin <glance@acc.umu.se>
The calibration values for the Petrel are typically in the range 1600 to
2400, while for Predator they are much smaller, with values in the range
800 to 1400. The consequence is that the calculated ppO2 values are too
low for the Predator. Adding a constant offset of about 1000 changes the
calibration value to be in approximately the same range as the Petrel,
and hence more reasonable ppO2 values. But this correction should only
be applied for the Predator, and not the Petrel.
Reviewed-by: Anton Lundin <glance@acc.umu.se>
This reads the reported mV values from the sensors, and based on the
calibration values converts it into a ppo2 value to report.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Sending this in OC mode is redundant and might confuse applications that
assume they only get PPO2 data in CC mode.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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.
The Shearwater devices support adding, removing or editing gas mixes
during the dive. The pre-defined gas mixes available in the opening and
closing block are only a snapshot of the configuration at the start and
at the end of the dive. Thus by editing the gas mixes during the dive
it's possible to switch to a gas mix that is not present in the opening
(or even the closing block). The parser doesn't support that.
To avoid this problem, we now collect the available gas mixes from the
sample data. As a side effect we only return those gas mixes that are
effectively used during the dive.
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.
The Shearwaters store the current dive mode for each sample, and not one
single value for each dive. Therfore we need to process all samples. If
there is at least one sample marked as closed circuit, we classify the
dive as a closed circuit dive. Otherwise we default to open circuit.
Gas mixes that have been disabled are stored as a mix with 0% oxygen and
0% helium. This is clearly an invalid gas mix, and it makes no sense to
return it back to the application.
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).
There are two good reasons for this change. First of all, it makes the
Predator data format more consistent with the Petrel data format, which
also has the final block appended to each dive. But even more important
is that we might actually need the information stored in the final block
someday.
The final block contains important information about the device, such as
the firmware and logbook version. Right now this information is simply
lost after the download. But if the data format ever changes to support
some new feature, we'll likely need that information to autodetect the
correct format.
Unfortunately this also changes the dive format in a non-backwards
compatible way. However, to minimize the inconvenience, the legacy
format (without the extra final block) remains supported in the parser.
The Petrel (with updated firmware) supports an enhanced communication
protocol, which is more efficient and powerfull than the legacy Predator
compatibility mode. The new protocol uses data compression for faster
transfers and supports the ability to selectively download individual
dives. Last but not least, the new protocol isn't limited to the last
128kB of logbook data, but can access the full logbook capacity (16MB).
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.
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>
So far only OSTC and Shearwater Predator are supported. For the OSTC we
support CNS and setpoint changes in the samples (the current hardware
doesn't actually support ppO2 sensors and for the older hw that does I
don't have the correct encoding information).
For the Predator we support only the "average ppO2 during the sample".
The Predator also gives us a CNS value at the end of the dive - I don't
quite know yet how to deliver that back to the consumer. Possibly as CNS
value in the very last sample? That would at least be consistent.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The Shearwater Predator has two different sets of gas mixes for OC
(Open Circuit) and CC (Closed Circuit) mode. Since the dive mode can
be switched during the dive (e.g. in a bailout scenario), there is no
easy way to select one of both sets. With this change, both sets are
returned. It's not a perfect solution, but for CC dives it's already
an improvement.
