Subsurface-mobile support request

[Jason Bramwell]

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/5baa82e6/attachment.html>