[TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On 10 June 2018 at 16:04, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>
> BT classical mode works - i was able to download 10 dives, that
> apparently already existed on the DC.
> i need to debug the BLE response from the device.
>

status report:
so sadly i'm observing a multitude of problems here with this DC
(OSTC+) on Windows with BLE.

1) the native WINAPI does not have means to pair or connect to a BLE
devices programatically, which means that the user has to find the
devices using Control Panel methods and pair / connect to it manually.
only at that point the GATT calls start working as the device services
get mounted to virtual paths. Qt is also affected and i will discuss
this with QtConnectivity.

this has been the case since the BLE API release in Windows 8.1:
https://social.msdn.microsoft.com/Forums/en-US/65c9cf4e-e225-4fc3-8c2c-66cd2401d3ed/how-to-establish-a-connection-from-windows-8-pc-to-a-bluetooth-low-energy-device

i found a comment that says that supposedly the Windows 10 "creator
update" makes the GATT calls work without pairing, but i cannot
confirm that as i have this ("whatever-")update installed.

the weird thing is the "BLE explorer" application which is UWP based
supports pairing and connection...to my understanding it uses C++
calls that make it possible to pair / connect to a device and the same
C++ calls are not available to non-UWP apps. i need to investigate
this more.

overall the state of BLE on Windows is quite poor according to users.

i really need to see a report where a paired DC handles the GATT part.
thus far the reports are only about DC not being paired (e.g. no mount
paths).

2) so OSTC+ has a certain service with 4 WriteNoResponse
characteristics (no READ, WRITE-ONLY) which is supposedly the service
we have to use for communicating to the device. at least we assume
that in Subsurface but i don't see a concrete reason for this
assumption. we also assume that the first characteristic is the one we
want to write the "0xBB" to.

when i manually write the "0xBB" (INIT) command to the first
characteristic the second characteristic becomes READ-ONLY and
responds with 0x4D (READY) in "BLE explorer". i think the current
BLE-Win32 stack in QtConnectivity does not handle that and the seconds
characteristic remains WRITE-ONLY. this has to be discussed with
QtConnectivity as well, i guess.

3) i don't think we handle 2) well in Subsurface.also i don't have
information if the BLE code in Subsurface and the code in
libdivecomputer works for OSTC+ on other OSes...
i know that writing to a WriteNoResponse characteristic would not
trigger our BLEObject::characteristicWritten().
BLEObject::characteristcStateChanged() also doesn't trigger.

this obviously needs more debugging, but not sure when i'm going to
have more time - maybe tomorrow.
also, i'm very interested how many people will respond to the testing
request...3, 10, 30?

lubomir
--