Hmm. Everything looks good initially:
Found service "{00001800-0000-1000-8000-00805f9b34fb}"
.. ignoring standard service
Found service "{00001801-0000-1000-8000-00805f9b34fb}"
.. ignoring standard service
Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
.. recognized service Shearwater (Perdix/Teric/Peregrine)
starting service characteristics discovery
.. service state changed to QLowEnergyService::DiscoveringServices
.. service state changed to QLowEnergyService::ServiceDiscovered
.. done discovering services
Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}" "Unknown Service"
c: "{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
d: "{00002902-0000-1000-8000-00805f9b34fb}"
d: "{00002901-0000-1000-8000-00805f9b34fb}"
Using service "{fe25c237-0ece-443c-b0aa-e02033e7029d}" as preferred service
.. enabling notifications
and that's all the normal Shearwater GATT services, and we're
recognizing it ("recognized service Shearwater") and picking the
correct one.
But then when we want to enable notifications (to get replies), we have this:
Using read characteristic "{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
now writing "0x0100" to the descriptor
"{00002902-0000-1000-8000-00805f9b34fb}"
error discovering service details QLowEnergyService::DescriptorWriteError
and that "DescriptorWriteError" means that things went south. We
*should* have seen
Descriptor write confirmation
"{fe25c237-0ece-443c-b0aa-e02033e7029d}" 14 "0100"
QLowEnergyService::NoError
BLE write completed
instead.
We then try to send a command anyway:
QTime("21:02:21.768") packet SEND "0100ff0105002e902000c0"
but even if that were to work, we'd never get a reply because the
notifications needed for reading the reply were never enabled. I doubt
it worked, and instead returned and error, and we just do
Deleting BLE object
Finishing download thread: "Dive data import error"
and that's all she wrote.
Anyway, this doesn't much look like the old traditional Shearwater
issues where even just finding the device and doing service discovery
was sometimes a chore and the dive computer just wouldn't respond.
This looks like everything works, but then the dive computer is
explicitly rejecting us writing to it.
Anyway, an inability to enable notifications is almost certainly due
to the dive computer having been paired securely, and probably using a
long-term key (LTK, one that isn't per-connection).
So I would not be surprised at all if what is going on is that the
Shearwater Cloud application did its own private secure pairing, and
then when you try to connect from another machine, or even on the same
machine without subsurface knowing about the LTK, any access will fail
due to key mismatch errors.
It is also quite possible that even if the LTK is maintained by the
system, the QtBluetooth subsystem isn't able to deal with it. We've
actually seem these kinds of errors occasionally before (from
non-Shearwater cases), and the previous cases seem to have been mainly
on Windows (but I see one that looks like MacOS). And QtBluetooth has
traditionally been weakest and had the most problems there.
So in at least one other case downloading from an iphone instead of
the windows machine "fixed" the issue.
You might also try to just explicitly unpair and re-pair the
Shearwater, _without_ running Shearwater Cloud. In case it's that
Shearwater Cloud enables some secure pairing thing.
It might be something entirely different, of course, but from the logs
it really does look like some secure pairing issue where subsurface
doesn't end up using the proper security key.
Linus