Mares Smart Dive Computer + Bluelink pro

[Fabio Capriati]

Hi,
I'm new here. I open a thread here to track this issue if someone is
interested to.
I chated with Dirk and Linus about Mares Smart computer and Bluelink
interface issue.
That's last Linus' mail with the problem analysis.

Bye
Fabio


---------- Forwarded message ---------
From: Linus Torvalds <torvalds at linux-foundation.org>
Date: dom 23 set 2018 alle ore 03:01
Subject: Re: Mares Smart Dive Computer
To: <fabio.capriati at gmail.com>, Subsurface Mailing List <
subsurface at subsurface-divelog.org>
Cc: Dirk Hohndel <dirk at hohndel.org>


On Sat, Sep 22, 2018 at 2:48 PM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> This looks odd, [..]
>
> I need to stare at the code. I suspect this is a more complex set of
> descriptors than what we've seen before, and I'm thinking that our use
> of the QT GATT interfaces is just fundamentally wrong, but happened to
> work with the simpler serives exposed by the devices we already
> support.

Ok, I think I see what's going on.

We've done the service discovery, and then we pick the first
non-standard service and decide that's our preferred service. And we
wait for the discovery of the characteristics of *that* service to
end, but when there are multiple services, the other discovery may
still be going on.

This hasn't shown up on the Suunto or Shearwater dive computers I
have, simply because they only have one single non-standard service.

So we have two issues:

 - I think we picked the wrong service to begin with for the Mares case

 - the debug log looks horribly messy because some of the discovery is
still going on while we try to start doing IO on that service

I have a patch that I think works around the debug issue, and that I
think will also make it easier to do a better job at picking the right
service (but that second thing is *not* done yet).

Dirk (and anybody else who is interested in debugging BLE), does the
attached patch work for you? It *shouldn't* change any behavior, but
it should result in much better debug output, looking something like
this (this is my Garmin Descent, which I also don't have working, but
that has a fairly complex GATT setup:

Found service "{00001800-0000-1000-8000-00805f9b34fb}" "Generic Access"
   c: "{00002a00-0000-1000-8000-00805f9b34fb}"
   c: "{00002a01-0000-1000-8000-00805f9b34fb}"
   c: "{00002a04-0000-1000-8000-00805f9b34fb}"
   c: "{00002aa6-0000-1000-8000-00805f9b34fb}"
Found service "{00001801-0000-1000-8000-00805f9b34fb}" "Generic Attribute"
   c: "{00002a05-0000-1000-8000-00805f9b34fb}"
        d: "{00002902-0000-1000-8000-00805f9b34fb}"
Found service "{6a4e2401-667b-11e3-949a-0800200c9a66}" "Unknown Service"
   c: "{6a4e4c80-667b-11e3-949a-0800200c9a66}"
   c: "{6a4ecd28-667b-11e3-949a-0800200c9a66}"
        d: "{00002902-0000-1000-8000-00805f9b34fb}"
Found service "{6a4e8022-667b-11e3-949a-0800200c9a66}" "Unknown Service"
   c: "{6a4e4c80-667b-11e3-949a-0800200c9a66}"
   c: "{6a4ecd28-667b-11e3-949a-0800200c9a66}"
        d: "{00002902-0000-1000-8000-00805f9b34fb}"
Found service "{6a4e2500-667b-11e3-949a-0800200c9a66}" "Unknown Service"
   c: "{6a4e2502-667b-11e3-949a-0800200c9a66}"
        d: "{00002902-0000-1000-8000-00805f9b34fb}"
   c: "{6a4e2503-667b-11e3-949a-0800200c9a66}"
        d: "{00002902-0000-1000-8000-00805f9b34fb}"
   c: "{6a4e2504-667b-11e3-949a-0800200c9a66}"
        d: "{00002902-0000-1000-8000-00805f9b34fb}"
   c: "{6a4e2505-667b-11e3-949a-0800200c9a66}"
        d: "{00002902-0000-1000-8000-00805f9b34fb}"
   c: "{6a4e2501-667b-11e3-949a-0800200c9a66}"
        d: "{00002902-0000-1000-8000-00805f9b34fb}"
 .. ignoring standard service "{00001800-0000-1000-8000-00805f9b34fb}"
 .. ignoring standard service "{00001801-0000-1000-8000-00805f9b34fb}"
Using service "{6a4e2401-667b-11e3-949a-0800200c9a66}" as preferred service

which shows *all* the services, their characteristics, and the
descriptors. It also shows exactly which service we ended up using as
the preferred one.

You can see above how there are three non-standard services on the
Garmin (the "Unknown Service") ones, and how we just randomly pick the
first one as the preferred one.  That's likely wrong for the Garmin,
but we have other issues too (ie unlike the Mares I haven't even
figured out what the protocol is).

I think the Mares has two non-standard services:

Found service "{544e326b-5b72-c6b0-1c46-41c1bc448118}"
Found service "{a86abc2d-d44c-442e-99f7-80059a873e36}"

but it would be interesting to see the whole service -> characteristic
-> descriptor tree.

I think I could figure it out by looking at your trace, but damn,
reading those GATT traces to figure out the descriptors is painful.

Anyway, still working on this all.

               Linus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20180924/ef644f15/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: application/x-patch
Size: 5909 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20180924/ef644f15/attachment-0001.bin>