The gasmix query interface considers cylinders and gas mixes independent
things, so the tank data structure has a pointer to the gasmix index.
But the EON Steel treats cylinders as just having a gasmix (and so does
subsurface, for that matter), so the gasmix index for the tank is just
the same as the tank index.
But we never filled it in, so you'd always see a "gas index" of zero,
and subsurface would end up warning each time about how the gasmix index
doesn't match the cylinder index (but because subsurface actually agreed
with EON Steel, it worked despite the warning).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of hardcoding the enum values for setpoint type and gas type,
use "lookup_enum()" to actually parse the enum data and use that.
I don't think this matters right now, since the numeric translations
haven't changed, but it is the RigthThing(tm) to do.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This fixes a bug where the begin/end marker was mistakenly added as the
value instead of as flag.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The dive gas parsing cases can be split out into a helper function to
keep things more manageable. Especially since there will be a couple
more cases coming up.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It turns out you can't hardcode the enum numbers either, since they
change from dive to dive (or possibly firmware version to firmware
version).
So do it right, and actually parse the string descriptor for the enum.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The samples that take 'enum' types need the type descriptor to parse
what the enum type means.
This doesn't actually use the data yet, I need to add parsing of the
enum descriptor string.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The previous commit fixed the cache initialization testing, and
uncovered the fact that the tank size cache initialization didn't set
the initialized bit correctly. That oversight had been hidden by the
fact that we then tested the bit wrongly, so not setting it right didn't
use to matter as long as there were other higher cache bits that were
set.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The check for whether we had initialized a field in the EON Steel cache
data structure was wrong, causing some entries to be returned
successfully even if their field had never been initialized.
In most cases, it didn't matter, since the cache data was initialized to
zero (which is a fine default for uninitialized data), so most of the
time it didn't matter.
But for the recently added dive mode field, this caused OC dives to be
returned as freedives, for example.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This does the basic divemode and setpoint parsing for the EON Steel, and
gets the CCR download right in the big picture.
The cylinder information is still confusing and incorrect, but this is a
big step in the right direction.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
.. every time I look for a new feature I add debug code to print out all
the descriptors. So let's just do it once and for all.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Sadly the data we get from the EON Steel is a bit of a mess.
It doesn't really tell us if the data is metric or imperial (it always sends
both wet volume and working pressure). And in imperial mode the Suunto
engineers seem a bit confused. The pressure given (entered on the dive computer
in psi) is sent to us not in bar, not in atm... it's "something". As far as I
can tell it's a constant factor of 1.00069182389937 different from bar.
And the wet sizes are a bit to small to get the cuft size the user entered.
But instead of trying to guess and fix the mess, we just pass it through...
So this is somewhat useful, but not really what most users will want.
Linus started this commit with a few lines that parsed the right values out of
the data stream from the Suunto EON Steel. I then added the implementation of
the infrastructure to convert the raw data and report it back to the caller.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Unlike the other models, the Aladin Tec 2G uses only a single byte to
store the oxygen percentage, and there is no need to manually re-map the
deco mix.
Normally, the oxygen percentage is stored using two bytes (little endian
byte order). Thus for a device supporting two gas mixes, four bytes will
be used, and the corresponding gas mix id for each byte is as follows:
ID: 0 0 1 1
After re-mapping the id of the deco mix, this becomes:
ID: 0 0 2 2
Since oxygen percentages are limited to the range 0-100%, the highest
byte (marked with an X) should always be zero and can thus be ignored:
ID: 0 X 2 X
Now, because an oxygen percentage of zero indicates a disabled gas mix,
this is equivalent to a device supporting three (or even four) gas
mixes, each stored using only a single byte:
ID: 0 1 2 3
We can take advantage of this knowledge to avoid having to re-map the
deco mix id.
We only used to save 16 extended strings per dive from the EON Steel
download, which is _plenty_: it's not like we actually generate that
many strings. Firmware version, battery status, transmitter info -
there's just not that many strings.
Oops.
Except if you have lots of transmitters. Then each wireless transmitter
will have three strings each, for transmitter ID and beginning/ending
battery status.
I only have one, but Andreas Klein has four. And it took me
embarrassingly long to realize that he really did have them on the
dives, because after the first two transmitter IDs got recorded, the
string space filled up and we silently dropped the rest.
But I have learnt my lesson. Future generations will talk about how I
said "32 strings will be enough for anybody".
But at least it should be enough for a few more transmitters. Somebody
should extend this some better way, but I'm still chasing other issues.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The gasmix query interface considers cylinders and gas mixes independent
things, so the tank data structure has a pointer to the gasmix index.
But the EON Steel treats cylinders as just having a gasmix (and so does
subsurface, for that matter), so the gasmix index for the tank is just
the same as the tank index.
But we never filled it in, so you'd always see a "gas index" of zero,
and subsurface would end up warning each time about how the gasmix index
doesn't match the cylinder index (but because subsurface actually agreed
with EON Steel, it worked despite the warning).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of hardcoding the enum values for setpoint type and gas type,
use "lookup_enum()" to actually parse the enum data and use that.
I don't think this matters right now, since the numeric translations
haven't changed, but it is the RigthThing(tm) to do.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Several devices (e.g. Oceanic Geo, Oceanic Veo 2.0 and Tusa Zen) report
a maximum depth that is clearly too large. The problem is easily fixed
by ignoring the higher bits. The exact bit mask is an educated guess. A
12 bit value is plausible because it's also used for the sample depths.
Select the default memory layout for unsupported devices based on the
amount of memory indicated in the version string. This allows to
download a full memory dump.
The new version of the log book format broke the string handling.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In freedive mode the sample rate is only 1 second instead of 4 seconds.
The tank pressure fields appear to be re-used for some other (unknown)
purposes, and should be ignored.
The gauge and freedive mode bits are stored in the settings field. The
location of the gauge bit appears to be the same for all models. For the
freedive bit it depends on the model, and also not all models support
it.
The dive time is stored in two separate bytes: one for the number of
minutes, and another one for the hours. Since we only took into account
the first byte containing the minutes, the divetime for dives longer
than one hour was always too short.
The Aeris 500AI serial number appears to be located at a slightly
different offset, and with an unusual encoding. It's a BCD encoded
number, but with the digits of each byte swapped.
At the moment, the encoding of the serial number is tied to the global
pointer mode. To support devices where this is no longer the case, a new
entry for the serial number encoding is added.
The latest v2.09 (hwOS) and v1.1.0 (hwOS4) firmware introduced a new
variant of the hardware descriptor command. This extended command
returns:
- a 16 bit hardware descriptor
- a 16 bit feature descriptor
- an 8 bit model descriptor
The hardware descriptor is backwards compatible with the existing one
(upper bits are all zero for now). For the OSTC4, the feature descriptor
is currently used to indicated the Bonex scooter version (0x01), and the
model descriptor is 0x43. For all other models, the feature and model
descriptors are always zero for now.
For older firmware versions, which do not support the new extended
descriptor yet, there is an automatic fallback to the previous
descriptor.
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.
The OSTC4 firmware version uses four digits for the firmware version
(X.Y.Z.Beta), while all other hwOS models use two digits (X.Y). To
preserve backwards compatibility with the existing two byte data format,
the OSTC4 firmware version is packed into a 16 bit integer as follows:
XXXX XYYY YYZZ ZZZB
and stored with little endian byte order.
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.
This way Subsurface can show different icons depending on what kind of
event we report.
This also fixes a bug where the begin/end marker was mistakenly added as
the value instead of as flag.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For applications supporting offline parsing (like libdivecomputer's own
dctool application), some device specific knowledge is still required in
order to map a particular model to the corresponding backend. The new
convenience function will take care of that internally.
The already existing dc_parser_new() function does the same, but
requires an open device handle, which makes it unsuitable for offline
parsing.
I'm not sure how reliable it is, and older wireless tank pods had a bug
in the reporting (looks like the battery voltage range calibration was
done incorrectly, and it reports 0% battery for new batteries).
But depending on how well it actually works when the batteries start
getting weak, the transmitter battery reporting is potentially *very*
useful.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For some reason I hadn't reported surface time. It's trivial to do
especially now that we have the varargs string adding function.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The dive gas parsing cases can be split out into a helper function to
keep things more manageable. Especially since there will be a couple
more cases coming up.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
.. and use it for the cases that used to do this by hand (Personal
Adjustment and Desaturation Time).
There will be more users coming up.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The EON Steel reports it in seconds remaining after the dive. That's a
bit excessive, but I guess SI units is where it's at.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now that we support string events and don't need to try to figure out
some libdivecomputer event number that doesn't exist, it's easy to add
the proper support for the dive state reporting that the EON Steel has.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It turns out you can't hardcode the enum numbers either, since they
change from dive to dive (or possibly firmware version to firmware
version).
So do it right, and actually parse the string descriptor for the enum.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The samples that take 'enum' types need the type descriptor to parse
what the enum type means.
This doesn't actually use the data yet, I need to add parsing of the
enum descriptor string.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Right now it only has an indication of whether the cylinder size is
imperial or metric, which is frankly quite useless.
Turn it into a bitmask instead, where we keep the imperial/metric data
for compatibility, but add another two bits that say that it's a CC
cylinder, and whether it's the oxygen or diluent cylinder.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
