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
<[email protected]> 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
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
