[TEST REQUEST] Windows Bluetooth LE build

[Jan Mulder]

 > 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...

Subsurface and connected libdivecomputer did work perfectly with my 
OSTC3 (which presents itself als OSTC Plus) some time ago. I even did 
firmware upgrades over BLE (all on Linux). Just tested current master 
for a normal download over BLE and that works (and it reminds me that I 
do not like using BLE when classic BT is available (all Linux)).


 > 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?

I will try to fire up my Windows machine, to check what is happing there 
  in BLE context (but disclaimer: I'm far from a Windows developer).

--jan