I misunderstood the way the helper function worked. Thanks Jef for
pointing it out. The way I wrote the code we ended up doing undefined
shifts which explains why the data I got back seemed so random.
With this we should be able to simply act on the four known values for
the base address, with 0xDD000000 never an option by the time you got
here - but in the old code (prior to the PNF addition) we would have
fallen back to 0xC0000000, so let's do the same here.
Any other value is actually an unknown format and should be treated as
such.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
As Jef correctly points out, RDBI actually stands for Read Data by
Identifier, and the correct identifier here is Log Upload.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Merge Dirk's Shearwater Teric branch.
The Teric only supports Shearwater's new download format (PFN - Petrel
Native Format), and the old legacy format no longer works.
I'm sure there are issues, and Dirk just ended up ignoring an
unexplained format difference on Android, but without this you get
nothing.
[ Fixed up a format warning in the merge commit - Linus ]
* 'teric' of git://github.com/Subsurface-divelog/libdc:
Shearwater PNF support: fall back to default logbook style
Shearwater: report error when parsing freedive
Shearwater: add Teric to list of supported dive computers
Shearwater: try to gracefully shut down the Bluetooth connection
Shearwater: add helper to send bytes to the dive computer
Shearwater Petrel Native Format parsing
Shearwater: use the correct address to download dives
Shearwater: detect which logbook format is support
Detect Sherwater Teric
Shearwater: skip deleted dives
On Android we appear to mis-interpret the response to the RDBI command.
Instead of failing, fall back to the default value (PNF for Teric,
Predator-like for everything else).
With this I can successfully download dive data from my Teric on
Android.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
RDBI response tells us which format the dive computer supports.
Shearwater recommends to use the 'Petrel Native Format' for all dive computers
which support it, even those pre-Teric models which (depending on firmware)
might support both PNF and the older 'Predator-Like Format'.
They also recommend to ignore the 0x90...... format which is very similar to
PNF but without the final record and to use the older Predator Like Format in
that case.
Which format we use is determined by the base address used to download the
logbook entries.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Dirk seems to have some documentation about the different ID's, plus it
just makes sense to order the switch statement by number.
This is partly based on Dirk's original commit to do the different model
numbers, with various changes over time due to merge conflict
resolution. Dirk's sign-off comes from Dirks commit in the original
subsurface branch.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently the dive computer backends are responsible for opening (and
closing) the underlying I/O stream internally. The consequence is that
each backend is hardwired to a specific transport type (e.g. serial,
irda or usbhid). In order to remove this dependency and support more
than one transport type in the same backend, the opening (and closing)
of the I/O stream is moved to the application.
The dc_device_open() function is modified to accept a pointer to the I/O
stream, instead of a string with the device node (which only makes sense
for serial communication). The dive computer backends only depend on the
common I/O interface.
Unlike the Shearwater Petrel, the Shearwater Nerd 2 appears to have a
distinct model number from the Nerd.
Reported-by: Janice McLaughlin <janice@moremobilesoftware.com>
At the moment the progress events are reported for each download
operation separately. Combined with the fact that the size of the dives
isn't known in advance, and thus the progress events are based on a
worst case value, the user experience is far from optimal. In practice,
the progress goes from 0 to 100% for every manifest, and it stays close
to zero while downloading the dives.
This is improved by combining the individual progress events into a
single progress for the entire download. This global progress simply
counts the number of individual download operations. Since each
operation is now subdivided into a fixed number of steps, regardless of
the size of the transfer, the perceived speed is no longer constant.
The model number is stored in the final block of each dive. But for an
efficient implementation of the fingerprint feature, the devinfo event
should be emitted before downloading the manifests or the dives. Thus
reporting the correct model number is problematic.
Currently the model number is simply hardcoded to the value of the
Petrel. This is sufficient for the parser, because there the model
number is only used to distinguish the Predator from all the other
models. Now, because the petrel backend doesn't support the Predator,
and the predator backend (which supports both the Predator and Petrel)
can obtain the correct model number from the final block, the hardcoded
value works fine. Except of course for identifying the actual model!
Allthough there doesn't seems to be a command to retrieve the model
number directly, we can retrieve the hardware type and map that to the
model number.
Being able to synchronize the dive computer clock with the host system
is a very useful feature. Add the infrastructure to support this feature
through the public api.
The vendor_product_parser_create() and vendor_product_device_open()
functions should be called indirectly, through the generic
dc_device_open() and dc_parser_new() functions. And the
vendor_product_extract_dives() functions are internal functions that
should never have been part of the public api in the first place.
Both the allocation and initialization of the object data structure is
now moved to a single function. The corresponding deallocation function
is intended to free objects that have been allocated, but are not fully
initialized yet. The public cleanup function shouldn't be used in such
case, because it may try to release resources that haven't been
initialized yet.
Instead of freeing the object data structure in the backend specific
cleanup function, the memory is now freed automatically in the base
class function. This reduces the amount of boilerplate code in the
backends. Backends that don't allocate any additional resources, do no
longer require a cleanup function at all.
The firmware version and serial number are stored in the final block
of each dive. That makes it very tricky to support the devinfo event
correctly. For an efficient implementation of the fingerprint feature,
the devinfo event should be emitted before downloading the manifests
or the dives. Fortunately it turns out it is actually possible to
retrieve the firmware version and serial number independently, using
the special identifier command.
A shutdown command should be send to the device, before the connection
is actually closed. In the absence of this command, the device will
display an error, even if the data transfer itself was successful!
The Petrel (with updated firmware) supports an enhanced communication
protocol, which is more efficient and powerfull than the legacy Predator
compatibility mode. The new protocol uses data compression for faster
transfers and supports the ability to selectively download individual
dives. Last but not least, the new protocol isn't limited to the last
128kB of logbook data, but can access the full logbook capacity (16MB).
