Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Thu, Sep 27, 2018 at 6:38 AM Jef Driesen <jef at libdivecomputer.org> wrote:
>
> On 2018-09-27 02:37, Linus Torvalds wrote:
> >
> > Jef - I assume your "send first two bytes separately" model is because
> > that's what the Mares app does on a serial line too, and you just
> > followed suite?
>
> Unfortunately that's not the reason. Originally, I used to send
> everything in one go. But for some reason that didn't work for the Mares
> Matrix, and that's why I changed it to send the command in two parts.
> See commit 59bfb0f3189b14ae858650b851539d59e3fefe86 for the details.
> It's been a while, but I think that's indeed also how the Mares
> application does it.

I should have looked at the history of that file, but I was so happy
to finally get data from it that I just didn't.

Oh well. It seems we do need to have something like "if bluetooth
transport" or similar. Or maybe it's the Matrix that should be
special-cased, since that seems to be the one that actually acts
differently.

I'll play around with this some more. I already tested that yes, I can
send the command and the arguments in two packets and it works fine if
I don't actually *wait* for the AA packet in between.

That wasn't a big surprise (since sending it as two packets is what
the Mares app does too), but it confirms the whole "it's some magic
timout".

And it's something in this that really makes it very slow:

   QTime("08:58:38.359") packet SEND "e742"
   QTime("08:58:38.460") packet SEND "0c00000004000000"
   QTime("08:58:39.251") packet RECV "aa48050000ea"

look at that time trace: it actually takes most part of a second for
the Mares to reply.

And I don't think it's actually the Mares divecomputer itself that
causes these delays, I think it's literally the Mares BlueLink Pro
dongle. What I think is going on is

 - the dive computer probably replies immediately to the command (like
it does over serial)

 - the bluetooth dongle has some logic like "buffer up the serial data
until the packet is full, or until some timeout"

which means that even if *our* side is infinitely fast, we'll never
see the "aa" ACK byte reply until at least a timeout (and the timeout
seems to be on the order of at least half a second).

So when we wait for just the 'aa' byte, almost a second has passed for
the actual dive computer, and it just gives up on us.

But there does seem to be something that is specific to either Qt or
whatever else, because the Mares App bluetooth packet trace that Fabio
originally had does *not* show the same kind of "almost one second"
delays for the data transfers.

>From the Mares App trace, I occasionally see delays on the order of
than 0.03 seconds, not that "almost one second".

I don't see what the Mares App does differently, though. We seem to
send exactly the same commands.

I'm wondering if it's some artifact of the Qt BLE implementation.

                     Linus