Merge with upstream libdivecomputer from Jef:
- Jef merged my Scubapro G2 work, but renamed everything, and didn't
get the newer IO model code. Very annoying.
I went along with changing the G2 model family name to
DC_FAMILY_UWATEC_G2 just to keep some of the basic infrastructure
more easily mergeable. But his uwatec_g2 version is not usable.
- Cochran updates from John Van Ostrand
- Misc improvements from Jef:
* divesystems idive improvements
* Oceanic OCS freedive mode
* ppO2 callback cleanup
- Some transport type work:
* changes to IRDA configuration
* basic bluetooth rfcomm transport mode
* 'master' of git://git.libdivecomputer.org/libdivecomputer: (35 commits)
Removed unused code
Fixed duplicate gasmix event reports
Added decompression event handling for the Commander
Fix bad profiles when profile ringbuffer wraps around
Changed cochran_comander_profile_size function parameters
Fixed location and encoding of Commander II pointers
Use a local variable for the layout pointer
Add new EMC device model string
Add support for Pre-21000 s/n Commander dive computers
Fix problems with wrapped logbook ringbuffer
Retry read operations on failure
Change profile download to be incremental
Fix the id string offset
Fix the progress events
Use the trimix data format
Use the correct model number
Enable more fine grained progress events
Abort with an error if the buffer is too small
Use the standard libdivecomputer error codes
Scubapro G2: add missed command packet logging
...
And remove the nasty and disgusting transmitter data handling code that
Dirk added to work around his misunderstanding of the parsing code.
This code now collects the various states of the transmitter batteries
throughout a dive and reports the most meaningful summary in the end. It
also rewrites the rest of the string handling code to be architecturally
cleaner.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The syntax is trivial.
"// FTDI" for FTDI cable support
"// BT" for classic Bluetooth support
"// BLE" for Bluetooth LE support
We can then parse this information during the Subsurface build process
and create the (hopefully correct) support matrix for dive computer
download from the mobile apps.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Stop pretending that all the devices since the Petrel are the same. They
actually aren't. So let's detect them and correctly identify them.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This should be a STRING callback, but those come from the header and we
don't have the information until after we have parsed all the samples.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The first dive computer to support this is the Perdix AI. Interestingly,
this keeps track of two sensors at all times. I haven't seen data with
two sensors active, yet.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The earliest document I have references log version 6. There are
apparently older versions, but I don't know what the differences
are. Before version 7, the log version wasn't always reliably
stored, so we assume 6 is the minimum and use 7 (or later) if we
find it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Newer cochran DCs record a gas change event at the begining of a
dive. The code creates a gas change before processing samples so
with newer DCs this resulted in duplicate events.
The method used to calculate the data used by dives (to determine when
we run out of ringbuffer) incorrectly didn't include surface sample
data. Ten to twenty minute of sample data is recorded at the surface in
case the diver re-descends, continuing the dive. The code then thought
that older dive profiles were not yet overwritten. The improper data was
returned to the user.
This function is much more useful if it works like a
ringbuffer_distance() function. It assumed the wrong values when
calculating profile size and it didn't have easy access to values it
needed to properly calculate profile sizes.
It makes sense to keep since it validates pointers.
Commander II pointers to profile ringbuffer data was wrong. After seeing
the Commander I encoding I realized the Commander II encoding of RB
pointers was in a flipped word big endian format. It only appeared to be
in normal big endian format because of an adjacent pointer that usually
shared the same first two bytes.
This adds support for older Cochran Commander dive computers,
specifically Commanders with serial numbers prior to 21000.
This also renames "Commander" model to "Commander II" and
adds "Commander I" to refer to pre-21000 models.
Since commit 344bfab229a17c7227b9bec02f616505a8d9e998 only a subset of
the id string is used to detect the model. But because the offset was
never updated, the model detection always fails now.
When I added support for the new Suunto EON Steel bluetooth download, I
needed crc32(), and instead of cooking my own (libdivecomputer does do
its own versions of the simpler crc functions), I made libdivecomputer
just depend on zlib instead, which provides a convenient crc32() function.
But I didn't add the new linker flag (-lz) in the right place in the
automake. It worked fine for me on Linux, but apparently not so well on
macos.
This fixes it.
Reported-and-tested-by: Benjamin <nystire@gmail.com>
Tested-by: Axel Richter <Axel.Richter@freenet.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
At the moment, the progress reporting will jump straight from about 0%
at the start of the download to 100% at the end of the download, without
any updates in between. This is improved by updating after every packet.
The error code returned by the dc_usbhid_read() function should be
returned as-is, instead of being replaced with some generic error, which
gets translated again to DC_STATUS_IO in the caller.
I did the packet logging for the received data side, but forgot to do
the same thing on the command transfer side, which makes the debug logs
a bit less useful.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When doing the G2 downloader, I dropped the initial handshake as I tried
to keep the code minimal, and the handshake didn't seem to make any
difference what-so-ever to me.
And it probably doesn't matter for anybody else either. But the code
isn't working for some people, and maybe it does actually matter.
More importantly, Scubapro's own LogTRAK application does send those two
initial commands, and it's probably a good idea to minimize the
differences between the different downloaders anyway, so add the
handshake sequence back in.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jef Driesen correctly points out that the 'address' field is just
leftover from the IrDA code, and is meaningless for the USB HID
transport version of the Scubapro G2.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The back-end parser seems to be the same as for the Uwatec Smart (aka
Galileo Sol). At least that's the assumption right now.
The downloader just uses USB HID (very similar to EON Steel) rather than
the horrible IrDA thing.
There's also eventually a BLE thing, but that's for the future.
This is an unholy mixture of the Uwatec Smart downloader logic and the
EON Steel usbhid transfer code. The back-end is pure Uwatec Smart
(model 0x11, same as Galileo Sol).
I'm not at all sure this gets everything right, but it downloads
*something*.
[Jef Driesen: Renamed the backend to uwatec, and made some smaller
cosmetic changes to match the existing coding style.]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The serial ops used a legacy calling convention that passed in just the
pointer to the userdata pointer (ie the first argument to the functions
was "void **userdata").
That's actually very inconvenient, because the custom IO data can not
only contain other interesting information that was filled in by the
custom IO provider, it also made it harder to chain these things
together, as exemplified by the core to emulate serial over the packet
interface in the subsurface bluetooth code.
This also adds the 'dc_context_t' field that is passed to the packet
routine open. That can allow the open routine to override the
'custom_io' details of the context at open time (to allow nested
custom_io operation).
Note that callers of the open function need to be aware that the
'custom_io' can be changed by the act of opening a custom_io, and the
value shouldn't be cached in some local variable.
Finally, this adds a new user-supplied opaque pointer
dc_user_device_t *user_device;
to the custom_io descriptor.
The 'user_device' data is filled in when registering the custom_io with
data that the custom IO open() routines can use. This is different from
the existing 'userdata' in that the 'user_device' is filled in before
dc_open_device() is called (and "open" can then use it to limit what
kinds of devices it looks for, for example).
In contrast, the existing 'userdata' field is filled in by the
"xyz_open()" routines, and contains the data necessary for the IO
itself.
The SSRF_CUSTOM_IO define is updated to v2 to indicate the new
interfaces.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This merges the Suunto EON Steel and Scubapro G2 BLE downloading updates
into the main Subsurface branch.
The basic infrastructure had been done earlier, this is just the tweaks
to actually take advantage of the BLE GATT back-end in Subsurface for
those two dive computers.
The actual subsurface code that exposes BLE GATT interfaces has not been
made public yet, it's too ugly, and will probably make small children go
blind. But I'll try to clean it up a bit and get it out for wider
testing asap.
* BLE-downloaders:
Scubapro G2: update for BLE downloading
Complete the EON Steel HDLC encoding/decoding work
Teach the EON Steel about HDLC encoding of the command packets
The code actually almost worked as-is, but for a tiny detail: the USBHID
packet reception code always receives a full 64-byte packet, while BLE
GATT will return how much it actually received.
The other difference is that USB HID is so fast that it didn't make any
difference where the progress was updated, it took about a second to
download everything.
BLE GATT is not fast to begin with, and the G2 may be particularly slow.
So with the BLE backend, you really do want progress updates for each
packet received, because the dump is going to take a while...
But with the trivial packet verification change, and with the progress
report updates, everything "JustWorks(tm)" over BLE.
Of course, I haven't committed the actual Subsurface BLE transfer parts
yet, because they are some incredibly ugly stuff with fragile bits and
pieces. But the fact that I can now download from two different dive
computers does mean that I think it's getting to the point where I will
just submit even my ugly code to Dirk.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The previous patch did the HDLC encoding on packet send, this does the
HDLC decoding on the receive side.
In order to properly check the data integrity, the HDLC-encoded packet
needs to be fully received before it can be processed. So while the HID
downloading continues to work packet-by-packet, the HDLC encoded BLE
GATT stream needs a temporary buffer for the data that gets filled as we
ask for the reply header.
Right now only the old USB HID path is actually tested, because I
haven't flushed out the packet receiving side in subsurface yet.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The BLE GATT transport ends up using HDLC for the stream encoding,
unlike the USB HID side. The EON Steel BLE GATT protocol actually does
that for both the commands and for the replies, but this converts only
the command side, because that's the simpler one.
The reply side code will need to be re-architected a bit, because right
now it is very much oriented towards beign able to do everything one
single packet at a time (which is true for USB HID) rather than treating
the packets as a stream of data (as is necessary for the CRC32
verification and to handle the escaping of the 0x7e/0x7d bytes in the
stream).
So with this change, you can't actually do a download over BLE, but I
was able to verify that the first command transfers correctly, and the
EON Steel replies to it over Bluetooth LE GATT.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This means that they still default to their respective USB devices, but
you can now set custom IO structure to pass in your own data.
Not only will we hopefully have some kind of BLE support, you could also
use this to simply emulate packets from a log-file by having a packet
replay (or by actually emulating a device). Of course, you can already
do this by actually emulating the device in a virtual environment, but
it might be useful for some kind of libdivecomputer testing environment.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Basically, this alows us to hide the usbhid code behind the custom_io
abstraction, so that a dive computer could either be given a supplied
custom_io structure, of if none is given, would create one for a USBHID
device.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The custom IO handlers will be extended to not just do serial line
emulation (generally over Bluetooth rfcomm), but do BLE too.
BLE does not look like a serial protocol at all, it's packet-based, and
we may have to add specific routines to indicate which GATT endpoints to
use etc. But like the traditional custom serial code, we want to do the
actual IO not from within libdivecomputer, but from the user of the
library (because the BLE support will require things like the Qt
Connectivity layer - and we do not want libdivecomputer to have to link
against something like Qt).
So this renames 'custom_serial' to 'custom_io', and instead names the
individual member function pointers 'serial_*' to make it clear that
those members are for serial communication.
It also adds new placeholders for packet_open/close/read/write. Note
that while these may look similar to the serial counter-parts, they are
not the same or even necessarily mutually exclusive. It is possible the
the caller fills in one or the other (or both), and they would be used
independently.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dives that are reported by the dive computer as unreadable (for example
due to a power loss during the dive) are now skipped instead of being
reported as a fatal error. Those dives can't be retrieved, so there is
no good reason to abort the download.
