Subsurface-mobile with BT and BLE support [was Re: updates to libdc with ABI change]

Linus Torvalds torvalds at
Thu Jun 29 08:59:29 PDT 2017

On Thu, Jun 29, 2017 at 5:19 AM, Jan Mulder <jlmulder at> wrote:
> 5 screenshots are attached. While I first thought that the correct service
> was detected,  I know think it is the wrong one.

It's not just that we probably picked the wrong service, that service
also has four different characteristics, and we would read from the
wrong one.

This is another case of "serial over BLE GATT is not standardized"
thing. So what my BLE code does is:

 - pick the first service that looks very vendor-specific (so in this
case it picked that 53544d54 service)

   On the OSTC, apparently we should pick the 0000fefb service.

But even had we picked the right service, within that service we did
the wrong thing, because our current logic is:

 - within the service, write to the first characteristic, and notify
(aka read) from the last one.

which worked fine with all the dive computers I'd seen so far. On the
OSTC, apparently I should enable notifications from the second one.

The reason it does "read from the last one" is that on the Shearwater,
there's only one characteristic, and it's read-write, so the "first
and last" choice ended up working for all the cases I'd seen (two
characteristics or one). But the OSTC has four.

We were going to have some service uuid list for dive computers we
know about anyway, so I'll just have to add that to the data we
maintain, and pick the service based on that.

And I'll change the first/last characteristic to just walk the list of
characteristics and look at the actual read/write properties. I may
have to add per-uuid quirks there too, we'll see.

> In order to check my hypothesis, I hacked around in qt-ble.cpp. And yes, I'm
> basically sure that the service 0000fefb... is the right one. In the code in
> master this one is discarded as standard, but by using this anyway I am able
> to get the OSTC3 in download mode. I did not succeed up to now to receive
> data from the OSTC3, so obviously, the parsing fails right at the start.

You could probably  just verify my "enable notification from the
second characteristic" by extending on your hack with the attached
patch. Does that make it work for you?

Note that you'll still need your code to pick the right characteristic
- this is just the "enable notifications right" side.

Anyway, I have enough information to try to hack something up. No
guarantees about whether it will work, but worst comes to worst I
guess I can get an actual dive computer to play with from Dirk and
have something to actually test against. But if you can test the
patch, that would be good.


-------------- next part --------------
diff --git a/core/qt-ble.cpp b/core/qt-ble.cpp
index d6a71665..b03783a5 100644
--- a/core/qt-ble.cpp
+++ b/core/qt-ble.cpp
@@ -251,10 +251,17 @@ dc_status_t qt_ble_open(dc_custom_io_t *io, dc_context_t *context, const char *d
 	/* Enable notifications */
 	QList<QLowEnergyCharacteristic> list = ble->preferredService()->characteristics();
+	const QLowEnergyCharacteristic *notifyC = NULL, *writeC = NULL;
-	if (!list.isEmpty()) {
-		const QLowEnergyCharacteristic &c = list.constLast();
-		QList<QLowEnergyDescriptor> l = c.descriptors();
+	foreach(const QLowEnergyCharacteristic &c, list) {
+		if (!notifyC && ( & QLowEnergyCharacteristic::Notify))
+			notifyC = &c;
+		if (!writeC && ( & (QLowEnergyCharacteristic::WriteNoResponse | QLowEnergyCharacteristic::Write)))
+			writeC = &c;
+	}
+	if (notifyC) {
+		QList<QLowEnergyDescriptor> l = notifyC->descriptors();
 		qDebug() << "Descriptor list with" << l.length() << "elements";

More information about the subsurface mailing list