Hey Jason, I've just updated to version 10.66 via HWOS Config App for Android.
Jason Bramwell <jb2c...@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@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 < > torva...@linux-foundation.org>: > >> On Thu, May 21, 2020 at 1:30 PM Dirk Hohndel <d...@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@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > >
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface