The default libdivecomputer fields are good for structured data that has
a well-defined format, like the cylinder information, or the temperature
data.
But it is entirely useless for miscellaneous divecomputer-specific
information, where there is no standard way of representing the data
across different kinds of dive computers.
Examples of this include simple things like deco calculation algorithm
(what kind of Buehlmann, gradient factor information or is it some
vendor-specific mode?) and even something as trivial as a serial number.
No, serial numbers aren't numbers. They are strings. Really.
But this also includes much more complex data that is really specific to
a particular dive computer or family: what the battery status is for the
dive computer or the wireless transmitters it is connected to (sometimes
it's a voltage, sometimes it's a percentage, sometimes it's just "good"
or "marginal").
It also includes random incidental information like firmware version
numbers (again, these are strings, not numbers, despite the name) or
dive mode and personal adjustment information.
So allow the dive computer to just give "extra information" in the form
of an array of { key, value } string pairs. For my Perdix AI the
information could be
{ "Serial", "370d1f24" }
{ "FW Version", "44" }
{ "Deco model", "GF 40/85" }
{ "Battery type", "3.6V Saft" }
{ "Battery at end", "3.4 V" }
and for my EON Steel with three wireless transmitters connected it can
look like this:
{ "Serial", "1742104730" }
{ "FW Version", "1.6.5" }
{ "HW Version", "70.3.0" }
{ "Battery at start", "Charge: 83%, Voltage: 4.012V" }
{ "Deco algorithm", "Suunto Fused RGBM" }
{ "Personal Adjustment", "P-2" }
{ "Battery at end", "Charge: 79%, Voltage: 3.977V" }
{ "Dive Mode", "Trimix" }
{ "Desaturation Time", "7:53" }
{ "Transmitter ID", "1519107801" }
{ "Transmitter Battery at start", "87 %" }
{ "Transmitter Battery at end", "87 %" }
{ "Transmitter ID", "1550110028" }
{ "Transmitter Battery at start", "100 %" }
{ "Transmitter Battery at end", "100 %" }
{ "Transmitter ID", "1719102387" }
{ "Transmitter Battery at start", "100 %" }
{ "Transmitter Battery at end", "100 %" }
so this data is inherently unstructured and dependent on the dive
computer, but quite relevant to the diver. Subsurface shows this in the
"Extra Info" panel for each dive computer.
Also teach the example output-xml code about the new string field
extension. That example output-xml code was written by Anton Lundin in
the old Subsurface branch, and signed-off-by Dirk. The sign-offs here
are taken from that original work.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
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>
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.
Libdivecomputer always uses metric units internally. But when reverse
engineering a device that stores everything using imperial units, it's
very convenient to be able to switch the output to imperial units too.
