On 12-01-18 00:02, Christian Schneider wrote:
Am 11.01.2018 um 09:58 schrieb Jan Mulder:
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).
Ok, despite the message in the first logfile, that did not solve the
issue at hand. Qt 5.9.3 seems to handle it correctly in this case.
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)
That your self build Subsurface does not see your computers BT interface
is weird, and I cannot explain this. I do not know enough about Gentoo,
and how its deals with upgrading stuff like Qt, bluez, etc. but as your
Qt is relatively new, I assume that your bluez stuff is also pretty recent.
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.
No, the connection does not work. There is some communication, but as
Linus already said, the controller never gets into
QLowEnergyService::ServiceDiscovered() state. And before that point,
there is not much Suburface/libdivecomputer processing going on.
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?
No, at least that is something we cannot conclude at this point. As we
are not getting in a phase that we actually have a connection and
interfacing data.
--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
