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