Import dives from Cressi Cartesio

[Martin de Weger]

I’m glad you can make sense out of this. ;)



Kind regards,

Martin De Weger




> Op 17 feb. 2020, om 21:47 heeft Linus Torvalds <torvalds at linux-foundation.org> het volgende geschreven:
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200217/4ebb82bc/attachment.html>