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).
Currently all device descriptors are included, regardless of whether
the device is actually supported by the library. If IrDA or USB support
is unavailable, a dummy backend is build which will always fail with
DC_STATUS_UNSUPPORTED. Thus there is no point in listing those devices
as being supported. Doing so will only confuse end-users.
Although the communication protocol of the OSTC3 is nearly identical to
that of the Frog, the different size parameters make it hard to share
the code easily. On top of that, if we ever implement native bluetooth
communication support, we'll need a completely separate backend anyway.
Therefore the Frog backend is simply duplicated, with a few OSTC3
specific changes applied here and there.
The existing ostc parser is upgraded to support the new OSTC3 data
format.
The Frog stores the index of the initial gas mix at the same location
as the OSTC, but the gas mix percentages are at a different offset, and
the number of gas mixes is different too. Parsing all the gas mixes in
advance makes the code easier to read and more future proof.
With the layout descriptors, most hardcoded constants are now in a
central place, which will make it easier to add support for new data
format variants.
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.
Because the size of a dive isn't known in advance, we use the worst case
value of 0xFFFFFF (or nearly 16MB). However in practice, the real size
is many orders of magnitude smaller, even after the decompression.
Instead of pre-allocating a huge memory buffer, we now start with a much
smaller one, and increase when necessary.
For the predator and petrel manifests, where the size is known in
advance, we continue to pre-allocate the exact amount of memory as
before.
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).
The new Petrel protocol uses a simple data compression scheme to reduce
the transfer times. The data is broken up into blocks of 32 bytes each.
Each block except the first is XOR'ed with the previous block, creating
large runs of zeros due to the similarity of the data. The zeros are
then run-length encoded (RLE) to save space.
This is done in preparation for the implementation of the new Petrel
protocol, which shares the low level communication with the existing
Predator protocol.
With the new interface, an application can easily retrieve the
underlying transport type from the device descriptors and present a
custom user interface element to the end-user for supplying transport
specific parameters. For example the serial port for devices using
serial communcication.
For devices using a usb-serial chipset or the bluetooth Serial Port
Profile (SPP/rfcomm), the transport type is DC_TRANSPORT_SERIAL, because
internally the serial emulation layer is used for the communication.
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.
This is only a preliminary version. There is certainly some room for
improvement, but the basic functionality is already in place. That
should be sufficient for daily use, and possibles issues can always be
fixed when discovered.
After the new firmware upgrade, up to three gas mixes are available
instead of only two. This causes the parsing to fail because there is
now an extra 6 byte gasmix block in the header.
Unfortunately, we can't rely on the firmware version to detect whether
this extra gasmix is present or not. In theory the dive computer can
contain dives in both the old and the new format. Because the firmware
version is a property of the device, and not stored inside each dive,
using the firmware version would either cause the old or the new dives
to fail parsing. This appears to be the approach DM4 is using.
According to some sources on the internet, the logbook gets erased
during the firmware update. However, according to the memory dumps I
received, that appears to be incorrect. The old dives are still
present, and it seems it's only DM4 that fails to download them.
So we need an alternative solution. After a detailed analysis of all
the Suunto dives at my disposal, I noticed something interesting. The
first 5 bytes of each dive are almost static. There are only 5
different variations:
0061906216
0061A06216
0062909118
0062C07118
0063C07118
The interpretation of these bytes is currently unknown, but the second
byte might be some kind of data format version. Each model always has
the same value here, and for the D6i it changes after the firmware
update:
0x61: D4, D6, D9, Cobra 2, Cobra3, Vyper 2, Vyper Air
0x62: D4i, D6i (old firmware), D9tx, HelO2
0x63: D6i (new firmware)
This can't be coincidence, so we use this byte to detect the presence
of the extra gasmix.
The HelO2, D4i, D6i and D9tx all use the same data format for the gas
mixes. The only difference is the number of gas mixes and the initial
byte offset. With this knowledge, we can easily use the same code for
all models. An additional advantage is that because the profile
configuration data is stored immediately after the gasmix section, we
can also replace the hardcoded offset with a simple calculation.
This macro was used to compensate for the fact that the 4 bytes at the
start of each dive, containing the previous and next dive pointers, are
stripped. With the SKIP macro the byte offset remained the same as in
the documentation. Nowadays, this compatibility isn't necessary anymore
and it only makes interpreting the raw binary data more difficult.
The max depth is stored in imperial units (feet), and should be
converted into metric units (meter). But for some reason this unit
conversion was omitted.
Apparantly there are also two different type of serial numbers present,
and their interpretation depends on the application. The Windows Dive
Organizer application shows both a serial number (byte offset 0x04) and
a warranty number (byte offset 0x0C). However, the Mac OS X Divers'
Diary application shows the number at byte offset 0x0C as the serial
number. Very confusing. For now, we just stick to the number at byte
offset 0x0C, because that's the number that is shown by the device
itself.
The serial numbers were not decoded at all. The raw bytes where simply
converted into an arbitrary 32 bit integer. Now the serial number
matches the real serial number as shown by the device.
The Cobalt tracks only the NDL time in the samples. There are however
two indications when the dive changes into a decompression dive, but
they don't always occur at the same time and may or may not appear in
the same sample. The first indication is that the NDL time goes to zero
and the other is the first occurrence of the "deco schedule computed"
bit (0x02) in the violation byte of the sample.
As soon as the NDL time goes to zero, an attempt is made to generate a
deco schedule. Depending upon the algorithm used, a schedule may or may
not have any stops, even though the NDL time is zero. If the schedule
does generate deco stops, the deco schedule computed bit is set in the
violation byte of the sample. This bit is set each time a non-zero
schedule is computed. But because this bit is immediately cleared after
the sample has been stored, and only set again at the completion of the
next schedule computation, not every sample will have this bit set.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The Matrix uses the same communication protocol as the Nemo Wide 2,
except that the sending the request packets with just a single write
operation doesn't seem to work. That's very surprising because it
caused no problems for the Nemo Wide 2 or the Icon HD!
The first two bytes of each request packet are probably some kind of
command type. These two bytes are answerred immediately with an ACK
byte (0xAA). Once this ACK byte has been received, the payload of the
command (if any) can be sent, and finally the response packet can be
received.
I suspect that when trying to send the entire command at once, the
device somehow doesn't receive the payload bytes correctly. Maybe it's
still busy processing those first two bytes, which causes the remainder
of the packet to get dropped? That might explain why the version
commands is not affected, because it doesn't have any payload bytes!
The application shouldn't have to deal with the delay between packets.
If the default value isn't good enough, that should be fixed internally
and not on the application side.
The second gas change event (type 0x06) contains both the oxygen and
helium percentages. These are now reported correctly with the new
GASCHANGE2 event.
The D9 family has begin and end of the deco event and we can therefore
convert this to the deco sample. For compatibility with existing software
we keep the events around.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The SAFETYSTOP is conceptually somewhere in between the NDL and the
DECOSTOP, so it makes sense to re-order the constants in the enum to
reflect this order.
These are based on the documentation we have and have been tested and
verified against actual dive data (with the exception of the pO2 and
ascent speed violations).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Two issues:
- the OSTC counts its gases 1-based, not 0-based
- dives don't always start with the first gas. Simply create a gas change
event right after the first time sample that informs the application what
the first gas mix is
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The version.h header file is generated by autoconf and therefore
located in the build directory and not the source directory. If
building out-of-tree, and a version.h header file is accidentally
present in the source tree, the wrong file will be picked up.
By reversing the order of the include directories, the build directory
is searched first, and the correct header file will be used.
For bug reports it's very convenient to know the exact version. For
release builds, the standard version triplet (major.minor.micro) is
more than sufficient, but that's not the case for development builds.
Due to the post-release version increment, development builds already
have a version number that is distinct from previous releases, but
including the git commit SHA1 is even more accurate.
On Windows, the git commit SHA1 is also embedded in the version
resource.
The new vendor event provides a mechanism to deliver auxiliary data,
which is automatically retrieved during the data transfer, but not
accessible through the library interface otherwise. Possible examples
include handshake data and/or device identification data.
This event is mainly intended for diagnostic purposes, in combination
with the memory dumping support. Very few applications will actually
need it for anything else.
If the first attempt fails, that might indicate the device isn't ready
yet to service requests. In that case immediately retrying again isn't
the right solution. Adding a small delay seems to increase the success
rate, so it's a good idea anyway, regardless of the underlying reason.
