Commit graph

80 commits

Author SHA1 Message Date
Dirk Hohndel
bb1df1218d BLE support: simplify write function
It seems clearer to bail when list is empty...

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-09-20 19:19:25 -04:00
Dirk Hohndel
753c00a493 BLE on non-Apple OSs: switch back to using BT address
While this interface is deprecated, too much in our existing code depends
on being able to create the QLowEnergyController with just the address.

Additionally, createCentral() is new in Qt 5.7 and therefor this broke
builds on Linux distros that are still on 5.6.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-09-17 16:31:07 -07:00
Dirk Hohndel
90d73924c2 BLE: try to pick the correct descriptor to write to
The ordering on Mac appears to be random, but after looking through the
various successful logs of BLE downloads, it seems we always wrote to the
ClientCharacteristicConfiguration descriptor. So try to find that one first,
and only grab the first descriptor in the list if we didn't find a
ClientCharacteristicConfiguration descriptor.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-09-17 09:58:11 -07:00
Dirk Hohndel
26e610c3f4 BLE: create controller from QBtDeviceInfo
Creating it from an address is a) deprecated and b) impossible on Mac or iOS.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-09-17 09:58:11 -07:00
Dirk Hohndel
2d405a1ebb Another signed/unsigned warning
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-08-26 14:53:59 -07:00
Anton Lundin
7c6fa227ea Null check before writing to pointer
In the serial api for libdivecomputer is ok to send NULL as the int
pointer actual, if you dont't care about how many bytes that where
actually read or written.

This makes sure we don't crash if the ble backend where ever used with
such a backend.

Signed-off-by: Anton Lundin <glance@acc.umu.se>
2017-08-01 13:39:35 -07:00
Jan Mulder
fbaaa64a4a Trivial code cleanup
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-11 17:11:49 +02:00
Jan Mulder
b409e9fc91 BLE read: remove aggressive read
Commit 709c1df2af introduced a hard blocking read for BLE devices.
This did break BLE reads from multiple DCs, and (in hindsight) was not
a correct implementation. It would require, for example, dynamic
read buffers as especially profile data grows with dive time, and
in addition, and more importantly, also the OSTC libdc parser cannot
process the entire profile of a dive at once (but likes to receive
it in 1K blocks). So, basically, it introduced issues, and did not
solve the OSTC read.

This commit reverts this hard blocking read (and as such will break
OSTC BLE reads). But it enables removal of the special cases for
the EON Steel and G2.

A next commit will solve OSTC BLE reads.

Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-11 13:29:41 +02:00
Jan Mulder
b7057c414f OSTC over BLE: take care of credits
Handle credits. Do not just ask for maximum credits all the time as this
will stop the download. Also do not let the credits go back to 0 (while
this might work, this is not tested). Getting back the 0 credits stops
the download, and even when it can be restarted, it is less efficient
(and not needed). Notice also that it takes some time before a grant
request is honoured. During testing I saw reception of up to 25 packets
between request and grant. So a lower bound for the request of
32 packets seems resonable.

One aspect the Telit/Stollmann TIO puzzeled me. Sections 4.1 and 4.2
both talk about credits, but my hyphothesis is that there are two
credits counters in play. One for traffic either way. This commit
only deals with credits granted by Subsurface to the OSTC to send
data. Credits granted by the OSTC to allow Subsurface to send new
commands is NOT part of this commit, and is seemingly not needed
in our scenario. As we only send new commands to the OSTC when
a previous one is finished (per HW's interface spec), the OSTC
does not run out of credits to receive commands.

Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-11 13:17:00 +02:00
Dirk Hohndel
55df597994 BLE support: the G2 wants packages one at a time
Just like the EON Steel it doesn't want us to loop until all packages
have been received.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-07-09 11:57:32 -07:00
Dirk Hohndel
4834f51a73 BLE: reduce the noise of debug output
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-07-06 09:35:04 -07:00
Dirk Hohndel
a8468caaa2 BLE: minor code cleanup
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-07-06 01:37:21 -07:00
Dirk Hohndel
a4bb61b58a BLE download: EON Steel doesn't want to loop over reads
This seems a bit brutal, but it does the trick and makes EON Steel
downloads work again.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-07-04 09:30:05 -07:00
Dirk Hohndel
8a1f5b9566 BLE: write confirmation isn't HW only
Happens on the Suunto EON Steel as well.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-07-04 09:29:31 -07:00
Jan Mulder
3cde4f594d Address code review
Addresses code review by Dirk. No functional changes.

Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-04 23:46:07 +09:00
Jan Mulder
709c1df2af BLE: read until no more data in coming in
The current BLE read reads just one 20 bype packet. That packet size is set
in ble_serial_ops, so, without being able to test on anything other than
a OSTC3, I assume that this holds for other BLE DCs too. So, I think is
is weird that those interfaces work with the current read() of just one
packet at the time.

As we need a blocking read (at least for the OSTC parser), just read all
data that is available on the input. And when we think we are done, give
the QtEventloop control to see if there is more, and process that incoming
data as well. All this basically implements a blocking read.

CAVEAT 1: This might break the reading from the currently working BLE devices.

CAVEAT 2: With this, I still cannot read the OSTC3 completely. For
developers familiar with the HW transfer protocol: it just stops while
reading the first full dive (header + profile) command 0x66, despite
correctly reading about 5Kb of data before. For some
reason, I do not believe that this is related to this commit.

CAVEAT 3: All above tested on Linux Desktop with bluez stack, and
confirmed NOT to work on Android 7.1.2, build with Qt 5.9.0, And
yes, I know 5.9.1 recommended.

Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-04 23:46:07 +09:00
Jan Mulder
d6b17fef08 OSTC over BLE: filter and track OSTC credit traffic
1) As the OSTC sends data to the BLE central role (the SSRF client) over 2
characteristics, we have to filter the administrative credit data from
the actual dive data that it received. The characteristcStateChanged
function is adapted for this.

2) We have to be sure that the Terminal Client I/O is fully defined during
opening the connecton to the OSTC. From 6d505b24f0c15 we can see
that the last step in setting up the terminal interface is the grant
of credits. This is done by writing to the proper (the only one, with
id = 0x2902) descriptor of the credits RX characteristic. The here
added slot is triggered on the completion of write of credits marking
the final stage of the setup.

Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-04 23:46:07 +09:00
Jan Mulder
6031692a39 Use waitFor instead of timer
See e79bede0aa. We rather use wait in combination
with spinning the event loop.

Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-04 23:46:07 +09:00
Jan Mulder
f6768cedf3 OSTC over BLE: Select the right service
The current "select the correct BLE service to talk to" is flawed.
It assumes that the first found non-standard UUID is the right one
and apparently it is for some DCs. But not for the HW devices.
The HW devices use a "standard" ie. approved by the Bluetooth
SIG, controller, that comes with a UUID that our code currently
considers standard so not to be the right one.

This (simple) commit selects the right service for HW. The UUID
is hard coded, and this is ok, because it is tied to the hardware
used by HW. Futher, it does not change anything for other BLE
devices.

Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-04 23:46:07 +09:00
Jan Mulder
6fe0388b96 OSTC over BLE: initialize Terminal I/O client
This initalizes the Terminal I/O client as described in paragraph 3 of
http://www.telit.com/fileadmin/user_upload/products/Downloads/sr-rf/BlueMod/TIO_Implementation_Guide_r04.pdf

This is for all Heinrichs Weikamp computers, that use referenced BT/BLE hardware
module from Telit Wireless Solutions (Formerly Stollmann E+V GmbH). The 16 bit
UUID 0xFEFB (or a derived 128 bit UUID starting with 0x0000FEFB is a
clear indication that the OSTC is equipped with this BT/BLE hardware.
Furthermore, most devices equipped with this BT/BLE hardware have BT addresses
starting with 00:80:25:...

Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-04 23:46:07 +09:00
Dirk Hohndel
bc1a313c9f Increase the BLE timeout to 12 seconds
This seems really long, but one user appeared to get a response after
almost 10 seconds. So going with 12 for some margin of error.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-07-03 22:22:16 -07:00
Dirk Hohndel
f98fa50c39 BLE code: address some compiler warnings
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-06-27 20:53:11 -07:00
Linus Torvalds
526595644f Use SSRF_CUSTOM_IO v2 to implement device data quirks for BLE GATT
Right now we have a quirk for Shearwater devices to set the random
address flag, but also to handle the differences at read/write time.

With this, I can finally download from both the Suunto EON Steel and the
Shearwater Perdix AI with the same binary.

It's not *pretty*, but it works.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 15:14:27 -07:00
Alex Blasche
e79bede0aa Use QLowEnergyController without QEventLoop
We rather use wait in combination with spinning the event loop.

Signed-off-by: Alex Blasche <alexander.blasche@qt.io>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 11:03:19 -07:00
Alex Blasche
57753321b0 Ensure all found BLE services are tracked
If a device has more than one service the order of service discovery
determined the selection of the service that we intend to interact
with. This assumption is not accurate and is even platform dependent.

Thinking ahead, it is likely that some devices may require us to keep
track and interact with multiple services at the time.

The new logic still suffers from the fact that there is no way
to select the correct service for interaction. This will require
higher level stack changes.

Signed-off-by: Alex Blasche <alexander.blasche@qt.io>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 11:03:19 -07:00
Alex Blasche
81dabe5ace Fix incorrect uuid check due to temporary char* in QString::toUtf8()
toUtf8() creates a temporary char* representation which is assigned to
uuid. As soon the object created by toUtf8() gets destroyed, the uuid
pointer points to releases memory.

The intention is to check that we don't have one of the standard
16bit Bluetooth uuids. That's the purpose of QBluetoothUuid::toUInt16().

Signed-off-by: Alex Blasche <alexander.blasche@qt.io>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 11:03:19 -07:00
Linus Torvalds
d0c3ef4cf8 Bluetooth: make LE-only devices add "LE:" as an address prefix
This seems a bit odd, but it actually has three different reasons for it:

 - It's a visual indication of BT LE mode for users

 - the rfcomm code only works with legacy BT support, and if we scan a
   device that only does LE, we want the custom serial code to instead
   automatically fall back on a "emulate serial over LE packets" model.

 - we want rfcomm to remain the default for devices that do both legacy
   BT _and_ LE, but we want people to have the ability to override the
   choice manually.  They can now do so by just editing the address
   field and adding the "LE:" prefix manually, and it automatically gets
   saved for next time.

So while a bit hacky, it's actually a very convenient model that not
only works automatically, but allows the manual override.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-06-26 22:20:01 -07:00
Dirk Hohndel
6f1590b098 BLE support: convert fprintf(stderr,...) to qDebug()
This way the output can be seen in the AppLog on Android.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-06-24 22:32:47 -07:00
Dirk Hohndel
63fc06e728 BLE support: add SPDX headers
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-06-24 22:32:01 -07:00
Linus Torvalds
196adb591b Very early and likely quite broken BLE GATT code
This is some very early and hacky code to be able to access BLE-enabled
dive computers that use the GATT protocol to send packets back and forth
(which seems to be pretty much all of them: a vendor-specific GATT
service with a write characteristic and a notification characteristic
for reading).

For testing only.  But it does successfully let me download dives from
my EON Steel and my Scubapro G2.

NOTE! There are several very hacky pieces in here, including just
"knowing" that the write characteristic is the first one, and the
notification characteristic is second.  The code should actually check
the properties rather than have those kinds of hardcoded assumptions.

It also checks "vendor specific" by looking at the UUID string
representation, and knowing that the standard ones start with zero.
Crazily, there doesn't seem to be any normal way to test for this,
although I guess that maybe the uuid.minimumSize() function could be
used.

There are other nasty corners. Don't complain, send me patches.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-06-24 21:58:01 -07:00