Subsurface-mobile support request

[Till Schwab]

*Till - has this worked before with that OSTC? *
This is my first OSTC and therefore the first time that I use the OSTC with
subsurface.

*Does the official HW downloader work? *
What is the official HW downloader? As far as I know, there is only
second-party software for OSTC Sport


*And the obvious: does it help to reset the thing by turning it off and on
again with removal of battery?  *
No, I just tested it. Unfortunately no improvement.

By the way, the download / connection with the Windows 10 software also
does not work (see jpg. in the appendix).




Am Do., 21. Mai 2020 um 22:51 Uhr schrieb Linus Torvalds <
torvalds at linux-foundation.org>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200522/9bd1a59e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Subsurface_Fehler_Import.jpg
Type: image/jpeg
Size: 150710 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200522/9bd1a59e/attachment-0001.jpg>