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.
Because the dive_count variable is decremented, it doesn't contain the
total number of dives, but the index of the last dive. A negative number
indicates no dives. The same result can be obtained by using the total
number of dives directly. That's not only more intuitive, but also fixes
a -Wsign-compare compiler warning.
Windows and unix use a diferent data type for representing socket file
descriptors (SOCKET vs int). This mismatch results in a compiler warning
when comparing to S_INVALID.
Allthough the input buffer size has type 'size_t', the return value of
the function has only type 'int'. Hence the function can't support input
buffers larger than INT_MAX.
This allows to fix a -Wsign-compare compiler warning: operand of ?:
changes signedness from ‘int’ to ‘size_t’ due to unsignedness of other
operand.
The hexadecimal value 0x80000000 is too large to be represented as a
signed 32bit integer. Therefore the default type for the constant is an
unsigned 32bit integer. This is a bit annoying because the timezone
field is actually defined as a signed integer, and thus comparisions
produce -Wsign-compare compiler warnings.
Fixed by switching to INT_MIN, which is the same underlying value but
interpreted as a signed integer.
Comparing signed and unsigned integer expressions can have unexpected
results because the signed integer will get promoted to an unsigned
integer. To avoid the warning, add an explicit cast to the unsigned
type, along with a check to catch negative values.
