Cleaned up and rebased "libdivecomputer-NG" branch

[Linus Torvalds]

On Fri, Apr 27, 2018 at 11:25 AM Dirk Hohndel <dirk at hohndel.org> 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:
QLowEnergyController::ControllerState(ConnectedState)
> 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* =
true"));
     QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
false"));

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?

                       Linus