On Tue, Sep 25, 2018 at 10:26 PM Fabio Capriati
<[email protected]> wrote:
>
> I feel me like a candy machine :)
> Here the last version log.
Whee.
Ok, so looking just at the new debugging..
First we write the command packet:
> QTime("07:19:17.790") packet SEND "c267"
and then do the read of the result, but because no packets have come
in yet, we hit the WAIT case:
> QTime("07:19:17.792") packet WAIT
Then the packets start coming in:
> QTime("07:19:19.758") packet RECV "aa00000000000000000000000000000000000000"
> QTime("07:19:19.761") packet RECV "00000000000000"
> QTime("07:19:19.764") packet RECV "0000000000000000000000000000000000000000"
> QTime("07:19:19.766") packet RECV "0000000000000000000000000000000000000000"
but this is the asynchronous "packet received" side, it is *not* the
actual READ part.
And in fact, we never seem to read the packets at all, we end up just
riming out:
> Finishing download thread: "Errore all'apertura di LE:00:1A:85:E0:0C:23 Mares
> (Quad).\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
and all your other downloads show the exact same issue. The packets
come in, but they never get read.
Very odd. That same function that prints out the "packet RECV" does that whole
receivedPackets.append(value);
to save the received data. And the reading side does that
qDebug() << QTime::currentTime() << "packet WAIT";
WAITFOR(!receivedPackets.isEmpty(), BLE_TIMEOUT);
and should have gotten to the READ side. I wonder if the problem is
that the Mares back-end tries to read in small chunks, and we hit that
if ((size_t)packet.size() > size)
return DC_STATUS_NOMEMORY;
test instead of actually reading the data.
Hmm.
Linus
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
