Mares Puck Pro Plus via Bluetooth (Mares Bluelink Pro)

[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?

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.

--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