Linus Torvalds
2018-09-24 18:36:46 UTC
Ok, so I've parsed the bluetooth logs that were provided by Allen Hall
(back in April) and by Fabio Capriati (recently), and I think I see
what is going wrong.
We actually do *almost* the right thing. We even pick the right GATT
service from the device.
It looks like (if I'm reading things correctly) that device has a service
544E326B-5B72-C6B0-1C46-41C1BC448118
which in turn has a few characteristics:
1d1aae28-d2a8-91a1-1242-9d2973fbe571
99a91ebd-b21f-1689-bb43-681f1f55e966
and that characteristic 1d1aae28 then has a "Client Characteristic
Configuration" descriptor to enable notifications and we'll get the
read data from that. And we just do a write to the 99a91ebd one.
That part is actually exactly what we expect: enable notifications on
one characteristic, and write to another. And the protocol is the
exact same normal Mares protocol that libdivecomputer already
supports.
So it should all just work, EXCEPT there is *third* characteristic on
that service too with uuid
d8b3ab7c-4101-ec80-c441-9b0914f6ebc3
and that's the thing that seems to mess us up.
We end up trying to enable notifications on that third characteristic,
because our logic to pick the read-vs-write ones is way way too
simplistic. We basically assume that the notifications come in on the
last characteristic, and that the writes go out on the first
characteristic. Both of which are wrong for this one.
But from everything I see, I think that the Mares code should just
magically start working if I fix that stupid choice of
characteristics.
I'm hoping to have hardware to test by Thursday, but I'm actually
hoping I could have a test-patch for people to try before that.
Because the Mares BLE case really looks like we should be able to get
it working fairly trivially.
Unlike the Garmin Descent, which still confuses the heck out of me,
despite me having the hardware to look at and traces to follow.
Linus
(back in April) and by Fabio Capriati (recently), and I think I see
what is going wrong.
We actually do *almost* the right thing. We even pick the right GATT
service from the device.
It looks like (if I'm reading things correctly) that device has a service
544E326B-5B72-C6B0-1C46-41C1BC448118
which in turn has a few characteristics:
1d1aae28-d2a8-91a1-1242-9d2973fbe571
99a91ebd-b21f-1689-bb43-681f1f55e966
and that characteristic 1d1aae28 then has a "Client Characteristic
Configuration" descriptor to enable notifications and we'll get the
read data from that. And we just do a write to the 99a91ebd one.
That part is actually exactly what we expect: enable notifications on
one characteristic, and write to another. And the protocol is the
exact same normal Mares protocol that libdivecomputer already
supports.
So it should all just work, EXCEPT there is *third* characteristic on
that service too with uuid
d8b3ab7c-4101-ec80-c441-9b0914f6ebc3
and that's the thing that seems to mess us up.
We end up trying to enable notifications on that third characteristic,
because our logic to pick the read-vs-write ones is way way too
simplistic. We basically assume that the notifications come in on the
last characteristic, and that the writes go out on the first
characteristic. Both of which are wrong for this one.
But from everything I see, I think that the Mares code should just
magically start working if I fix that stupid choice of
characteristics.
I'm hoping to have hardware to test by Thursday, but I'm actually
hoping I could have a test-patch for people to try before that.
Because the Mares BLE case really looks like we should be able to get
it working fairly trivially.
Unlike the Garmin Descent, which still confuses the heck out of me,
despite me having the hardware to look at and traces to follow.
Linus