Merge upstream libdivecomputer updates by Jef Driesen.
Minor fixups, and add ID for Cressi Neon.
* git://github.com/libdivecomputer/libdivecomputer:
Add support for the Cressi Neon
Use symbolic constant for invalid value
Remove duplicate macro definition
Add BLE support for the Aqualung i750TC
Exclude the surface time from the dive time
I verified that the unsigned integer in the devinfo header actually matches the
serial number shown in the "About" dialog on the device - so let's add this as
extra data string and make it user visible (and also allow Mares Icon HD style
devices to be reliably distinguished in Subsurface).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I verified that the unsigned integer in the devinfo header actually matches the
serial number printed on the device - so let's add this as extra data string
and make it user visible (and also allow Suunto Vyper style devices to be
reliably distinguished in Subsurface).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It seems that Suunto extended the gas change information in FW 2.5, and
added events and fields for when you create and delete gas mixes under
water.
The parses the relevant new information to get gas switches working
again, and to also add the information about gas creation and deletion
events.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Merge upstream libdivecomputer updates by Jef Driesen:
- fix HW Sport and Mares Genius firmware update
- Windows Visual Studio build updates
- Various parser updates:
- sporasub depth, salinity and sample rate parsing
- Atomics Cobalt atmospheric pressure parsing
- unit cleanups (Uwatec, McLean Extreme)
* git://github.com/libdivecomputer/libdivecomputer:
Some more fixes for the new Mares Genius firmware
Implement the salinity field
Fix the sample rate parsing
Add support for the new Mares Genius firmware
Use the correct standard gravity factor
Use SI units internally
Fix negative depth values
Move the unit conversion to the last moment
Implement the atmospheric pressure field
Always use the stored atmospheric pressure
Add a CI job to build with Visual Studio
Migrate to Visual Studio 2013 (or newer)
Emit events when downloading a memory dump
Fix the depth decoding
Add library dependencies in windows build
Fix the hwOS Sport firmware upgrade
Post release version bump to 0.8.0
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.
We explicitly check that field for 0 before dereferencing it. Let's make sure
that it always starts out being 0 - otherwise we'll get a potential crash here.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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.
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>
Update to the v0.7.0 release.
Only a couple of trivial changes from the last development version we merged with:
- add new product ID for the Sherwood Amphos 2.0
- make the example app use the product name and not vendor name for the
McLean Extrme
* tag 'v0.7.0':
Release version 0.7.0
Use the product name as the family name
Add support for the Sherwood Amphos 2.0
Merge upstream updates from Jef:
- add suppoort for various new variants of existing dive computers:
+ Suunto Eon Steel Black, and new variant of Zoop Novo
+ Sherwood Beacon
+ new Shearwater Perdix AI model number
- add new Sporasub SP2 support
- various minor fixes and updates
* 'master' of git://github.com/libdivecomputer/libdivecomputer: (22 commits)
Add support for a new Suunto Zoop Novo variant
Add support for the EON Steel Black
Add support for the Sporasub SP2
Fix an overflow in the progress events
Use a common sleep implementation
Fix the clang compiler flag detection
Add Github Actions CI builds and releases
Show a summary after configuration
Extend the OS detection to non Windows platforms
Implement the ndl/deco sample
Fix the maximum depth
Mark the McLean Extreme as supporting BLE
Fix -Wcast-qual compiler warning
Mark the new iX3M 2021 models as supporting BLE
Add support for the Sherwood Beacon
Remove the infinite timeout
Simplify the loop for reading the packet header
Add a new Perdix AI hardware type
Fix the McLean Extreme fingerprint feature
Perform the check for the NULL key earlier
...
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 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.
Dirk got a log from Amin that shows
Discovered new device: "EZ001945" "LE:{cb0ff33a-40d3-63eb-2764-11e63896534f}"
Not recognized as dive computer
and that's the i750TC device model name. It's not recognized as a dive
computer because subsurface don't have that EZ as a model version, but
even if it did, it would not try to use BLE to download because
libdivecomputer doesn't mark it as BLE capable.
But it appears that it is, so add the protocol marker (even if the log
Dirk has then shows a failure to connect, so not all is well).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge with Jef's upstream libdivecomputer updates:
- support new Ratio iX3M 2021 model IDs
- support Mares Horizon, and fix the Mares Genius layout
- add support for Shearwood Sage
- various warning fixes, other minor details
* 'master' of git://github.com/libdivecomputer/libdivecomputer: (23 commits)
Wait before sending the firmware data
Add support for the new iX3M 2021 models
Avoid generating the SIGPIPE signal
Use an unsigned value to represent the undefined state
Use an unsigned integer for the number of dives
Use the cross-platform socket file descriptor type
Limit the size to INT_MAX
Define DC_TIMEZONE_NONE as a signed integer
Use an unsigned integer for the length
Fix -Wsign-compare compiler warnings
Fix -Wshadow compiler warnings
Fix -Wcast-qual compiler warning
Fix -Wswitch compiler warning
Remove unused variables
Implement the rbt sample
Use some more descriptive variable names
Verify the oxygen and helium percentage
Add support for the Mares Horizon
Swap the object major and minor version
Fix the Mares Genius memory layout
...
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.
