The Log Upload RDBI (Read Data by Identifier) 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 0x90000000 format which is very
similar to PNF but without the final record and to use the older
Predator Like Format in that case.
The 0xDD000000 format is 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.
Which format we use is determined by the base address used to download
the logbook entries.
Signed-off-by: Dirk Hohndel <dirk@hohndel.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.
The low level serial and IrDA functions are modified to:
- Use the libdivecomputer namespace prefix.
- Return a more detailed status code instead of the zero on success and
negative on error return value. This will allow to return more
fine-grained error codes.
- The read and write functions have an additional output parameter to
return the actual number of bytes transferred. Since these functions
are not atomic, some data might still be transferred successfully if
an error occurs.
The dive computer backends are updated to use the new api.
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 new Petrel protocol uses a simple data compression scheme to reduce
the transfer times. The data is broken up into blocks of 32 bytes each.
Each block except the first is XOR'ed with the previous block, creating
large runs of zeros due to the similarity of the data. The zeros are
then run-length encoded (RLE) to save space.
This is done in preparation for the implementation of the new Petrel
protocol, which shares the low level communication with the existing
Predator protocol.
