Mares Puck Pro Plus via Bluetooth (Mares Bluelink Pro)

[Christian Schneider]

Am 11.01.2018 um 09:58 schrieb Jan Mulder:
> On 11-01-18 09:03, Christian Schneider wrote:
>> 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
> There is a suspicious line in your log: "Cannot connect due to pending
> active LE connections". This is related to an old (but open) Qt bug
> (https://bugreports.qt.io/browse/QTBUG-42519), and the Qt manual says
> this on this subject: "It is important to mention that some platforms
> such as a BlueZ based Linux cannot maintain two connected instances of
> QLowEnergyController to the same remote device. In such cases the second
> call to connectToDevice() may fail."
> 
> As the Subsurface code works fine for other BLE devices like HW OSTC,
> Shearwater and some Scubapro's, I do not believe that we try to connect
> to the device twice (or more).
> 
> Could it be that something else on your computer tries to connect to it
> before we do?

Might be, that this was because I clicked on "connect" in my KDE gui
before starting Subsurface. I tried again without connecting previously
and then this line doesn't appear (log attached again).

> 
> And with respect to test/debug ... well ... you probably have to start
> with building Subsurface yourself (the easy part), and build Qt from
> source (the bit harder part). And as BLE is not standard, I'm not sure
> that when passing the currently open fail, you are out of the woods.
> When you search on BLE OSTC in our email archive, you will find long
> threads related to BLE development.

I'm already building QT as I'm on Gentoo Linux, and I already had build
Subsurface myself too, but with the selfbuild one SubSurface wasn't able
to see my computers BT interface at all, that's why I'm using the
appimage (for now)

I don't know very much about BT, so I'm not really sure what a 'service'
is, that is mentioned in the logs. But my guess would be, that
connection works, since services are found, but the services don't match
what is expected.
I already mentioned that I selected Mares Puck Pro when the actual
device is a Mares Puck Pro Plus. Maybe there is a difference between
these devices and that's causing the trouble?
BR, Christian


> 
> --jan
> 
>>
>> 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: subsurface.log
Type: text/x-log
Size: 16408 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20180112/5930dead/attachment.bin>
-------------- 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/20180112/5930dead/attachment.sig>