[TEST REQUEST] Windows Bluetooth LE build

Lubomir I. Ivanov neolit123 at gmail.com
Mon Jun 11 11:30:44 PDT 2018


On 11 June 2018 at 20:36, Jan Mulder <jlmulder at xs4all.nl> wrote:
> On 11-06-18 19:20, Lubomir I. Ivanov wrote:
>>
>> On 11 June 2018 at 20:00, Jan Mulder <jlmulder at xs4all.nl> wrote:
>>> Check for the correct ready byte is not done at the Subsurface side, but
>>> in
>>> the libdivecomputer procedure hw_ostc3_transfer(...). But not sure that
>>> answers your question.
>>>
>>
>> ok i see,
>>
>> to my understanding libdc has to query the value of the second
>> characteristic for the READY command via the Qt BLE.
>>
>> this characteristic remains with the state "Write without response"
>> and does not update it's state to "Notify" in the current Windows Qt
>> BLE stack.
>> which then does not trigger our slots:
>>      BLEObject::characteristcStateChanged
>>      BLEObject::characteristicWritten
>>
>> as far as i can tell this is a Windows Qt BLE issue - waiting on a
>> response from the QtConnectivity folks.
>>
>> but one strange thing here is that the document says that the second
>> characteristic should be in a "Notify" state from the start, which is
>> not the case for my OSTC+.
>> so i'm still not sure if this is specific to this prototype.
>>
>> if you or someone else with a OSTC+ can confirm to me what the initial
>> parameters of the OSTC+ 's second characteristic are, i would
>> appreciate it.
>> is it "Write without response" or "Notify" and on what OS / platform?
>>
>> cc Anton as i see him as a libdc contributor in this area.
>
>
>
> Checking with nfConnect on Android. Characteristic 2 is Notify. 1 is write
> no response, 3 is write and 4 is indicate. Exactly as is written in the TIO
> document sections 6.2 .. 6.5 All this by scanning my OSTC3
>

thank you,

i forgot about nrfConnect on Android...just tried that myself and the
second characteristic is indeed Notify.
so the device is fine.

the Qt BLE Windows stack on the other hand detects it as "Write
without response".
this has to be investigated - possible bug.

i hope it's a matter of fixing some of the flags here:
https://msdn.microsoft.com/en-us/library/windows/hardware/hh450840(v=vs.85).aspx
and not being an API level bug.

lubomir
--


More information about the subsurface mailing list