When reading data from the EON Steel, we'd generally continue reading
until we saw that a response was done by seeing a packet that wasn't
full.
That broke for the case of the data boundary matching the packet
boundary, fixed by the commit "suunto eon steel: fix file reading
special case".
However, that commit only fixed it for the case of reading a file, where
the result has a size that is known up-front. And most other situations
really don't matter, because the result size is fixed and fits in a
single packet, so it all works.
However, there are still a few cases that could trigger the problem,
notably reading the directory contents.
So change the send_receive() logic to actually read the expected size
from the receive header in the first packet of the reply. This means
that we need to re-organize the packet reception code a bit, but the end
result is that we are much more careful about data sizes,
This also changes the packet logging to be much more readable, by
logging just the actual data, and not the (uninteresting) per-packet
header, or the stale data at the end of the packet.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The "receive_data()" function would continue to try to read packets as
long as the previous packet was full-sized, but with just the right size
of file and the right chunking, the file might end at a packet boundary.
Then receive_data() would try to read more data, which fails - there are
no more packets, despite the last packet being full.
This never triggered for me, but Robert Helling forwarded a data dump of
a filure to read a dive due to this.
Since I don't trigger this case, I can't really test it, but I did check
that the new "stop early" logic works for me (ie never triggers ;).
Reported-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When compiling a 32bit dll with the mingw-w64 compiler, some 64bit
integer arithmetic operations are implemented using functions from
libgcc (e.g. __divdi3 and __moddi3 from libgcc_s_sjlj-1.dll). This
unexpected dependency is inconvenient for applications.
The run-time dependency can be avoid by linking statically.
reefnet_sensusultra_device_set_maxretries was killed off back in v0.3,
but was still lying around in the public header.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
At least one Oceanic Geo is unable to download the last memory page.
However, another device with an older firmware version (version 1D
instead of 2B), does not have this problem. So in theory the correct
layout depends on the firmware version.
But since the profile ringbuffer also appears to end at the address
0xFE00 instead of 0x10000, we'll never need to download that last page
in practice. Thus we can be lazy and simply use a single layout for all
firmware versions. The only drawback is that the last page might be
missing when downloading a full memory dump.
Applications are supposed to lookup the fingerprint when the devinfo
event is emitted. For the Uwatec Smart devices, the fingerprint is the
raw device timestamp. But because this timestamp was already used to
initialize the command before emitting the event, an outdated value
(typically the default value of zero) was used instead of the correct
one set by the application.
The Uwatec dive computers report the depth based on fresh water. Salt
water dives need a correction to take into account the salinity. There
is only a fresh/salt water flag present in the data, but Uwatec appears
to assume a salinity factor of 1.025.
The size of the dive header is one byte smaller: 0x32 instead of 0x33
bytes. Because we were expecting a larger packet, this bug caused the
downloading of the dive headers to fail. I'm surprised no one noticed
this mistake before.
With the new temperature and pressure field, artificially injecting the
temperature and pressure info from the header into the samples is no
longer necessary. Applications will typically expect a real temperature
or pressure profile, and not a few discrete points.
The two surface samples (with zero depth) at the begin and end of the
dive are kept for now, to support events that occur at the surface.
I forgot to include the Suunto Solution part in the previous commit.
In theory the Suunto Solution (and Eon) can't be affected by the ghost
event bug. All possible events bytes are already exhausted, and
therefore unknown events are impossible. But applying the fix anyway
doesn't hurt and keeps the code consistent with the other backends.
The newest Suunto models (e.g. D4i, D6i, D9tx and DX) support a few
additional events (type 0x15 and higher), which are not supported yet
because their interpretation isn't known.
Due to a nasty bug, these unkown events result in "ghost" events. When
such an unknown event is encountered, the sample type field isn't set
explicitely. Therefore it simply retains the value from the previous
sample, whatever that might be. If the previous sample happens to be an
event as well, then the unknown event will show up as a duplicate event.
But if the previous sample is not an event, then the resulting event
type is undefined.
This is fixed by always resetting the event type explicitely. Those
unknown events are also suppressed now and no longer delivered to the
application.
Allthough I haven't observed this bug with the Suunto Eon and Vyper,
they could be affected too.
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.
This adds a dump function for the ostc3 series computers. This function
dumps the whole external eprom, that contains the dive-headers and the
dive data.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
For the IQ-700, the existing code for the active gas mix always results
in an out-of-range gas mix index. The index of the active gas mix is
probably stored in another bit. As a temporary workaround, we simply
assume the active gas mix is always the first gas mix. This should
already produce correct results for dives with only single gas mix.
The Tusa IQ-700 is very similar to the other Seiko based models. The
most important change is that due the smaller amount of memory (8K vs
32K), the logbook entries are only 1 byte large instead of two bytes.
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.
