[TEST REQUEST] Windows Bluetooth LE build

Lubomir I. Ivanov neolit123 at gmail.com
Mon Jun 11 08:16:03 PDT 2018


On 11 June 2018 at 17:49, Dirk Hohndel <dirk at hohndel.org> wrote:
>
>> 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?

it does it with calls that are not exposed to user space.

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

it doesn't work for the OSTC. i've tried writing a native WINAPI test
app, bypassing Qt, but there is no API for pairing or connecting.
maybe there is a way to hack around it - waiting on response from
QtConnectivty too.

threads of interest:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/e321cb3c-462a-4b16-b7e4-febdb3d0c7d6/windows-10-pairing-a-ble-device-from-code?forum=wdk
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

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

where can i find this documentation?

if someone gives me the Linux UUIDs of the 4 chars i can compare.
even a dump of the whole successful operation of downloading dives
(command exchange etc) would help.

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

after writing 0xBB to the first char, the second char (that suddenly
becomes readable) either becomes "0xBB - 0x4D" or "0x4D".
i don't know what dictates the differences here.

>
>> 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'm not allowed to dual boot this machine.
my VMs have trouble gaining access to the BLE hardware - i can try that again.

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

writing to a characteristic that has the "WriteNoResponse" flag, means
that no Qt signal will be emitted that someone wrote to that char.
which means that a characteristicWritten() would not be reached.

in the case of the OSTC+ we are writing to such a char (the first one).
after that it becomes a question of how we detect if someone wrote to
it in libdc or subsurface.
i wasn't able to find the code for that, but please feel free to
correct me as i was kind of tired when checking...

>> 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")
>

yes, i'm aware. just wondering, because some other DC might just work.

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

sounds good.

lubomir
--


More information about the subsurface mailing list