Mares Puck Pro Plus via Bluetooth (Mares Bluelink Pro)

Christian Schneider christian at ch-sc.de
Thu Jan 11 00:03:29 PST 2018


Thx for looking into this!
Hm, is there some possibility to test/debug qt ble then? Or should I
check (and how) if there is an even lower level problem (kernel/bluez)?
BR, Christian

Am 10.01.2018 um 22:02 schrieb Linus Torvalds:
> On Wed, Jan 10, 2018 at 10:58 AM, Christian Schneider
> <christian at ch-sc.de> wrote:
>>
>> I attached the log from libdc and from Subsurface itself, as the libdc
>> log isn't very long and the Subsurface log seems to contain some
>> communication.
> 
> Subsurface finds the service, but then when it tries to discover the
> details, we never seem to finish service discovery.
> 
> You can see the "discovering details" phase in the log, but then it
> doesn't get to "enabling notifications" which is where we start to
> really talk to the device.
> 
> It fails with "failed to find suitable service on 00:1A:85:E0:0B:FA",
> which just means that the Qt BLE service state never went to
> ServiceDiscovered.
> 
> (Well, "never" here means "within BLE_TIMEOUT", which is 12 seconds).
> 
> So it never gets to the actual communication phase.
> 
> I'm not sure why that happens. This is all still pretty much entirely
> the QT BLE connection phase, there's not really any subsurface or
> libdivecomputer part to it all.
> 
>             Linus
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 293 bytes
Desc: OpenPGP digital signature
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20180111/1a613293/attachment-0001.sig>


More information about the subsurface mailing list