On Thu, Jun 29, 2017 at 5:19 AM, Jan Mulder <jlmul...@xs4all.nl> 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. Thanks, Linus
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 && (c.properties() & QLowEnergyCharacteristic::Notify)) + notifyC = &c; + if (!writeC && (c.properties() & (QLowEnergyCharacteristic::WriteNoResponse | QLowEnergyCharacteristic::Write))) + writeC = &c; + } + + if (notifyC) { + QList<QLowEnergyDescriptor> l = notifyC->descriptors(); qDebug() << "Descriptor list with" << l.length() << "elements";
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface