Currently the profile ringbuffer starts at the base address 0x4000, but
I believe the real start is one 0x20 byte page earlier, at 0x3FE0. I
have two reasons for this:
1. To locate the start of a dive, we always have to substract one page
from the pointers in the logbook ringbuffer. With the new base address,
they would point directly to the start of the dive, which makes a lot
more sense.
2. When comparing the divetime as stored in the header with the one
obtained by counting the number of samples, they always match except for
dives that span the ringbuffer wrap point. If those extra 0x20 bytes are
included, the counts do match again.
Unfortunately, this change breaks the assumption that the ringbuffer is
aligned to packet boundaries. As a workaround, we define a virtual
ringbuffer that is slightly larger than the actual ringbuffer, but
properly aligned. Data outside the real ringbuffer is downloaded and
then immediately dropped.
Packets have a fixed size of 0x80 bytes, while a single page is only
0x20 bytes long. Thus each read operation always returns 4 pages at
once. Now, if the end-of-profile pointer is not nicely aligned on a
packet boundary, then the download algorithm won't arrive exactly at the
start address of the ringbuffer, because the ringbuffer is properly
aligned. The consequence is that we won't even notice we reached the
ringbuffer boundary and happily continue reading outside the ringbuffer.
Oops!
This is fixed by aligning the end-of-profile pointer, which guarantees
that all read operations are now nicely aligned to packet boundaries.
When trying to send a command, the first attempt always fails. We
receive the echo, but no data packet. A second attempt usually works,
but we always get back the same data packet. That's cleary wrong.
Now, when comparing the data packets with those of the Tusa application,
I noticed something very interesting. When we request the first packet
(page 0x0000), we get:
W: 520000
R: 520000
R: 00880124056202000250002890470824...19202720002000200020002000204145
The Tusa application also request this page, but the response is
completely different:
W: 520000
R: 520000
R: 22182224222322092203220522112210...0000000000f021fc0000000000000045
The response we get is identical to the response that the Tusa
application gets for page 0x0052:
W: 520052
R: 520052
R: 00880124056202000250002890470824...19202720002000200020002000204145
The only difference here is the echo of the command. But the echo should
be ignored, because it's generated by the pc interface, and not send by
the dive computer. This is easily verified by the fact that we always
receive an echo, even without a dive computer connected (e.g. only the
pc interface).
Notice how the command type (first byte) and page number (last byte) are
identical (0x52) for this request! I suspect that somehow the command
type ends up being interpreted as the page number. That would explain
why we're always getting the same response: as far as the device is
concerned we're always requesting page 0x52. This is probably also
related to the fact that the device doesn't respond after the first
request. It's not impossible that if the first command wasn't received
correctly and we resend the command, the device receives something that
contains parts of both attempts.
By sending the command and reading the echo byte by byte instead of all
at once, the above problem disappears.
Without the delay, the communication immediately fails. We receive the
command echo, but not the actual data packet. I suspect the device is
still be busy with the initialization and needs a bit more time before
it's ready to accept a request.
We received data from a Mares Smart where the existing heuristics to
detect the last dive are not sufficient. The very last check, where the
calculated and stored are compared results in a fatal error.
The Mares Smart supports not only scuba diving, but also freediving.
Because the freedive data format is fundamentally different from the
regular dives, being able to detect the type of dive in advance is very
important. For that reason, Mares moved the 4 bytes containing the dive
mode and number of samples from the beginning of the header to the end.
Except for this 4 byte shift, there are no changes for regular dives.
For the freedives, there is no real profile available, only a summary of
the entire freedive session. In an attempt to workaround this
limitation, we generate a pseudo profile in exactly the same (but ugly)
way as is done in the Mares Nemo backend.
The new OSTC3 (model 0x1A) is identical to the existing OSTC3, except
that the usb interface has been replaced with a bluetooth interface.
The new OSTC2 (model 0x1A) will retain the look and feel of the OSTC 2C
(e.g. plastic housing, piezo buttons and rechargable battery), but under
the hood it will use the same firmware as the OSTC3. It will also have a
bluetooth interface.
The gas mix index stored in the alarm bytes is occasionally out of range
(larger than the number of available gas mixes). The index refers to one
of the disabled gas mixes. Since those are excluded now, this results in
a fatal error instead of a switch to a nonsense gas mix.
To workaround this problem, the alarm based gas switches are disabled
until we figure out how to parse them correctly.
The Chromis is almost identical to the Meridian, and will probably need
the same workaround. Although I don't have any data to confirm this,
let's just keep the two in sync.
Gas mixes are disabled by setting their oxygen percentage byte to 0x00.
This is clearly an invalid gas mix, and it makes no sense to return it
back to the application.
It seems the device doesn't allow you to enable a gas mix if the
previous gas mix has already been disabled. Therefore we can simply stop
parsing the gas mixes once the first disabled gas mix has been found.
According to the technical specifications, the Uwatec Aladin Tec 2G
supports maximum two gas mixes. The data appears to confirm this,
because the extra third gas mix always contains unrealistic oxygen
percentages.
However, I came across some data containing gas switches to the third
gas mix. The interesting part is that according to the Uwatec
application, this is actually a switch to the second gas mix in the
header. One possible explanation is that for models with up to 3 gas
mixes, they are labelled respectively "bottom", "travel" and "deco" mix.
But the documentation for the Aladin Tec 2G only refers to the bottom
and deco mix. So it might be that internally the index of the deco mix
is always the 3th mix, regardless of whether a travel mix is supported
or not.
If the only allowed values for the gas mix index are 0 (for the bottom
mix) or 2 (for the deco mix), then manually remapping the deco mix is
equivalent with ignoring the lowest bit. This has the advantage that the
required bitmasks and shifts are no longer different from those for the
other models.
For the Galileo Trimix we don't know yet where and how the gas mixes are
stored. Right now, we just pretend there are no gas mixes available,
which is misleading.
Originally, I assumed that the trimix firmware update changed the model
number from 0x11 (Galileo) to 0x19 (Galileo Trimix). But that assumption
appears to be wrong because I received data from a Galileo with model
number 0x11, but with the trimix data format. Another explanation might
be that the trimix data format is not specific to the trimix firmware.
Anyway, this is easily fixed by treating both models identically.
The latest firmware v1.75 introduced a new hardware descriptor byte to
identify the different models based on their hardware features. This new
hardware descriptor is now used as the libdivecomputer model number. For
older firmware versions, which do not support the descriptor yet, there
is an automatic fallback to the previous method based on the serial
number.
When trying to send an unsupported command, the ostc will simply ignore
the command. Instead of echoing the command byte back, the ostc will
immediately send the ready byte, to indicate it's ready to receive the
next command. We can use this to detect unsupported commands, because
the ready byte is a reserved value and guaranteed to never be a valid
command byte.
Normally we don't send invalid commands. But newer firmware version can
always introduce new commands to support new features. To maintain
backwards compatibility with older firmware versions, it's important to
be able to detect unsupported commands and provide a fallback.
In freedive mode, the Oceanic Veo 2.0 and 3.0 have samples that are only
4 bytes long, instead of the normal 8 bytes.
The Oceanic VT3 and Hollis DG03 use the same logbook layout, and
although I haven't been able to confirm this with real data, it's very
likely they need the same fix.
The Oceanic VTX is very similar to the Aeris A300 CS. The main
difference is the higher baudrate (115200 vs 38400). This is annoying
because without the correct baudrate, no communication is possible and
thus the existing autodetection based on the version packet doesn't
work. As a workaround, we now rely on the model number from the device
descriptor. The consequence is that the user must select the correct
model now (or at least a model with the same baudrate).
This change will be necessary for the Oceanic VTX, because it uses a
higher baudrate.
To maintain backwards compatibility, the existing function remains
unchanged and a new function is introduced instead.
At the moment, there is only retry logic for the ACK/NAK byte. Corrupt
data packets (e.g. wrong checksum, unexpected length, etc) are treated
as a fatal error. By reading the entire packet inside the retry loop,
all non-fatal errors are automatically taken care off.
This change is necessary for the Oceanic VTX. For some unknown reason,
the device always responds with an invalid data packet when sending the
version command for the first time:
W: 84 00
R: 5A 4F ?? 45 41 4E 56 54 58 20 31 42 20 32 30 34 38 E9
There is always one byte missing (marked with question marks), resulting
in a timeout. However, when re-sending the command again, we receive a
valid data packet:
W: 84 00
R: 5A 4F 43 45 41 4E 56 54 58 20 31 42 20 32 30 34 38 E9
This might be a firmware bug, because we're observing the exact same
behaviour with the official Oceanlog application.
In freedive mode, the Aeris Elite T3 has samples that are only 2 bytes
long, instead of the normal 8 bytes.
Since there are many other models which support a freedive mode, the new
implemention provides the necessary infrastructure to easily integrate
those other models too.
The OSTC cR is new model for closed circuit (CCR) diving. Under the hood
it's identical to the OSTC 3, but with an S8 connector to interface with
an external oxygen sensor. Since the data format already supports oxygen
sensors, the OSTC cR can be added to the list of supported devices
without any further changes.
The EON Steel notifications and states match the libdivecomputer ones
very badly, but this tries to make sense of the ones that match. And
puts the infrastructure in to do others in the future.
Signed-off-by: Linus Torvalds <torvalds@linux-fouindation.org>
The really sad part is that the EON Steel handles gas change events
correctly, by actually saying which cylinder it switches to. But the
libdivecomputer interfaces are broken, and only contain the gas *mix*
you switch to, which is ambiguous since you could have the same mix in
multiple cylinders.
Maybe we could put the one-based cylinder index into the "flags" field?
With zero meaning "unknown". That would be a straightforward extension.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The OSTC3 can display a status message of up to 16 characters large.
Since this does not include the terminating null character, the buffer
needs to be one byte larger.
