On 11 June 2018 at 20:00, Jan Mulder <jlmul...@xs4all.nl> wrote: > On 11-06-18 18:29, Lubomir I. Ivanov wrote: >> >> On 11 June 2018 at 18:16, Lubomir I. Ivanov <neolit...@gmail.com> wrote: >>> >>> On 11 June 2018 at 17:49, Dirk Hohndel <d...@hohndel.org> wrote: >>>> >>>> >>>>> On Jun 10, 2018, at 5:36 PM, Lubomir I. Ivanov <neolit...@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. thanks. lubomir -- _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface