Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Tue, Sep 25, 2018 at 1:33 PM Fabio Capriati <fabio.capriati at gmail.com> wrote:
>>
>> Mmmm ... Probably in previous log the computer gets out from pc mode ... That's this is better (only 3 time download)

It's really really close.

So here we write the "read version" command:

> Write characteristic with handle  10 "c267" (service: "{544e326b-5b72-c6b0-1c46-41c1bc448118}" , writeWithResponse: false , signed: false )
> Descriptor write confirmation "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 9 "0100" QLowEnergyService::ServiceError(NoError)
> BLE write completed
> Characteristic write confirmation "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 10 "c267" QLowEnergyService::ServiceError(NoError)
> BLEObject::characteristicWritten

and then we start getting the reply:

> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "aa00000000000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000000000000536d61727400000000"

but we give up:

> Finishing download thread: "Errore all'apertura di LE:00:1A:85:E0:0C:23 Mares (Smart).\nDi solito per capire il problema è utile mandare i file di log agli sviluppatori. Puoi copiarli nella clipboard attraverso la maschera Informazioni."
> no new dives downloaded
> "20.502: DCDownloadThread finished"
> "localDevice OnePlus 3 is valid, starting discovery"

and then you try again:

> "31.015: DCDownloadThread started for Mares Smart on LE:00:1A:85:E0:0C:23"
> Starting download from  BT
> Creating Android Central/Client support for BTLE
> qt_ble_open( 00:1A:85:E0:0C:23 )

.. and look, here's the rest of the reply that we didn't fully get on
the previous download:

> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "000000000030322e30312e30300201000031352d"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "30352d313760f1536d617274204d617265730000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "00000000000000000000000000000000000000ea"

but now we're just starting from scratch and do it all over, write a
new "get version" command:

> Write characteristic with handle  10 "c267" (service: "{544e326b-5b72-c6b0-1c46-41c1bc448118}" , writeWithResponse: false , signed: false )
> Descriptor write confirmation "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 9 "0100" QLowEnergyService::ServiceError(NoError)
> BLE write completed
> Characteristic write confirmation "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 10 "c267" QLowEnergyService::ServiceError(NoError)
> BLEObject::characteristicWritten

and we start getting the data:

> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "aa00000000000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "aa00000000000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000000000000000000000000000000"

.. and we give up halfway again, although now we get some *other*
stale data from a previous read command too (note the two copies of
the "aa0000.." thing: "aa" is "ACK" and starts a reply.

> Finishing download thread: "Errore all'apertura di LE:00:1A:85:E0:0C:23 Mares (Smart).\nDi solito per capire il problema è utile mandare i file di log agli sviluppatori. Puoi copiarli nella clipboard attraverso la maschera Informazioni."
> no new dives downloaded
> "47.228: DCDownloadThread finished"

.. and you try a third time:

> "49.552: DCDownloadThread started for Mares Smart on LE:00:1A:85:E0:0C:23"
> Starting download from  BT
> Creating Android Central/Client support for BTLE
> qt_ble_open( 00:1A:85:E0:0C:23 )

and again in the meantime we've gotten lots of old stale data queued,
this is again doubled up:

> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000000000000536d61727400000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000000000000536d61727400000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000030322e30312e3030"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0000000000000030322e30312e3030"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0201000031352d30352d313760f1536d61727420"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "0201000031352d30352d313760f1536d61727420"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "4d61726573000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "4d61726573000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "000000000000ea"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "000000000000ea"

but we skip the old data and write the command *again* since we're
starting a new download:

> Write characteristic with handle  10 "c267" (service: "{544e326b-5b72-c6b0-1c46-41c1bc448118}" , writeWithResponse: false , signed: false )
> Descriptor write confirmation "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 9 "0100" QLowEnergyService::ServiceError(NoError)
> BLE write completed
> Characteristic write confirmation "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 10 "c267" QLowEnergyService::ServiceError(NoError)
> BLEObject::characteristicWritten
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "aa00000000000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "aa00000000000000000000000000000000000000"
> Characteristic change notification "{544e326b-5b72-c6b0-1c46-41c1bc448118}" 7 "aa00000000000000000000000000000000000000"

.. and now we're getting *three* copies of the replies.

So things are *almost* working, but we clearly aren't reading the data itself.

The fact that we have old queued packets makes me think that we
*should* have hit this codepath:

  dc_status_t BLEObject::write(const void *data, size_t size, size_t *actual)
  {
        if (actual) *actual = 0;

        if (!receivedPackets.isEmpty()) {
                qDebug() << ".. write HIT with still incoming packets in queue";

but I'm not seeing that "write HIT with incoming packets" message, so
I'm starting to suspect that we actually never queue the packets up
due to some confusion with the way we registered the
characteristcStateChanged() callback.

I'll look at the code some more, but this might be one of those "I'm
happy I should have my own BlueLink coming in a couple of days".

Because we're clearly *very* close, but I don't see why the reading
side doesn't seem to be seeing the incoming data.

                      Linus