Merge misc fixes from Jef's upstream.
This fixes the incorrect and partial Oceanic Geo 4.0 support from commit
e38406b353bb ("Start adding IDs for the Oceanic Geo 4.0"), where I was
assuming it looked like the I770R.
* https://github.com/libdivecomputer/libdivecomputer:
Add support for the Oceanic Geo 4.0
Fix a buffer overflow
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>
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>
Merge upstream libdivecomputer updates from Jef:
- Add support for the Aqualung i550C
- Update Ratio iX3M GPS naming and note that they support rfcomm
- misc cleanups
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Add support for the Aqualung i550C
Enable bluetooth support for the Ratio iX3M GPS
Update the naming of the Ratio iX3M GPS range
Mark the string tables as constant
Refactor the filter functions
There's a new dive computer in town: the Oceanic Geo 4.0. It looks like
it should support BLE, and is probably fairly similar to the Pro Plus X.
Or so this initial support trial just assumes.
I don't have the version string for this device yet, so that hasn't been
added at all. A full dump is required, the initial report only (almost
accidentally) gave the model numbers thanks to the BLE scan data.
Reported-by: George Rocks <jrroques2004@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge Jef's upstream updates.
Trivial conflicts just because of whitespace differences and a comment
difference in our Suunto D5 support changes.
* git://github.com/libdivecomputer/libdivecomputer:
Add support for the Suunto D5
Add support for the Tusa Talis
Add the G2 HUD bluetooth device name
Detect Mares Quad with more flash memory
Fix the limit for an invalid sample temperature
Fix a buffer overflow
It seems that the BLE communication protocol is somewhat different from
the serial one in the version string: while the serial version tends to
show the memory size, the BLE version string has some other numeric
pattern.
We don't have enough information to guess what it is, although normally
the BLE pattern is just "0001" instead of some memory size string. But
I've seen the i770R once report 0090 instead. Some status code?
Regardless, make the Pro Plus X and the I300C pattern simply ignore the
last four digits, since they clearly vary, and those two computers
support BLE.
The i770R pattern already did that, since I saw it myself. The Pro Plus
X I have a communication trace from Brett Woods, and the i300C I just
assume follows the same pattern.
Reported-by: Brett Woods <brett@jeepswag.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sync up with Jef's upstream changes.
About half of it was stuff we'd already done: i770R support (together
with the Oceanic dive truncation) and the change to the Scubapro G2 BLE
protocol.
And once again, Jef has taken the work of others (me and Janice) and
made pointless changes to it just to make merging harder.
And once again, I tried to match up with upstream as much as possible to
make future merges easier. But it annoys me.
This *may* also get the Aqualung i300C working over bluetooth. I have
no real way to test, but the basic parsing support is there thanks to
Jef, and Janice implied that the BLE handshaking is the same as the
i770R.
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Add support for the Aqualung i300C
Add support for the Aqualung i770R
Fix the Pro Plus X gas mixes
Oceanic: fix up dive truncation issues
Scubapro G2: update BLE downloading for new 1.4 firmware version
Add a workaround for invalid ringbuffer begin pointers
It appears that the Aqualung i770R looks almost the same as the Pro Plus
X, but has an additional pO2 field for each gas by the O2 field, which
impacts the offset calculations.
Pull upstream updates from Jef Driesen.
This is mainly the Pelagic (Oceanic, Sherwood, Aeris, Aqualung etc)
download interface reset sequence.
* https://github.com/libdivecomputer/libdivecomputer:
Fix the RTS signal handling for Pelagic interface
Fix a memory leak in the error handling
The "I have NO IDEA" 0xE5 command seems to be a handshake packet with a
passphrase based on the serial number of the device.
Sadly, we can't actually read the serial number from the device until
after this handshake as successfully completed, which makes it a bit of
a chicken-and-egg problem from a communication standpoint.
However, the serial number is also exposed in the bluetooth name that
the device advertizes, which is the reason for the newly added
"dc_iostream_get_name()" function - so that whoever set up the IO for us
can give us the name.
Annoying, yes, but less annoying than "I have NO IDEA".
Thanks to Janice McLaughlin for pointing out the logic of this magic
handshake, which is apparently also the case for the Aqualung i300C.
This also simplifies the command sequence handling: if you use
oceanic_atom2_ble_transfer() and ask for an answer (even if the answer
size is zero, and only the ACK is returned), the BLE transfer code will
handle the sequence number on its own.
Only if you send a packet without expecting an answer at all do you need
to manage the sequence number manually. This is mainly used for
oceanic_atom2_device_write(), although I suspect that code gets an ACK
and could use a zero answer size too.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This fixes the dive truncation that happened with long dives due to the
removal of extra padding (commit a2100843b9cf: "Remove extra padding
from the end of the profile"). It turns out the rest of the profile was
in bits 13-15 (with bit 12 being something else).
Also update the memory layout and the baudrate for the i770R.
Signed-off-by: Janice McLaughlin <janice@moremobilesoftware.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The RTS signal needs to be low before it is raised, and not just set.
This ensures that the PIC inside the Pelagic PC interface is reset and
the initialization sequence always starts cleanly, regardless of the
previous state of the signal.
Reported-By: Bill Perry <bperrybap@opensource.billsworld.billandterrie.com>
It seems to make things more robust. Without this, the first packet in
particular seems to easily get lost, and the retry gets things going
again.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This works over BLE, although the end result of a dive download is still
a bit wonky. There remains some parsing problem that Jef says are
likely be common with the Pro Plus too.
The serial download doesn't work at all, for unknown reasons. That
*should* be the easy part that "just works" and acts the way previous
similar dive computers have acted. It's a standard FTDI chip (FT231X)
that exposes a serial connection, but there may be some setup required
to choose between USB and BLE that we do not know about right now.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Oceanic Pro Plus X is quite different from the previous models. The
profile data is now stored in a dedicated memory area, and hence there
are a few important differences:
Reading data from the new profile memory area is done with a new F6
command. This new command is very similar to the existing B8 command,
but accesses a completely different memory area. In order to integrate
those two memory areas as transparantly as possible into the existing
infrastructure, a virtual memory space is introduced. The lower part of
the virtual memory is mapped onto the main memory area, while the upper
part is mapped onto the new profile memory area.
The page size of the new profile memory area also increased from 16 to
256 bytes. If the profile size is not an exact multiple of 256 bytes,
the dive computer pads the profile data with 0xFF bytes.
The other changes are the usual Oceanic device specific changes.
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.
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 second variant of the open or create functions were introduced to
maintain backwards compatibility. But after being removed from the
public api, these functions serve no purpose anymore, and can be removed
completely.
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.
Select the default memory layout for unsupported devices based on the
amount of memory indicated in the version string. This allows to
download a full memory dump.
At the moment, the encoding of the serial number is tied to the global
pointer mode. To support devices where this is no longer the case, a new
entry for the serial number encoding is added.
By adding the logbook and profile functions to the vtable, a dive
computer backend can now easily replace the default implementation with
a custom one, without having to duplicate the common code.
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.
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.