Subsurface-mobile support request

[Linus Torvalds]

On Thu, May 21, 2020 at 1:30 PM Dirk Hohndel <dirk at hohndel.org> wrote:
>
> This looks like we are starting communication, but then all we get back from the OSTC Sport is 0xFFFF
>
> Any ideas?

The BLE side looks good and normal.

>> Service discovery initiated
>> Found service "{00001800-0000-1000-8000-00805f9b34fb}"
>>  .. ignoring standard service
>> Found service "{00001801-0000-1000-8000-00805f9b34fb}"
>>  .. ignoring standard service
>> Found service "{0000180a-0000-1000-8000-00805f9b34fb}"
>>  .. ignoring standard service
>> Found service "{0000fefb-0000-1000-8000-00805f9b34fb}"
>>  .. recognized service Heinrichs-Weikamp
>>  .. starting discovery
>> Discovery of "{0000fefb-0000-1000-8000-00805f9b34fb}" started
>>  .. done discovering services

Ok, so this is triggering the new code that actually recognizes the
service ID, but for the case of the OSTC, that's actually not that
different from what it used to do (HW already had the special UUID
trigger).

And it clearly does pick that service:

>> Service "0000fefb-0000-1000-8000-00805f9b34fb" discovered (start: 10 end: 22 ) QLowEnergyServicePrivate(0x6fd41feb50)
>> Found service "{0000fefb-0000-1000-8000-00805f9b34fb}" "Unknown Service"
>>    c: "{00000001-0000-1000-8000-008025000000}"
>>         d: "{00002902-0000-1000-8000-00805f9b34fb}"
>>    c: "{00000002-0000-1000-8000-008025000000}"
>>         d: "{00002902-0000-1000-8000-00805f9b34fb}"
>>    c: "{00000003-0000-1000-8000-008025000000}"
>>         d: "{00002902-0000-1000-8000-00805f9b34fb}"
>>    c: "{00000004-0000-1000-8000-008025000000}"
>>         d: "{00002902-0000-1000-8000-00805f9b34fb}"
>> Using service "{0000fefb-0000-1000-8000-00805f9b34fb}" as preferred service
>>  .. enabling notifications

looking good so far, and:

>> Write descriptor with handle  22 "0200" (service: "{0000fefb-0000-1000-8000-00805f9b34fb}" )
>> Write characteristic with handle  17 "ff" (service: "{0000fefb-0000-1000-8000-00805f9b34fb}" , writeWithResponse: true , signed: false )
>> Descriptor write confirmation "{0000fefb-0000-1000-8000-00805f9b34fb}" 22 "0200" QLowEnergyService::NoError
>> BLE write completed
>> Descriptor write confirmation "{0000fefb-0000-1000-8000-00805f9b34fb}" 16 "0100" QLowEnergyService::NoError
>> BLE write completed
>> Characteristic write confirmation "{0000fefb-0000-1000-8000-00805f9b34fb}" 17 "ff" QLowEnergyService::NoError
>> Characteristic change notification "{0000fefb-0000-1000-8000-00805f9b34fb}" 20 "17"

Yeah, IO is working and data is transferring. At least to begin with.

The libdivecomputer log is more clear about the actual data transfer,
but they look fine too - all the way until it just starts sending all
FF (with then very occasional noise of other things that again look
like valid data).

But that odd stream of FF doesn't _look_ like our BLE code would be
the cause of it. At least not the core code.

It could be some artifact of the magical HW serial flow control code
(the whole "hw_credit" thing), but I do not know that code at all.
That was all Jan Mulder, I think. But none of that has changed lately.

Till - has this worked before with that OSTC? Does the official HW
downloader work?

And the obvious: does it help to reset the thing by turning it off and
on again with removal of battery?

                      Linus