<div dir="ltr"><b>Till - has this worked before with that OSTC? </b><br><div>This is my first OSTC and therefore the first time that I use the OSTC with subsurface.<br></div><div><br></div><div><b>Does the official HW downloader work? </b></div><div>What is the official HW downloader? As far as I know, there is only second-party software for OSTC Sport <br></div><div><br></div><div><b>And the obvious: does it help to reset the thing by turning it off and on again with removal of battery? <br></b></div><div>No, I just tested it. Unfortunately no improvement.<b><br></b></div><div><br></div><div>By the way, the download / connection with the Windows 10 software also does not work (see jpg. in the appendix).<br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Do., 21. Mai 2020 um 22:51 Uhr schrieb Linus Torvalds <<a href="mailto:torvalds@linux-foundation.org">torvalds@linux-foundation.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, May 21, 2020 at 1:30 PM Dirk Hohndel <<a href="mailto:dirk@hohndel.org" target="_blank">dirk@hohndel.org</a>> wrote:<br>
><br>
> This looks like we are starting communication, but then all we get back from the OSTC Sport is 0xFFFF<br>
><br>
> Any ideas?<br>
<br>
The BLE side looks good and normal.<br>
<br>
>> Service discovery initiated<br>
>> Found service "{00001800-0000-1000-8000-00805f9b34fb}"<br>
>> .. ignoring standard service<br>
>> Found service "{00001801-0000-1000-8000-00805f9b34fb}"<br>
>> .. ignoring standard service<br>
>> Found service "{0000180a-0000-1000-8000-00805f9b34fb}"<br>
>> .. ignoring standard service<br>
>> Found service "{0000fefb-0000-1000-8000-00805f9b34fb}"<br>
>> .. recognized service Heinrichs-Weikamp<br>
>> .. starting discovery<br>
>> Discovery of "{0000fefb-0000-1000-8000-00805f9b34fb}" started<br>
>> .. done discovering services<br>
<br>
Ok, so this is triggering the new code that actually recognizes the<br>
service ID, but for the case of the OSTC, that's actually not that<br>
different from what it used to do (HW already had the special UUID<br>
trigger).<br>
<br>
And it clearly does pick that service:<br>
<br>
>> Service "0000fefb-0000-1000-8000-00805f9b34fb" discovered (start: 10 end: 22 ) QLowEnergyServicePrivate(0x6fd41feb50)<br>
>> Found service "{0000fefb-0000-1000-8000-00805f9b34fb}" "Unknown Service"<br>
>> c: "{00000001-0000-1000-8000-008025000000}"<br>
>> d: "{00002902-0000-1000-8000-00805f9b34fb}"<br>
>> c: "{00000002-0000-1000-8000-008025000000}"<br>
>> d: "{00002902-0000-1000-8000-00805f9b34fb}"<br>
>> c: "{00000003-0000-1000-8000-008025000000}"<br>
>> d: "{00002902-0000-1000-8000-00805f9b34fb}"<br>
>> c: "{00000004-0000-1000-8000-008025000000}"<br>
>> d: "{00002902-0000-1000-8000-00805f9b34fb}"<br>
>> Using service "{0000fefb-0000-1000-8000-00805f9b34fb}" as preferred service<br>
>> .. enabling notifications<br>
<br>
looking good so far, and:<br>
<br>
>> Write descriptor with handle 22 "0200" (service: "{0000fefb-0000-1000-8000-00805f9b34fb}" )<br>
>> Write characteristic with handle 17 "ff" (service: "{0000fefb-0000-1000-8000-00805f9b34fb}" , writeWithResponse: true , signed: false )<br>
>> Descriptor write confirmation "{0000fefb-0000-1000-8000-00805f9b34fb}" 22 "0200" QLowEnergyService::NoError<br>
>> BLE write completed<br>
>> Descriptor write confirmation "{0000fefb-0000-1000-8000-00805f9b34fb}" 16 "0100" QLowEnergyService::NoError<br>
>> BLE write completed<br>
>> Characteristic write confirmation "{0000fefb-0000-1000-8000-00805f9b34fb}" 17 "ff" QLowEnergyService::NoError<br>
>> Characteristic change notification "{0000fefb-0000-1000-8000-00805f9b34fb}" 20 "17"<br>
<br>
Yeah, IO is working and data is transferring. At least to begin with.<br>
<br>
The libdivecomputer log is more clear about the actual data transfer,<br>
but they look fine too - all the way until it just starts sending all<br>
FF (with then very occasional noise of other things that again look<br>
like valid data).<br>
<br>
But that odd stream of FF doesn't _look_ like our BLE code would be<br>
the cause of it. At least not the core code.<br>
<br>
It could be some artifact of the magical HW serial flow control code<br>
(the whole "hw_credit" thing), but I do not know that code at all.<br>
That was all Jan Mulder, I think. But none of that has changed lately.<br>
<br>
Till - has this worked before with that OSTC? Does the official HW<br>
downloader work?<br>
<br>
And the obvious: does it help to reset the thing by turning it off and<br>
on again with removal of battery?<br>
<br>
Linus<br>
</blockquote></div>