[TEST REQUEST] Windows Bluetooth LE build

[Jan Mulder]

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.

--jan