Import dives from Cressi Cartesio
Linus Torvalds
torvalds at linux-foundation.org
Mon Feb 17 12:47:46 PST 2020
On Mon, Feb 17, 2020 at 12:08 PM Martin de Weger <martin at deweger.org> wrote:
>
> It looks like it is not recognized as dive computer.
No, that part is ok. But the logs look a bit garbled, but that is just
an artifact of the asynchronous device discovery.
So there's a few random
Found new device: "" "LE:{8fac5ff0-c2cb-4478-a931-92e8d02dc56a}"
Not recognized as dive computer
sprinkled around, but they are just other devices.
For the Cartesio, we're doing this:
qt_ble_open( {b3c70fef-954e-457d-bc92-ba8c819c3bf9} )
trying to connect
...
F ound new device: "Cartesio" "LE:{b3c70fef-954e-457d-bc92-ba8c819c3bf9}"
"this could be a Cressi Cartesio"
connected to the controller for device {b3c70fef-954e-457d-bc92-ba8c819c3bf9}
.. discovering services
Found service "{0000180a-0000-1000-8000-00805f9b34fb}"
.. ignoring standard service "{0000180a-0000-1000-8000-00805f9b34fb}"
Found service "{0000180f-0000-1000-8000-00805f9b34fb}"
.. ignoring standard service "{0000180f-0000-1000-8000-00805f9b34fb}"
Found service "{0000fe59-0000-1000-8000-00805f9b34fb}"
.. ignoring standard service "{0000fe59-0000-1000-8000-00805f9b34fb}"
Found service "{6e400001-b5a3-f393-e0a9-e50e24dc10b8}"
.. created service object QLowEnergyService(0x7fc2557cd310)
Found service "{6e400001-b5a3-f393-e0a9-e50e24dcca9e}"
.. created service object QLowEnergyService(0x7fc25665e640)
.. done discovering services
Found service "{6e400001-b5a3-f393-e0a9-e50e24dc10b8}" "Unknown Service"
c: "{6e400001-b5a3-f393-e0a9-e50e24dc10b8}"
c: "{6e400002-b5a3-f393-e0a9-e50e24dc10b8}"
d: "{00002902-0000-1000-8000-00805f9b34fb}"
c: "{6e400003-b5a3-f393-e0a9-e50e24dc10b8}
c: "{6e400004-b5a3-f393-e0a9-e50e24dc10b8}"
c: "{6e400005-b5a3f393-e0a9-e50e24dc10b8}"
Found service "{6e400001-b5a3-f393-e0a9-e50e24dcca9e}" "Unknown Service"
c: "{6e400002-b5a3-f393-e0a9-e50e24dcca9e}"
c: "{6e400003-b5a3-f393-e0a9-e50e24dcca9e}"
d: "{00002902-0000-1000-8000-00805f9b34fb}"
Using service "{6e400001-b5a3-f393-e0a9-e50e24dc10b8}" as preferred service
.. enabling notifications
Using read characteristic "{6e400002-b5a3-f393-e0a9-e50e24dc10b8}"
now writing "0x0100" to the descriptor
"{00002902-0000-1000-8000-00805f9b34fb}"
BLE write completed
..
QTime("21:07:03.358") packet SEND "aaaaaa0000000055"
QTime("21:07:03.358") packet WAIT
which all looks reasonable. That final "packet SEND" is us actually
starting the communication, but then we don't get anything back.
But that is because we decide to use the wrong service. As mentioned
earlier, BLE serial transmission isn't standardized, and the Cressi
BLE dongle has a fairly complex set of services and characteristics.
It has a number of standard services (for battery level etc), but it
has _two_ nonstandard unknown services, and we pick the first one.
But it's the second one - the 6e400001-b5a3-f393-e0a9-e50e24dcca9e
service - that is the "Nordic UART service".
But while that is somethign that the Nordic Semi nRF app knows about
(it's from your screenshots earlier), this is very much not something
that subsurface knew about, so subsurface picked the first one of the
two services.
So subsurface was trying to communicate with the wrong BLE service,
and isn't getting any replies.
I just need to figure out a heuristic that goes "use this service for
the Crssi case" without breaking the _other_ heuristics we have for
other cases..
This is the kind of annoying thing that happens with random new BLE
devices. We used to have it every time we saw a new BLE device, we've
just been lucky that our heuristics got good enough that we haven't
seen this in a while.
Linus
More information about the subsurface
mailing list