Re: Subsurface-mobile support request
On Thu, May 21, 2020 at 3:30 PM Till Schwab 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. Ahh, ok, then it does sound like it might be a "corrupt memory" issue, possibly together with some parsing limitation of ours. Sending Jef a memory dump should clarify. > 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 Heh. I've never used anything but subsurface, but I just assumed there was something else. I only used an OSTC a couple of times (years ago), my loaner was given to other people who needed it more. > 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). Ok, that's just more verification that is almost certainly isn't the BLE communication itself (although the fact that your first try was android made it unlikely - I think that ends up being one of the more tested platforms wrt BLE and subsurface). Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface-mobile support request
Dirk, I don't see a description of the problem in the email thread, so I'm probably missing some context here. Anyway, from a quick inspection of the libdivecomputer logfile, the contents of the compact headers looks suspicious. The first 4 entries all look good: i=0, offset=0, current=1, data=C4160014011C101C1F1A1F0025010024 i=1, offset=16, current=2, data=9C14001405130A2368051C003A020024 i=2, offset=32, current=3, data=8417001405130D071C0621002F030024 i=3, offset=48, current=4, data=0F130014051310005A051A0015040024 The rest of the entries are all 0xFF, which is normal too. Except for the 228th entry: i=228, offset=3648, current=16386, data=0240812005408E400220608120024020 Because this one has the highest dive number (16386), it will be selected as the most recent dive. But that number looks very suspicious to me. I suspect it might be some corrupted data instead of an actual dive. So if we try to retrieve that dive, I wouldn't be surprised if things go wrong. I can't really tell what happened, because the log appears to be truncated at this point. @Till: Any chance you can download a full memory dump of your OSTC? You probably need to use the desktop version of subsurface for that. Or the libdivecomputer dctool command-line application. I'll likely also need the full log from a normal download. If this indeed turns out to be a corrupted logbook entry, then we can probably fix it by erasing the problematic logbook entry. Jef ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface-mobile support request
On Thu, May 21, 2020 at 1:30 PM Dirk Hohndel wrote:
>
> This looks like we are starting communication, but then all we get back from
> the OSTC Sport is 0x
>
> Any ideas?
The BLE side looks good and normal.
>> Service discovery initiated
>> Found service "{1800--1000-8000-00805f9b34fb}"
>> .. ignoring standard service
>> Found service "{1801--1000-8000-00805f9b34fb}"
>> .. ignoring standard service
>> Found service "{180a--1000-8000-00805f9b34fb}"
>> .. ignoring standard service
>> Found service "{fefb--1000-8000-00805f9b34fb}"
>> .. recognized service Heinrichs-Weikamp
>> .. starting discovery
>> Discovery of "{fefb--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 "fefb--1000-8000-00805f9b34fb" discovered (start: 10 end: 22
>> ) QLowEnergyServicePrivate(0x6fd41feb50)
>> Found service "{fefb--1000-8000-00805f9b34fb}" "Unknown Service"
>>c: "{0001--1000-8000-00802500}"
>> d: "{2902--1000-8000-00805f9b34fb}"
>>c: "{0002--1000-8000-00802500}"
>> d: "{2902--1000-8000-00805f9b34fb}"
>>c: "{0003--1000-8000-00802500}"
>> d: "{2902--1000-8000-00805f9b34fb}"
>>c: "{0004--1000-8000-00802500}"
>> d: "{2902--1000-8000-00805f9b34fb}"
>> Using service "{fefb--1000-8000-00805f9b34fb}" as preferred service
>> .. enabling notifications
looking good so far, and:
>> Write descriptor with handle 22 "0200" (service:
>> "{fefb--1000-8000-00805f9b34fb}" )
>> Write characteristic with handle 17 "ff" (service:
>> "{fefb--1000-8000-00805f9b34fb}" , writeWithResponse: true , signed:
>> false )
>> Descriptor write confirmation "{fefb--1000-8000-00805f9b34fb}" 22
>> "0200" QLowEnergyService::NoError
>> BLE write completed
>> Descriptor write confirmation "{fefb--1000-8000-00805f9b34fb}" 16
>> "0100" QLowEnergyService::NoError
>> BLE write completed
>> Characteristic write confirmation "{fefb--1000-8000-00805f9b34fb}"
>> 17 "ff" QLowEnergyService::NoError
>> Characteristic change notification "{fefb--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 mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
