<div dir="ltr">Hi,<div>I'm new here. I open a thread here to track this issue if someone is interested to. </div><div>I chated with Dirk and Linus about Mares Smart computer and Bluelink interface issue. <br>That's last Linus' mail with the problem analysis.</div><div><br></div><div>Bye</div><div>Fabio<br><br><br><div class="gmail_quote"><div dir="ltr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">Linus Torvalds</strong> <span dir="ltr"><<a href="mailto:torvalds@linux-foundation.org" target="_blank">torvalds@linux-foundation.org</a>></span><br>Date: dom 23 set 2018 alle ore 03:01<br>Subject: Re: Mares Smart Dive Computer<br>To: <<a href="mailto:fabio.capriati@gmail.com" target="_blank">fabio.capriati@gmail.com</a>>, Subsurface Mailing List <<a href="mailto:subsurface@subsurface-divelog.org" target="_blank">subsurface@subsurface-divelog.org</a>><br>Cc: Dirk Hohndel <<a href="mailto:dirk@hohndel.org" target="_blank">dirk@hohndel.org</a>><br></div><br><br>On Sat, Sep 22, 2018 at 2:48 PM Linus Torvalds<br>
<<a href="mailto:torvalds@linux-foundation.org" target="_blank">torvalds@linux-foundation.org</a>> wrote:<br>
><br>
> This looks odd, [..]<br>
><br>
> I need to stare at the code. I suspect this is a more complex set of<br>
> descriptors than what we've seen before, and I'm thinking that our use<br>
> of the QT GATT interfaces is just fundamentally wrong, but happened to<br>
> work with the simpler serives exposed by the devices we already<br>
> support.<br>
<br>
Ok, I think I see what's going on.<br>
<br>
We've done the service discovery, and then we pick the first<br>
non-standard service and decide that's our preferred service. And we<br>
wait for the discovery of the characteristics of *that* service to<br>
end, but when there are multiple services, the other discovery may<br>
still be going on.<br>
<br>
This hasn't shown up on the Suunto or Shearwater dive computers I<br>
have, simply because they only have one single non-standard service.<br>
<br>
So we have two issues:<br>
<br>
- I think we picked the wrong service to begin with for the Mares case<br>
<br>
- the debug log looks horribly messy because some of the discovery is<br>
still going on while we try to start doing IO on that service<br>
<br>
I have a patch that I think works around the debug issue, and that I<br>
think will also make it easier to do a better job at picking the right<br>
service (but that second thing is *not* done yet).<br>
<br>
Dirk (and anybody else who is interested in debugging BLE), does the<br>
attached patch work for you? It *shouldn't* change any behavior, but<br>
it should result in much better debug output, looking something like<br>
this (this is my Garmin Descent, which I also don't have working, but<br>
that has a fairly complex GATT setup:<br>
<br>
Found service "{00001800-0000-1000-8000-00805f9b34fb}" "Generic Access"<br>
c: "{00002a00-0000-1000-8000-00805f9b34fb}"<br>
c: "{00002a01-0000-1000-8000-00805f9b34fb}"<br>
c: "{00002a04-0000-1000-8000-00805f9b34fb}"<br>
c: "{00002aa6-0000-1000-8000-00805f9b34fb}"<br>
Found service "{00001801-0000-1000-8000-00805f9b34fb}" "Generic Attribute"<br>
c: "{00002a05-0000-1000-8000-00805f9b34fb}"<br>
d: "{00002902-0000-1000-8000-00805f9b34fb}"<br>
Found service "{6a4e2401-667b-11e3-949a-0800200c9a66}" "Unknown Service"<br>
c: "{6a4e4c80-667b-11e3-949a-0800200c9a66}"<br>
c: "{6a4ecd28-667b-11e3-949a-0800200c9a66}"<br>
d: "{00002902-0000-1000-8000-00805f9b34fb}"<br>
Found service "{6a4e8022-667b-11e3-949a-0800200c9a66}" "Unknown Service"<br>
c: "{6a4e4c80-667b-11e3-949a-0800200c9a66}"<br>
c: "{6a4ecd28-667b-11e3-949a-0800200c9a66}"<br>
d: "{00002902-0000-1000-8000-00805f9b34fb}"<br>
Found service "{6a4e2500-667b-11e3-949a-0800200c9a66}" "Unknown Service"<br>
c: "{6a4e2502-667b-11e3-949a-0800200c9a66}"<br>
d: "{00002902-0000-1000-8000-00805f9b34fb}"<br>
c: "{6a4e2503-667b-11e3-949a-0800200c9a66}"<br>
d: "{00002902-0000-1000-8000-00805f9b34fb}"<br>
c: "{6a4e2504-667b-11e3-949a-0800200c9a66}"<br>
d: "{00002902-0000-1000-8000-00805f9b34fb}"<br>
c: "{6a4e2505-667b-11e3-949a-0800200c9a66}"<br>
d: "{00002902-0000-1000-8000-00805f9b34fb}"<br>
c: "{6a4e2501-667b-11e3-949a-0800200c9a66}"<br>
d: "{00002902-0000-1000-8000-00805f9b34fb}"<br>
.. ignoring standard service "{00001800-0000-1000-8000-00805f9b34fb}"<br>
.. ignoring standard service "{00001801-0000-1000-8000-00805f9b34fb}"<br>
Using service "{6a4e2401-667b-11e3-949a-0800200c9a66}" as preferred service<br>
<br>
which shows *all* the services, their characteristics, and the<br>
descriptors. It also shows exactly which service we ended up using as<br>
the preferred one.<br>
<br>
You can see above how there are three non-standard services on the<br>
Garmin (the "Unknown Service") ones, and how we just randomly pick the<br>
first one as the preferred one. That's likely wrong for the Garmin,<br>
but we have other issues too (ie unlike the Mares I haven't even<br>
figured out what the protocol is).<br>
<br>
I think the Mares has two non-standard services:<br>
<br>
Found service "{544e326b-5b72-c6b0-1c46-41c1bc448118}"<br>
Found service "{a86abc2d-d44c-442e-99f7-80059a873e36}"<br>
<br>
but it would be interesting to see the whole service -> characteristic<br>
-> descriptor tree.<br>
<br>
I think I could figure it out by looking at your trace, but damn,<br>
reading those GATT traces to figure out the descriptors is painful.<br>
<br>
Anyway, still working on this all.<br>
<br>
Linus<br>
</div></div></div>