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>
It really looks (very superficially) like the Oceanic Pro Plus X might
act exactly the same as the Aqualung i770R over bluetooth: it has the
exact same bluetooth name pattern ("ER001299", where "ER" is the ASCII
represetnation of the model number (0x4552) and the 001299 looks like
the serial number that we then use for "authenticating" with the device.
I haven't actually tested this at all, but Brett Woods sent the
bluetooth scan information, and it looks promising. So let's just test
it.
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.
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).
The packetization format for the BLE communication used to be that the
first byte of the BLE GATT payload was the size of the payload (1-19
bytes).
That seems to no longer be true as of fw version 1.4. It is still the
size of the payload for the simple small reply packets, but for the long
data stream it ends up being an odd sequence of 13 different values that
are almost - but not quite - 19 apart.
Whatever. Modify our strict "length byte must make sense" rule to be
more of a guidline than a hard rule. This makes the download succeed
again.
Very weird.
Reported-by: Adric Norris <landstander668@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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
Unfortunately there are several devices with an invalid ringbuffer begin
pointer. In such cases, the strict validation of the pointer causes the
download to fail, without being able to download any dives at all.
Since the begin pointer is only needed to detect the start of the oldest
dive, we can fall back to downloading the entire profile ringbuffer.
Usually we can still detect the start of the oldest dive in some other
(indirect) way. For example when reaching past the end of the
ringbuffer, or the presence of invalid pointers in the linked list
structure. The result is that, we'll be able to download at least some
dives before hitting some other error.
The packetization format for the BLE communication used to be that the
first byte of the BLE GATT payload was the size of the payload (1-19
bytes).
That seems to no longer be true as of fw version 1.4. It is still the
size of the payload for the simple small reply packets, but for the long
data stream it ends up being an odd sequence of 13 different values that
are almost - but not quite - 19 apart.
Whatever. Modify our strict "length byte must make sense" rule to be
more of a guidline than a hard rule. This makes the download succeed
again.
Very weird.
Reported-by: Adric Norris <landstander668@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
Some of the transport types have meaningful names.
The BLE transport has a device name that was exposed during device
discovery, for example, and some back-ends (ok, right now only the
Aqualung i300C and i770R) need to know what that device name was in
order to handshake with the device properly.
Other transports, like the USBSTORAGE one, could usefully use this to
get the basename of the path to the storage, although right now that
transport makes do with simply doing a "dc_iostream_read()" on the
transport instead.
For now, this is just the infrastructure, ready to get hooked into.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit fac3c8ff1487 ("Aqualung i770R: fix up gas mix parsing") was
supposed to fix gasmix parsing for the i770R, but because Janice's patch
didn't apply as-is, I had just redone it by hand, and in the process
copied the wrong o2_offset for the i770R, giving (not surprisingly) the
wrong results.
This just fixes my copy-paste error to what Janice actually had
originally.
Mea culpa.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Primoz seems to have problems downloading dives from the Garmin Descent,
even when the same files work fine for me. I suspect it's some Windows
issue, and the primary suspect would be the usual CR/LF text conversion.
Using O_BINARY would seem to be the obviously correct thing to do, and
won't hurt.
Reported-by: Primoz P <primozicp@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. the parsing was actually already there, but we never generated the
event to report it. I hadn't had any files with HR data.
Reported-by: Primoz P <primozicp@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It appears that the Aqualung i770R looks almost the same as the ProPlus
X, but has an additional pO2 field for each gas by the O2 field, which
impacts the offset calculations.
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>
Pull fix from Jef's upstream.
This fixes the end of dive garbage for newer Aqualung dive computers,
including the i770R.
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Remove extra padding from the end of the profile
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>
Even after removing the pages padded with 0xFF bytes, there are still
some invalid sample pages present at the end of the profile. But it
turns out the number of valid profile pages is stored in the logbook
entry.
The only caveat is that the number of pages appears to be stored as a 12
bit number, which limits the total profile size to only 64Kb. We don't
known what happens for larger dives.
So it turns out that we really shouldn't send the command and arguments
as one single packet in all situations, because at least the Mares
Matrix really seems to want that "wait for ACK before sending
arguments". See commit 59bfb0f3189b ("Add support for the Mares
Matrix") for details.
Also, because bluetooth is slow (and it looks like it's particularly
slow for us with the Qt bluetooth code for some reason), we don't want
to ask for big packets of data, because it seems to cause a buffer
overflow on the BlueLink Pro when the serial data from the dive computer
arrives faster than the bluetooth data can be sent to the downloading
side.
So when using the BLE transport, limit the packet size to 128 bytes and
disable the command splitting.
With this, I can download hundreds of kB of data from the Mares Quad Air
successfully over BLE. It's *slow*, but it works.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Mares backend used to send the commands by splitting them up into
the two-byte command and the "rest", while waiting for the ACK byte
(0xAA) to come in between the two parts.
That seems to work fine for the serial side, but the the BLE packets, it
seems to cause too much of a delay between the command bytes and the
argument bytes, and the end result is that the Mares doesn't actually
act on the argument bytes at all, and just sends an EOF reply (0xEA).
The Mares app itself does seem to send them as two packets, but
apparently without actually waiting in between, avoiding the issue.
Let's just send the command as a single write, which makes at least my
loaner Mares Quad Air with the BlueLink Pro dongle happy.
We may need to revisit the details of this based on feedback. But it
should speed up downloading too, by avoiding the roundtrip wait for the
ACK byte.
This affects all the computers in the Mares Icon HD family: Matrix,
Smart, Smart Apnea, Icon HD, Icon HD Net Ready, Puck Pro, Nemo Wide 2,
Puck 2, Quad Air, Smart Air and Quad.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The dc_iostream_{read,write}() implementation had multiple issues:
(a) it would return DC_STATUS_SUCCESS even if no iostream
implementation existed.
Yes, it would also return a zero "actual" bytes, but most backends
don't even pass an "actual" pointer, so returning success was still
completely insane.
This one probably didn't matter, because all iostreams should have
read and write members, but the return value was completely wrong
if that ever were to happen.
(b) The write side actually tested not whether a write function
existed, but whether a read one existed.
Again, this one probably didn't matter in practice, since an
iostream without a read and write member doesn't make much sense,
but the test was completely wrong regardless.
(c) If the user passed in a NULL 'actual' pointer, the wrapper would
ignore that, and pass in its own pointer instead, in order to know
how many bytes to print for the debug message.
But that means that the low-level read/write functions cannot know
whether the user actually is able to handle a partial read or not.
This one _definitely_ matters, because some protocols need to have
a buffer for the whole incoming packet, but packerts may not always
be full-size. The low-level protocol needs to know whether to wait
for further packets (in order to fill the buffer) or to just return
the partial data.
This fixes all of these issues. If the user passes in a NULL actual
pointer (indicating that it needs all-or-nothing and is not ready to
handle a partial success), just loop over the IO until the buffer is
fully exhausted.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 437cc3e0cc9f88eedf27657c485cd55f23a4f2df.
Jef convinced me that this is fundamentally the wrong thing to try here.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
Pull Aqualung i100 support from Jef's upstream libdivecomputer.
Very similar to the I200, but with the header in a different location.
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Add support for the Aqualung i100
Merge upstream libdivecomputer changes from Jef Driesen.
A harmless build cleanup, and a small fix for the Mares Smart Apnea
temperature parsing.
* git://github.com/libdivecomputer/libdivecomputer:
Fix the Mares Smart Apnea min/max temperature
Fix the libusb and hidapi includes
When on the actual watch, the filename format for the FIT files ends up
being something like
2018-09-21-10-23-36.fit
but then if you download the activity from the Garmin Connect activity
website, it might show up as a ZIP file that contains a file named
something like
3030954326.fit
instead.
In order to make it easy to import these fit files that have been
downloaded from the Garmin cloud, relax the filename rules a bit.
NOTE! You still need to have the proper directory structure, and put
your FIT files in a subdirectory like
<some path>/Garmin/Activity/
to match the way the FIT files show up when you mount the Garmin Descent
locally. You can then point subsurface to <some path> when you do a
"download" from the Garmin Descent, regardless of whether it's an actual
case of the dive computer being mounted, or if you've downloaded the FIT
files to your local filesystem.
Reported-by: Andrew Trevor-Jones <atj777atj777@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.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>
The data was always there, and we used to report it as the length of the
next deco stop, which didn't make much sense, but it was basically the
only interface that libdivecomputer had.
Now that we've added DC_SAMPLE_TTS, report TTS properly, and just report
the deco stop time (which the EON Steel doesn't actually give us) as one
minute whenever we have a ceiling.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This will allow parsing dives from the Shearwater Teric, but depending on the
firmware could also be used on older models.
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>
Based on information from Ryan January, who got it from his Garmin
contacts and got the go-ahead to share the data.
This is mainly the water density and deco model. It has a few other
fields troo, but nothing necessarily worth reporting.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Based on information from Ryan January, who got it from his Garmin
contacts and got the go-ahead to share the data.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
