On Fri, Apr 27, 2018 at 11:25 AM Dirk Hohndel <d...@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
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
