Subsurface-mobile support request

[Till Schwab]

Hey Jason,
I've just updated to version 10.66 via HWOS Config App for Android.

Jason Bramwell <jb2cool at gmail.com> schrieb am Fr., 22. Mai 2020, 08:46:

> What version of the firmware is your dive computer running? I think there
> were some Bluetooth connectivity issues with certain older versions (I
> cannot recall the details of these). Current versions are hwOS Tech 3.10
> and hwOS Sport 10.66
>
> Sent from my iPhone
>
> On 22 May 2020, at 01:16, Till Schwab via subsurface <
> subsurface at subsurface-divelog.org> wrote:
>
> 
> *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
>>
> <Subsurface_Fehler_Import.jpg>
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200522/f3f652aa/attachment-0001.html>