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
...
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>
The Mares Horizon is a variant of the Mares Genius, with a few changes
to support SCR dives:
The dive header is slightly modified. There is an extra 8 byte field at
offset 0x18, which causes all later fields to have moved up with the
same amount. This difference is indicated in both the object minor
version (with a change from v0.0 to v0.1), and the logformat.
For the profile data, there is a new SDPT sample type which contains a
bit more information compared to the existing DPRS sample type. This
difference is indicated with a change in the object type (from 0 to 1).
The current implementation assumes a fixed order for the record types (a
DSTR record, a TISS record, zero or more DPRS/SDPT records with an AIRS
record every 4 sample, and finally a DEND record), and either only DPRS
or SDPT records but never a mixture of the two. If these assumptions
turns out to be incorrect, the implementation will need to be changed
significantly. Note that the assumption of the fixed order was already
present for the Genius.
Bluetooth support is currently disabled in the Horizon firmware, but
might be re-enabled in the future.
The Sherwood Sage appears to be very similar to the Aeris A300CS. For
the BLE communication the handshake fails and is disabled.
Reported-By: Nick Shore <support@mac-dive.com>
Merge upstream libdivecomputer from Jef:
- support the Scubapro Aladin A2
- improve Cressi Goa support
- parse and report Oceanic firmware versions
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Report the firmware version in the devinfo event
Refactor the version string matching to use one table
Parse the firmware version
Add support for Cressi Goa gauge and freedives
Add the extra 5 bytes containing the divemode
Add a function to insert data anywhere in the buffer
Add support for the Scubapro Aladin A2
Just like for the Descent Mk1 this uses the internal Garmin model number (as
indicated in the FIT format) as model, not the USB product ID.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Merge upstrean libdivecomputer updates from Jef Driesen:
- a different way to work around the windows 'instance' craziness
- minor updates to the Shearwater parser
* git://github.com/libdivecomputer/libdivecomputer:
Add support for parsing info events
Add support for the Shearwater Peregrine
Fix a conflict with the Windows header files
Add a missing parameter for the USB HID filter
Merge upstream changes by Jef Driesen:
- add support for Liquivision dive computers
- add support for the Aqualung i470TC
- extract out Atomic Aquatics Cobalt USB support as a iostream
- misc fixes
* git://github.com/libdivecomputer/libdivecomputer:
Fix the OSTC4 firmware upgrade
Handle a negative number of bytes as an error
Update the example application
Use the new USB transport for the Atomic Aquatics Cobalt
Add an I/O implementation for USB communication
Add support for filter parameters
Disable direct access to the filter function
Increase the receive timeout to 5 seconds
Fix the McLean Extreme bluetooth name
Add support for Liquivision dive computers
Add support for the Aqualung i470TC
Replace the hardcoded libusb based code with the new USB I/O transport.
This enables the use of a custom I/O on platforms where libusb is not
available.
Replace the small helper function to retrieve the function pointer and
then call the function, with another helper function to call the filter
function directly. This way the function pointer doesn't need to be
exposed at all.
Add initial support for the Oceans S1.
This expands a bit on the generic functions for the field-cache code,
and uses that to then add a fairly minimal Oceans S1 downloader.
And while it's minimal, it downloads about everything the S1 offers,
which is mainly just depth and temperature.
There are a few fields that it currently doesn't use, notably the
events and NDL information that the dive computer presumably reports in
the auxiliary data that comes in the sample, but without documentation
and more testing I'm not comfortable parsing that.
There's also some "current dive computer state" that isn't imported,
like the battery status. I know how to read it, but it's not per-dive
data that could be added as extra fields: it's literally just the
current dive computer battery state at the time of the download.
The Oceans team said they'll provide more information about the
download, so this might be expanded in the future, but it seems fairly
usable even in this form.
Thanks to Dhaval Giani for sending me his Oceans S1 as a loaner, and to
Seth Garrison for doing the initial BLE packet dumps that made me think
it was fairly easily doable.
* Oceans-S1:
Oceans S1: polish up the downloading logic for usability
Oceans S1: actually download all dives and parse them
Oceans S1: fill out core download protocol details
Oceans S1: start filling in protocol details
Oceans S1: start documenting the download format and first packets
Add skeleton for Oceans S1 downloader
Add generic dc_field_get() helper
Merge upstream libdivecomputer updates from Jef Driesen:
- Jef merged the EON Steel dive sorting fix we had in our branch: one
less difference to upstream
- Jef merged the McLean Extreme support with some updates and cleanups,
this just takes all his changes.
- manual pages for iostream
- various minor fixes and updates from Jef
* git://github.com/libdivecomputer/libdivecomputer:
Update the gitignore file
Update the man pages for the new iostream functions
Purge the serial port buffer during initialization
Add support for the McLean Extreme
Suunto Eon Steel: sort the dive list properly
Remove the salinity compensation
Fix the hwOS ppO2 bug for firmware v3.08
Initial support for McLean Extreme
Signed-off by: David McLean Carron <david_de_carron@hotmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
They don't actually have any native BLE capabilities, but there's a "HAL
9000" docking station with bluetooth capability (and a USB cable for
wired connectivity).
This will need more work, the BLE communication is packetized
differently from the regular serial one. But I'm keeping this
difference from Jef's upstream for posterity.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There is also an i300C that is Bluetooth capable, but I don't know if
that's the same model as the i300 or a different variation.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This uses pretty much all of our new infrastructure: the USB storage
iostream for the actual IO, the field-cache for the divecomputer fields,
and the string interface for the events.
It's also a very fast downloader.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The bluetooth device filtering is based on the fact that the format of
the bluetooth device name is something like 'FQ001124', where the two
first letters are the ASCII representation of the model number (e.g.
'FQ' or 0x4651 for the i770R), and the six digits are the serial number.
Add the Shearwater Nerd 2 bluetooth device name.
The change to uppercase is purely cosmetic. The string comparisions are
not case-sensitive. But for documentation purposes it's good practice to
list the exact name as reported by the device.
It's exactly the same as the regular i200, but has a new version number
and string.
Tested-by: Tiago Thedim Dias <tiagotsoc@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Mares Genius supports a new command to download different types of
objects (e.g. dive header, dive profiles, etc) directly, without needing
to manually read and parse the contents of the flash memory.
The data structure also changed significantly. The profile data is now
organized into different records. Each record starts and ends with a 4
byte ascii marker:
DSTR: Dive start record
TISS: Tissue record
DPRS: Sample record
AIRS: Air integration record
DEND: Dive end record
and contains a CRC checksum. The contents of the records remains very
similar to the existing iconhd data format.
Based-on-code-by: Janice McLaughlin <janice@moremobilesoftware.com>
The main difference with the serial communication is that the BLE
communication uses data packets (with a maximum size of 20 bytes)
instead of a continuous data stream.
Occasionally, the device responds with an empty packet (with just the
ACK and EOF byte) or with a short packet where one or more payload bytes
are missing. The empty packet is most likely caused because the device
didn't receive the second part of the command (with the parameters) in
time. The missing bytes might be caused by a buffer overflow on the
Bluelink Pro, when the data from the dive computer arrives faster over
the serial link than the device can forward it over the slower bluetooth
link to the host system.
One way to address this problem is to lower the packet size from 256 bytes
to only 128 bytes. The main disadvantage is that this also impacts the
download speed considerably. In one particular example, the total
download time increased from about 135 to 210 seconds (which is already
slow compared to the 62 seconds the same download takes over usb)!
An alternative solution is to simply retry the failed command. That way
there is only a performance penalty for the few bad packets, and not for
every single packet. In the above example, only two packets needed a
retransmission.
Note that the iconhd communication protocol uses no checksums. Hence
it's not possible to detect corrupt data packets. Only short packets can
be detected, because they result in a timeout.
