On 11-06-18 19:20, Lubomir I. Ivanov wrote:
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.
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
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
