Cleaned up and rebased "libdivecomputer-NG" branch

Linus Torvalds torvalds at
Fri Apr 27 11:46:39 PDT 2018

On Fri, Apr 27, 2018 at 11:25 AM Dirk Hohndel <dirk at> wrote:

> Through literally several dozen tries and reboots and random sequences, I
got my
> old BT-only Mac to connect with the Petrel 2 in order to do a Firmware
update to
> the latest (53).
> I then finally got Android to connect at all.

Ok, so the firmware update at least made some change. That's a good sign,
in that it does imply that at least _some_ of the problems were due to a
bug that the Shearwater people knew about and fixed.

> This is in no cloud mode, empty log file:

> "4.696: DCDownloadThread started for Petrel 2 on LE:00:13:43:0D:2B:30"
> Starting download from  BT
> Starting the thread 0
> "4.698: dc_descriptor_get_transports"
> "4.698: SERIAL BT BLE "
> "4.698: get_supported_transports returns"
> "4.698: BLE "
> Creating Android Central/Client support for BTLE
> qt_ble_open( 00:13:43:0D:2B:30 )
> Connection updated: error: QLowEnergyController::Error(NoError) oldState:
QLowEnergyController::ControllerState(ConnectingState) newState:
> connected to the controller for device 00:13:43:0D:2B:30
>    .. discovering services
> Service discovery initiated
> Found service "{00001800-0000-1000-8000-00805f9b34fb}"
>   .. ignoring standard service
> Found service "{0000180a-0000-1000-8000-00805f9b34fb}"
>   .. ignoring standard service
> Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
>   .. created service object QLowEnergyService(0xc52d6de0)
> Discovery of "{fe25c237-0ece-443c-b0aa-e02033e7029d}" started
> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end:
9 ) QLowEnergyServicePrivate(0xc5271c00)
>   .. done discovering services
>   .. discovering details
>   .. enabling notifications

Ok, this all looks successful.

> Deleting BLE object
> "4.929: No new dives downloaded from dive computer"

Hmm. I'm not seeing any errors here either, but I'm surprised to not see
any actual *communication* debugging.

I wonder if that got turned off in your version of Qt? Because all the
messages above are our _own_ qdebug output.

The actual *data* transfer debugging is from qt itself, and we turn it on
and off with

     QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
     QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =

and I wonder if maybe Qt itself stopped doing those debug messages?

For example, on my desktop, I see not just the "Found service" messages
that we output, I also see a lot of other debug data from Qt itself:

   Sending read_by_group_type request, startHandle: b endHandle: ffff 2800
   Received size: 22 data: "11140b00ffff9d02e73320e0aab03c44ce0e37c225fe"
   Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}" start handle: b end
handle: ffff
   Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"

and your log doesn't have any of that. So then the fact that you *also*
don't have the actual IO debugging actually makes sense.

> Finishing the thread Dive data import error dives downloaded 0
> no new dives downloaded
> "4.932: DCDownloadThread finished”

Because this would all be successful for the "no dives on the dive
computer" case other than the complete lack of debug messages..

> So we are successfully connecting, are discovering the services and then
we give
> up right away. Not sure if this adds any more useful information, but I
thought I’d
> pass it along.

I think "we give up right away" may actually be "we exchanged just a couple
of packets and found that there were no dives".

Did the firmware update perhaps reset the dive computer entirely and remove
all dives on the dive computer?


More information about the subsurface mailing list