We do this for a few other device where we need slightly different behavior,
depending on the specific model.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With just a single table, the version string matching not only becomes
simpler, but adding new layouts also requires no code changes anymore.
For devices that need different layouts depending on the firmware
version (e.g. Oceanic Atom 2.0 and Aeris Manta), the table may contain
multiple entries with the different firmware versions. The only
requirement is that the entry with the highest firmware version must be
listed first.
The patterns used for the version string have the firmware version
masked out because it varies. We can re-use those masks to extract the
firmware version.
The gauge and freedives have a slightly different data format compared
to scuba dives. The main difference is the size of the header and two
new sample types.
The logbook header has 5 bytes extra, which are not present in the dive
header. Those 5 extra bytes contain the dive mode, which is required for
parsing the dive data. Therefore, insert all 5 bytes again and update
the parser.
The remaining 4 bytes appear to be some 32 bit address. They are not
used for anything right now, but are preserved as well in case they are
needed in the future.
The memory buffer already supported appending and prepending data, but
not inserting data anywhere in the buffer. That's exactly what the new
function does. The free space is still maintained at either the start or
the end of the buffer.
This actually got broken long ago (and before the new "Subsurface-DS9"
branch: when I converted the Garmin parser to use the generic field
cache, I missed the fact that the parser now cleared _only_ that generic
part of the per-dive cache in between different dives.
The GPS information, and the general dive information would be left
alone in between dives, and could leak from one dive to the next.
Most of the time you don't notice, because dives tend to all have the
same information, so the stale data would get overwritten when parsing
the next dive. But that isn't _always_ true - particularly for the GPS
information, not all the data necessarily always exists.
So clear all the per-dive data when starting to parse a new dive.
This puts the non-gps data all in one sub-structure, so that it's easy
to clear that too in one go - even though that part of the data probably
always does get opverwritten by the new dive data.
Reported-by: @brysconsulting
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge updates from Jef's upstream branch.
Fix Mares Genius salinity parsing, and a possible buffer overflow in the
Liquivision Lynx parser.
This also has Jef's copy of Dirk's Shearwater PNF parsing fix that we
already had in our tree.
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Fix a buffer overflow
fix Shearwater PNF parsing for Petrel / Petrel 2
Fix a bug in the salt and fresh water parsing
The existing check accepts the number of array elements as a valid
index. That's clearly wrong for zero based indexing, and would result in
a buffer overflow.
At some point (possibly around v71 of their firmware), Shearwater implemented
PNF for the Petrel and Petrel 2. Those are of course not air integrated, and
apparently don't support adjustable sample rate, so the log data doesn't include
opening and closing record 5. Instead of failing when those aren't found, we
should simply only access those when they actually exist.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Pull Shearwater PNF parsing fix from Dirk:
"The parser assumed that all opening/closing records were required.
But it seems that for the Petrel / Petrel 2 they actually aren't,
specifically record 5 is missing.
Which makes sense, as that one only contains air integration stuff
plus the sample interval (which isn't configurable on the older dive
computers)"
* 'shearwaterPNFfix' of github.com:Subsurface-divelog/libdc:
fix Shearwater PNF parsing for Petrel / Petrel 2
At some point (possibly around v71 of their firmware), Shearwater implemented
PNF for the Petrel and Petrel 2. Those are of course not air integrated, and
apparently don't support adjustable sample rate, so the log data doesn't include
opening and closing record 5. Instead of failing when those aren't found, we
should simply only access those when they actually exist.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The original Mares Genius support was based on Mares Dive Organizer
2.25, which has a bug in the salinity parsing. The latest version 2.26
has this bug fixed.
Reported-by: Greg McLaughlin <gregm@somemore.com>
Pull McLean Extreme fix from Jef Driesen.
The McLean Extreme sample interval was wrong, causing imported dives to
appear twice as long as long as they should.
* git://github.com/libdivecomputer/libdivecomputer:
Fix the sample interval
The McLean Extreme records a sample every 10 seconds instead of every 20
seconds. This resulted in dive durations that were twice as long as
expected.
Reported-by: David Carron <david_de_carron@hotmail.com>
This mostly reverts commit cb7f47b ("Shearwater Teric: add support for
the TAG INFO_EVENT") because upstream libdivecomputer now does this
natively as of commit 3e89e1b ("Add support for parsing info events").
Also, the way this had been done, it looks like it had basically
disabled the support for LOG_RECORD_FREEDIVE_SAMPLE, although nobody
seems to have ever complained, so presumably there aren't a lot of
freedivers using Shearwater dive computers and subsurface.
With this, our main differences with Jef are just the string interface
code, and the fact that we still stop parsing at LOG_RECORD_FINAL.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge Dirk's Peregrine support with Jef's.
Jef had some extra logic, and otherwise the same, so this is just a
history merge with no content difference.
* 'Subsurface-DS9' of github.com:Subsurface-divelog/libdc:
Add basic detection for Shearwater Peregrine
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
In one of the Windows system header files, an "interface" macro is
defined as:
#define interface struct
This results in some very strange build errors when also including the
descriptor-private.h header file. That's because the dc_usb_params_t
struct has a member field named "interface":
typedef struct dc_usb_params_t {
unsigned int interface;
unsigned char endpoint_in;
unsigned char endpoint_out;
} dc_usb_params_t;
As a workaround, define the WIN32_LEAN_AND_MEAN macro before including
the windows.h header file. This excludes some less common Windows API
declarations, including the above one.
In commit 57f0ce6d7902117cfc4d0d6b401b516fc93ca488, an extra parameter
was added to the dc_descriptor_filter() function. But I only updated the
libusb code path and forgot to do the same for the hidapi variant.
It turns out that Windows is more of a PoC than I ever imagined. The
system headers will have something like this in it:
#define __STRUCT__ struct
#define interface __STRUCT__
which means that using the identifier "interface" will result in
completely indecipherable error messages from a Windows compiler.
That's some truly broken stinking garbage. It's not like "interface" is
even a bad identifier.
Let's just #undef this crazy feature.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When Jef added a filter parameter in commit 57f0ce6 ("Add support for
filter parameters") he didn't do the HIDAPI case, because who uses
HIDAPI?
Windows and OS X, it would seem.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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
Commit d1b865d192afc9efde337b5cff8a239366f15565 breaks the OSTC4
firmware upgrade because the OSTC4 expects to receive the service init
command and the service key all at once, before sending any response.
The hwOS firmware still reads the service init command one byte at a
time, and sends the echo immediately after each byte. But in the
meantime, the hwos firmware has also been optimized. The processing time
for an incoming byte is now always faster then the time it takes for the
next byte to physically arrive via the serial line between the USB/BT
chip and the processor. Thus, even without any buffering, sending all
bytes at once should no longer be a problem.
This partially reverts commit d1b865d192afc9efde337b5cff8a239366f15565.
Reported-by: Anton Lundin <glance@acc.umu.se>
Suggested-by: Ralph Lembcke <mail@ralph-lembcke.de>
There is no reason for libusb to ever return a negative number of bytes,
but due to the use of a signed integer, it's technically possible. And
because libdivecomputer returns an unsigned integer, such a negative
number would be reported as a very large size.
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.
The USB communication is now also implemented as an I/O stream
transport. Unlike most I/O devices, USB communication supports multiple
interfaces and endpoints. This requires some some special care:
In the general case, autodetection isn't really possible without
additional knowledge. Hence the need for the filter parameters to pass
this kind of information.
The implementation assumes two bulk endpoints for the standard
read/write interface. Communication with the control endpoint is
supported through the new DC_IOCTL_USB_CONTROL_{READ,WRITE} ioctl's.
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.
When the fingerprint feature isn't used (or with a timestamp of zero),
the response to the SIZE (0xC6) and DATA (0xC4) commands is received
almost instantly:
[0.302704] W: C60000000010270000
[0.366727] R: DCF90F00
[0.367829] W: C40000000010270000
[0.394812] R: E0F90F00
But when the fingerprint feature is used (with a non-zero timestamp),
there is a noticable delay:
[0.341218] W: C64CEB204D10270000
[1.927905] R: FE0B0000
[1.931610] W: C44CEB204D10270000
[5.092081] R: 020C0000
In this particular case, the total amount of dive data was close to 1M
bytes, which pushed the delay over the 3 second timeout, and caused the
download to fail. Increasing the timeout to 5 seconds fixed the problem.
The most likely explanation is that the dive computer needs to scan its
internal logbook to determine which dives and how many bytes to send.
Because that involves reading relative slow flash memory, this can take
up to a few seconds, especially if there are many dives present.
The duration of the delay also depends on the value of the fingerprint
timestamp: the less dives we try to download, the longer the delay! I
suspect that's because the most recent dives are located near the end of
the logbook. Hence, the less dives we request, the more dives the dive
computer needs to skip.
Below are some timings for downloading espectively 792410, 531856 and
270850 bytes from the same dive computer, but with a different
fingerprint value:
[0.216305] W: C6F8D5C84510270000
[0.373511] R: 56170C00
[0.378929] W: C4F8D5C84510270000
[0.661388] R: 5A170C00
[0.236246] W: C620D80F4810270000
[0.559608] R: 8C1D0800
[0.563755] W: C420D80F4810270000
[1.171631] R: 901D0800
[0.246193] W: C654E6434A10270000
[0.826365] R: FE210400
[0.831760] W: C454E6434A10270000
[1.974351] R: 02220400
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
This adds a few finishing touches to actually download dives in the
expected order (newest first), which fixes the handling of already
downloaded dives.
It also adds the fingerprinting code to optimize the downloading a bit.
Finally, it handles cancellation in the middle.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This isn't perfect - we don't do the whole dive fingerprint etc, so
right now it always downloads all dives.
To make matters worse, it downloads dives oldest first, which then
confuses the subsurface downloader that expects newest first.
So there's stuff to clean up, but the basic profile data is all there.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
All of the Oceans S1 protocol seems to be basically ASCII data, but the
bigger chunks of data (the dive list, and the actual dive profiles) are
chunked in 512-byte pieces with sequence numbers and what looks like
some checksum.
This doesn't check the checksum yet, but the basic "download data" seems
to work.
Note that the code doesn't actually _parse_ said data yet, nor create an
actual dive list. So this is very much only very incremental progress,
but this seems to have been the nastiest part of the actual protocol.
Knock wood.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
