[TEST REQUEST] Windows Bluetooth LE build

[Jan Mulder]

On 11-06-18 19:20, Lubomir I. Ivanov wrote:
> On 11 June 2018 at 20:00, Jan Mulder <jlmulder at xs4all.nl> wrote:
>> On 11-06-18 18:29, Lubomir I. Ivanov wrote:
>>>
>>> On 11 June 2018 at 18:16, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>>>>
>>>> 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:
>>>>>>
>>>>>> 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.
>>>>
>>>
>>> after checking the document, i can confirm that the order and flags of
>>> the characteristics (in the service of interest) matches for this
>>> prototype OSTC+.
>>>
>>> Jan, do you remember what procedure we use to verify that second
>>> characteristic (00000002-0000-1000-8000-008025000000) has received the
>>> READY command:
>>>
>>> https://github.com/Subsurface-divelog/libdc/blob/e97a47cca55973199715df0f818b4955e60d3a31/src/hw_ostc3.c#L56
>>>
>>> i can only find the writing of the INIT command to the first
>>> characteristic (00000001-0000-1000-8000-008025000000) in our code
>>> base:
>>>
>>> https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L158
>>
>>
>> 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

--jan