On 10 June 2018 at 16:04, Lubomir I. Ivanov <neolit...@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 -- _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface