[TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Jun 10, 2018, at 5:36 PM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> 
> 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.

So how does the Control Panel do this, then, if there are no API calls
to connect to a BLE device?
Case in point - DM5 does not require the user to somehow pair their
EON Steel with the computer, DM5 simply starts talking to it. Which makes
me think that we should try to just talk the OSTC and check if it responds...

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

This code was written based on documentation of the BLE stack that the
OSTC implements.
I wonder if the four characteristics are in the same order. It would be interesting
to dump all the information we can get on the four of them both under Windows
and Linux and see if this points at something odd.

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

If you write the 0xBB, do you get 0xBB anywhere on the characteristics that
you can see?

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

Linus and Jan should be able to answer most questions that you might have
on the BLE code / OSTC BLE interface. A lot of this is still rather fragile and
hack-ish, but we should be able to figure out how this is supposed to work
and if you boot Linux on your laptop you should be able to create "identical"
interactions on Linux (where this all works) and Windows...

> i know that writing to a WriteNoResponse characteristic would not
> trigger our BLEObject::characteristicWritten().
> BLEObject::characteristcStateChanged() also doesn't trigger.

I don't understand what you are trying to tell us here.

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

Lots of people have these dive computers. The questions you are asking
is about the intersection of people who (a) have a Windows laptop with
BLE and one of these devices (large number), (b) who've seen your
announcement (a lot fewer), and (c) who feel comfortable that they can
follow the instructions and make this work (that I expect to be a fairly
small number - in part because this is not just "run this installer")

I will leave on a two week trip on Wednesday and much as I love our
users, I will not bring the Windows laptop on this trip. But since Jan is
now able to play along, I hope that we'll be able to make progress 
nonetheless

/D