[TEST REQUEST] Windows Bluetooth LE build

[Anton Lundin]

On 11 June, 2018 - 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.

I haven't played around with BLE that much, but I have a OSTC4 which I
can test things against, but no windows around.

On the higher layers of libdc, it doesn't care if its serial, BT or
BTLE, the protocol to talk with OSTC3's (OSTC3, OSTC+, OSTC Sport,
OSTC2, OSTC4 and so on) are all the same.

It's Jan who figured out how to talk with the BLE chip in those, and its
some sort of quasi-standard "serial over BLE" or something.

The current BLE code in Subsurface works just great against the OSTC4 I
got, on both android and Linux.


//Anton


-- 
Anton Lundin	+46702-161604