Like most dive commputers, the Mares Genius uses a surface timeout to
detect the end of the dive. But since there is no explicit dive time
field stored, the total dive time is based on the number of samples,
which includes this surface time at the end of the dive. However, the
dive time displayed by the dive computer (and also the Mares
DiveOrganizer application) does not include this surface time.
For older firmware versions the value is hardcoded to 3 minutes, but
starting with the newer v01.02.00 firmware the value is configurable and
stored in the settings. To detect whether the setting is available, we
need to check the profile version instead of the header version. That's
because the header appears to be generated on-the-fly during the
download, and thus the header version also changes for dives recorded
prior to the firmware update.
For all other models, also take into account a hardcoded timeout of 3
minutes.
The changes in commit 5cb527d53ca88ac692beb55288172fc1003975fa to
support the new Mares Genius firmware v01.02.00 were incomplete.
For dives recorded prior to the firmware upgrade, only the header
version changed from 0.0 to 1.1, while the profile version remained the
same. But for dives recorded after the firmware upgrade, the profile
version also changed from 0.2 to 1.0.
The known header and profile object versions (indicated as
type.major.minor) are now:
Model | Firmware | Header | Profile
========|==========|========|=========
Genius | 1.0.x | 1.0.0 | 0.0.2
Genius | 1.2.0 | 1.1.1 | 0.1.0
Horizon | 1.7.28 | 1.0.1 | 1.0.2
To simplify the object version check, all versions below a certain upper
limit are now considered supported.
The byte at offset 0x1A appears to be some settings byte, containing not
only the sample rate index, but also some other values in the higher
bits. Except for the 4th bit, which contains the salinity setting, the
meaning of those higher bits remains unknown. Since the sample rate is
limited to only 4 possible values, 2 bits are sufficient for encoding
the sample rate index. The 3th bit might contain some other setting, or
be reserved for future sample rates.
The new Mares Genius firmware v01.02.00 has a header which is 10 bytes
larger. This difference is indicated with a change in the major version
from 0 to 1.
For manual depth calculations by divers, the standard gravity is
often approximated as 10.0 (e.g. 1 bar corresponds to 10 meter), but
libdivecomputer prefers to use the exact value of 9.80665 m/s².
For the McLean Extreme, it has been confirmed that the device also uses
the correct standard gravity internally for the conversion of the sample
depth.
Prefer SI units for internal constants (e.g. density) and calculations.
This results in more consistent conversion formulas across the different
backends.
For the Uwatec backend, this changes makes it also much more visible
that the unit for the depth is either 1 millibar (maximum depth) or 2
millibar (sample depth).
The difference between two unsigned integers can be negative. To avoid
ending up with some very large positive values, an explicit cast to a
signed integer is required.
Depths are normally expected to be always positive, but near the surface
the pressure will be very close to the atmospheric pressure. Therefore
small negative values are not unusual.
Processing the data in device units, and performing the unit conversion
only at the very last moment, avoids the need for intermediate floating
point math and thus possible rounding errors. In practice this is not
really an important issue, except for some case where a negative zero
value was returned.
The migration to Visual Studio 2013 allows to build the Visual Studio
project in a Github Action.
Because some of the source files (e.g. the resource script and version
header) are normally auto-generated by the autotools build system, an
msys environment is setup to run the configure script. When building
from a distribution tarball, this extra step isn't necessary.
Starting with msvc 2013, the C compiler has much better C99 support. The
previous workaround to compile everything as C++ code is no longer
needed.
Some additional changes:
- Add a 64bit build
- Enable _CRT_SECURE_NO_WARNINGS to silence warnings
With just 12 bits, the depth values are limited to at most 40.95m.
However for some deeper dives, this appears to be wrong. The next two
higher bits, which were previously unknown, are also part of the depth.
This increases the maximum depth to 163.83m.
Support for the S_BLOCK_WRITE2 command is only available since the hwOS
Tech firmware v3.09 and the hwOS Sport firmware v10.64. In commit
9e92381be48866f3f13a11e98d59962575bb5ad3 it was enabled for all firmware
versions newer than v3.09, causing the firmware upgrade to fail for
older hwOS Sport firmware versions.
Reported-by: Anton Lundin <glance@acc.umu.se>
The Sporasub SP2 uses a very simple communication protocol and memory
layout, but with some unusual aspects:
Dives are artifically limited to a maximum of 6000 samples.
Unlike all other dive computers, the dives are not stored in some kind
of ringbuffer structure. Once the memory is full, no new dives can be
recorded. The existing dives need to be erased first, and the dive
computer will start recording again at te start of the memory area. The
Sporasub application has an "Auto-clear watch memory after data
transfer" feature for this purpose.
I didn't implement a more efficient download algorithm because
downloading a full memory dumps takes less than 10 seconds.
The maximum value for the progress events is based on the amount of the
flash memory available for storing the dives. But the 8 byte serial
number is not stored inside the dive data, and is added dynamically
during the data transfer. This extra data needs to be taken into account
to avoid overflowing the progress events and trigger an assert in the
code.
The clang compiler accepts *any* compiler flags, and just reports
an annoying warning instead:
warning: unknown warning option '-Wsomething' [-Wunknown-warning-option]
Use -Werror=unknown-warning-option to change this warning into an error,
and detect the unsupported flag. Since this is a clang specific option,
it can't be used unconditionally with other compilers. The option is
also only used for checking the compiler flags, and not for compiling
the code.
The new Github Actions offers similar functionality as the Travis CI
integration, but with some interesting extra features:
The build action is almost equivalent to the existing Travis build
configuration. But as an extra feature, the build artifacts are now
available for download.
The release action does automatically build a distribution tarball and
create a Github release, whenever a new version is tagged and pushed.
The upper bits appear to contain some other (currently unknown)
information. The Oceanic VT Pro specifications list a maximum depth of
399 ft (120 m), which requires only 9 bits. The Oceanic application also
ignores the higher bits.
The McLean Extreme uses a dual stack Bluetooth module from Microchip
which supports both Bluetooth Classic and Low Energy.
Reported-by: David Carron <david_de_carron@hotmail.com>
The CBC initialization vector is passed as a const pointer, and then
cast to a non-const pointer to store it in the aes state struct. This
cast can easily be avoided by changing the struct field into a const
pointer.
The new iX3M 2021 models with bluetooth do support BLE communication.
Bluetooth Classic (rfcomm), which was the only supported bluetooth
variant in the previous models, is not available.
When an Uwatec Aladin is connected, but the transfer hasn't been started
yet, we receive a continuous stream of zero bytes. Approximately every
7-8ms a new zero byte is received. But when the dive computer is
(temporary) disconnected, the stream of zero bytes also ends.
The consequence is that due to the use of blocking read call with an
infinite timeout, the application becomes unresponsive, without any
chance to abort the communication. This can eaily be avoided by using a
timeout instead. Receiving the main 2048 byte packet takes about 1050ms.
Thus a 3000ms timeout should be long enough to not cause the main data
transfer to timeout, but still short enough to cancel reasonable fast.
The for loop construct without an increment statement is a bit unusual
and thus easy to miss. With an equivalent while loop, the intent becomes
a bit more obvious.
Currently the fingerprint feature uses the first 7 bytes of the computer
configuration data. Since this information does not uniquely identify a
dive, and is actually often identical for several dives, no new dives
are detected anymore. Fixed by using the date/time timestamp at the
start of the dive configuration data instead.
Reported-by: David Carron <david_de_carron@hotmail.com>
The previous commit added a check for a NULL key inside the filter
functions, but it's more efficient to handle it early on, before even
calling the filter function.
An example where the filter functions can be called with a NULL key is
when a bluetooth discovery fails to retrieve the name of the remote
device. In such case, we have no information to detect whether the
bluetooth device matches a known dive computer or not, and thus it
shouldn't be filtered out.
The matching functions expect a pointer to the value as argument, and
not the value itself. Since a C string is already a pointer (to a NULL
terminated character array), an extra pointer indirection is required.
Without the small delay, sending the first frame often fails. Trying to
read the ACK response byte just fails with a timeout, and no data is
received at all. The bootloader is probably not ready to receive data
yet.
The new iX3M 2021 models (refered to as 'iX3M with Sequared Buttons' in
the Ratio support section) identify as iX5M in the Bluetooth name.
Reported-by: Damian Zaremba <damian@damianzaremba.co.uk>
Handling the SIGPIPE signal in a library is tricky, because installing a
signal handler does affects the entire application. But we can at least
try to avoid generating the SIGPIPE signal ourselves. On Linux, that
requires the use of the MSG_NOSIGNAL flag, and on Mac and BSD setting
the SO_NOSIGPIPE socket option.
