The universal application works well, but is quite difficult to extend
with more functionality. Therefore a new and more modular application is
needed. The new dctool application will support multiple sub-commands,
to carry out specific actions. Extending the application will be as easy
as adding new commands.
To store the day (range 1 to 31) as a binary encoded value, only 5 bits
are required. The extra 6th bit is part of the year. The year is also
not BCD encoded. This happened to work by accident, because for a single
nibble, the current implementation of the bcd2dec() function returns the
binary value.
The new gasmix sample contains the index of the active gas mix.
This new sample is intended as a replacement for the existing gas change
events (SAMPLE_EVENT_GASCHANGE and SAMPLE_EVENT_GASCHANGE2). To maintain
backwards compatibility, the legacy events are marked as deprecated but
not removed yet.
In CC mode, only the diluents are stored in the header. The list with
the OC gas mixes, which are used for bailout, are not stored in the
header. In order to retrieve the bailout mixes too, we need to parse the
profile and add them to the manual gas mixes.
The protocol of the iX3M series is almost identical to the protocol of
the iDive series. The main difference is that the command bytes and the
size of the response packets have been changed. In order to be able to
communicate with the correct set of commands, the user needs to supply
the correct number now. To maintain backwards compatibility, a new
variant of the open function is added.
Apparantly Fedora applies a custom patch to glibc's tcsetattr()
function, which adds an extra check to verify the PARENB/CREAD/CSIZE
bits in the termios c_cflag field.
However, in commit 197b9f09421111e03588c94d55a72aa6ec624c63 we already
discovered that for pty's, some of the termios settings make no sense at
all, and therefore the Linux kernel always does:
tty->termios.c_cflag &= ~(CSIZE | PARENB);
tty->termios.c_cflag |= (CS8 | CREAD);
Thus, instead of ignoring such nonsense termios settings, the kernel
changes the termios structure to reflect what pty's actually do. The
consequence is that these settings will not stick, and cause the extra
check in the Fedora specific patch to fail.
To workaround this problem, we ignore the error when building
libdivecomputer with pty support enabled.
If the dive computer has not recorded any dives yet, the profile pointer
isn't valid and contains the default value 0xFFFFFFFF. There is no need
to return an error in this case.
In some rare cases, the initial gas mix contains the value 0xFF. This
value is obviously outside the expected range (1-5), and therefore
causes the parsing to fail. It's not really clear how this can happen.
As a workaround for the fatal error, we now ignore the invalid value and
simply proceed without a gas mix.
The dive computer records the raw absolute pressure. To convert this
pressure value into a depth, we need to divide by the salinity factor,
not multiply!
The GCC 5 compiler with -Wpedantic enabled generates warnings for the
non-standard predefined identifier __FUNCTION___. These warnings can be
avoided by using the C99 identifier __func__ instead.
The internal Uwatec tank id should be converted to the libdivecomputer
tank index. If there is no corresponding tank, the tank pressure samples
are dropped for the following reasons:
Some models appear to record an absolute tank pressure sample, even if
there is no pressure sensor attached to the corresponding tank. In this
case only the tank index changes. The sample value simply retains the
last pressure of the previous tank. Since we don't have any real
pressure data, dropping those samples is fine.
Dives are downloaded using bulk transfers with an 8K buffer. Normally
the 2 second timeout is more than sufficient, and the timeout should
never expire, unless there is some serious communcation problem. But
nevertheless, users are reporting timeouts for dives having a length
that is an exact multiple of the USB packet size (64 bytes). In that
case, libusb reports a timeout with an non-zero amount of bytes
received. Despite the timeout, the received data contains a complete
dive.
I suspect libusb is somehow unable to determine whether the transfer is
complete and therefore waits until the timeout expires. For transfers
that are not a multiple of the USB packet size, the end of the transfer
is indicated by the last incomplete packet. This is not the case if the
length is an exact multiple of the USB packet size. This problem is
usually solved by sending a zero-length packet. Maybe the USB stack of
the Cobalt is not sending such a zero-length packet?
Atomics will address the problem with a Coblat 2 firmware upgrade, that
will simply append two zero bytes if the length is a multiple of 64
bytes. As a workaround for older firmware versions, we ignore the
timeout and process all received data. This shouldn't have any
disadvantages. An incomplete dive, for example due to a real timeout,
will now be detected by means of the minimum length and/or the checksum.
The Mares Smart Apnea uses a different data format than the regular
Smart, because it records not only a summary of each freedive in the
session, but also a full depth profile.
Because both the regular Smart and the Smart Apnea have the same model
number (0x10), another way to distinguish the two variants is needed.
Therefore, the Smart Apnea gets a modified model number, with one of the
higher bit set. The actual type is detected from the contents of the
version packet.
The new Smart Apnea is also capable of recording multiple samples per
second (e.g. 2, 4 or 8). But since our smallest unit of time is one
second, we can't represent this, and the extra samples will get dropped
for now.
The Galileo Trimix supports up to 10 tanks and gas mixes. However, the
existing alarm based gas switch events have only 2 bits available, and
can support at most 4 gas mixes. Therefore, the trimix variant stores
another 4 bit value in the second alarm byte.
For the first three gas mixes (and possibly also the fourth), both alarm
bytes appear to be always set to the same value. For the higher mixes,
the value in the first alarm byte is always zero. This doesn't cause any
problems, because in the data stream the second alarm byte is stored
after the first one, and our final value is always the last one.
The non-trimix variant also has the second alarm byte, but the gas mix
bits appear to be always zero. In order to avoid taking this zero as the
final value, a separate table is used for the trimix variant.
The air integrated uwatec aladin models do record the total consumption,
and not the begin/end pressure. Returning the total consumption as the
begin pressure, combined with a zero end pressure is strictly speaking
not correct, but it still provides useful information.
Even if there are no O2 sensors connected (for example in auto or fixed
setpoint mode), the device records a ppO2 sample with all three values
set to zero. Such samples are now ignored, as if there was no ppO2
sample present.
Reported-by: Anton Lundin <glance@acc.umu.se>
The Atomics Cobalt backend uses libusb directly, without going through
an internal I/O layer that support logging. Therefore the logging needs
to be done in the backend itself.
The logbook ringbuffer starts at address 0x03E0 instead of 0x240. Since
none of the other models uses the same address, a completely new layout
structure is necessary.
The begin/end pressure for unused tanks is normally zero. But I noticed
that in some cases both pressure values are stored as 0xFFFF. Since that
corresponds to a pressure of 511.99 bar, this is most likely some
special magic value, and not a valid pressure.
Tanks where either the begin or end pressure is 0xFFFF are now ignored
too.
