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 > <[email protected]> het volgende geschreven: > > On Mon, Feb 17, 2020 at 12:08 PM Martin de Weger <[email protected]> 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
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
