Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Thu, Sep 27, 2018 at 10:00 AM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> And what may end up happening is that when the bluetooth side is slow,
> the buffer on the BlueLink fills up from the serial data and you have
> buffer overflows, and then things go sideways very quickly.
>
> Judging by the fact that we did get 250 bytes, I wonder if the buffer
> size on the BlueLink is perhaps around 256 bytes.

Ahh. I can actually reproduce this behavior with the "dump
divecomputer memory". I now realize that that never worked before for
me - I saw a lot of 'ff' bytes being transmitted, but I didn't see
*all* of them, because it would result in the same eventual failure.

But yes, limiting the packetsize to 128 bytes when using the BlueLink
Pro dongle really fixes things.

And I also made the "split command" be conditional, and the "send as
one" be triggered by just the bluetooth case.

I more and more suspect this is some Qt bluetooth thing that causes
these delays (perhaps due to lost packets and retransmissions?) The
Mares App can do 256-byte reads because for some reason it has much
higher bluetooth throughput.

Maybe it's that Qt by default goes to the slow 125kbit mode, when BLE
can do 1mbps (or 2mbps for BLE5)?

I have a patch that I'm testing that I'll be pushing out shortly, but
it does fix this issue for me.

                         Linus