Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Tue, Sep 25, 2018 at 11:52 AM Fabio Capriati
<fabio.capriati at gmail.com> wrote:
>
> Here the log with Linus' patch.

Thanks.

> Found service "{00001800-0000-1000-8000-00805f9b34fb}" "Generic Access"
>    c: "{00002a00-0000-1000-8000-00805f9b34fb}"
>    c: "{00002a01-0000-1000-8000-00805f9b34fb}"
> Found service "{544e326b-5b72-c6b0-1c46-41c1bc448118}" "Unknown Service"
>    c: "{1d1aae28-d2a8-91a1-1242-9d2973fbe571}"
>         d: "{00002902-0000-1000-8000-00805f9b34fb}"
>    c: "{99a91ebd-b21f-1689-bb43-681f1f55e966}"
>    c: "{d8b3ab7c-4101-ec80-c441-9b0914f6ebc3}"
> Found service "{0000180a-0000-1000-8000-00805f9b34fb}" "Device Information"
>    c: "{00002a29-0000-1000-8000-00805f9b34fb}"
>    c: "{00002a24-0000-1000-8000-00805f9b34fb}"
>    c: "{00002a28-0000-1000-8000-00805f9b34fb}"
>    c: "{00002a23-0000-1000-8000-00805f9b34fb}"
> Found service "{0000180f-0000-1000-8000-00805f9b34fb}" "Battery Service"
>    c: "{00002a19-0000-1000-8000-00805f9b34fb}"
> Found service "{a86abc2d-d44c-442e-99f7-80059a873e36}" "Unknown Service"
>    c: "{1bd19c14-b78a-4e0f-aeb5-8e0352bac382}"
>         d: "{00002902-0000-1000-8000-00805f9b34fb}"
>    c: "{279f9dab-79be-4663-af1d-24407347af13}"
>    c: "{6aa5711b-0376-44f1-bca1-8647b48bdb55}"
>  .. ignoring standard service "{00001800-0000-1000-8000-00805f9b34fb}"
> Using service "{544e326b-5b72-c6b0-1c46-41c1bc448118}" as preferred service

All looks good.

>  .. enabling notifications
> Using read characteristic "{1d1aae28-d2a8-91a1-1242-9d2973fbe571}"
> now writing "0x0100" to the descriptor "{00002902-0000-1000-8000-00805f9b34fb}"
> Write descriptor with handle  9 "0100" (service: "{544e326b-5b72-c6b0-1c46-41c1bc448118}" )

Yup, now we actually write that "enable notifications", so things have improved.

> Write characteristic with handle  10 "c267" (service: "{544e326b-5b72-c6b0-1c46-41c1bc448118}" , writeWithResponse: false , signed: false )
> Descriptor write confirmation "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 9 "0100" QLowEnergyService::ServiceError(NoError)
> BLE write completed

All good. This "c267" is the "version command" that libdivecomputer sends:

        // Send the version command.
        unsigned char command[] = {0xC2, 0x67};
        status = mares_iconhd_transfer (device, command, sizeof (command),
                device->version, sizeof (device->version));


> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "aa00000000000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000000000000536d61727400000000"

.. and this is actually us getting the reply, too, so everything looks fine.

Except we should be getting 140 bytes of reply, and apparently we only
got 80 bytes, and then we give up:

> Finishing download thread: "Errore all'apertura di LE:00:1A:85:E0:0C:23 Mares (Smart).\nDi solito per capire il problema è utile mandare i file di log agli sviluppatori. Puoi copiarli nella clipboard attraverso la maschera Informazioni."

This is apparently the Italian translation of

   Error opening the device

from when dc_device_open() fails. But the aboce means that we actually
got a *lot* further.

> no new dives downloaded
> "25.493: DCDownloadThread finished"

But not quite there.

> ---------- libdivecomputer.log ----------
> Subsurface: v4.8.2-45-g0d886f2e07ba, built with libdivecomputer v0.7.0-devel-Subsurface-NG (f705ddefa8497e93ea68af0f5e74d301662175de)
> INFO: Open: transport=32
> INFO: Configure: baudrate=115200, databits=8, parity=2, stopbits=0, flowcontrol=0
> INFO: Timeout: value=1000
> INFO: DTR: value=0
> INFO: RTS: value=0
> INFO: Purge: direction=3
> INFO: Write: size=2, data=C267
> INFO: Read: size=0, data=
> ERROR: Failed to receive the answer. [in /data/android/subsurface/libdivecomputer/src/mares_iconhd.c:172 (mares_iconhd_transfer)]

The problem _looks_ like it's simply that it didn't get the whole 140 bytes.

On the whole, your trace actually makes me think that the bluetooth
download succeeded, but there might just have been an IO error.

Can you try a few more times to see if it was just a temporary
bluetooth packet loss or something? And I will look more at the code
whether we should perhaps add a few more debug statements.

In particular, it would probably be good to have some timestamping. It
would also likely be good to actually have a debug statement that we
actually triggered the right characteristcStateChanged() handling when
that incoming data happened.

But it really looks like the code is very close, or even possibly correct.

               Linus