Mares Smart Dive Computer + Bluelink pro

Jef Driesen jef at libdivecomputer.org
Thu Sep 27 06:38:24 PDT 2018


On 2018-09-27 02:37, Linus Torvalds wrote:
> So it turns out that "BLE is slow" is actually the *reason* for the 
> problem.
> 
> There's some really odd timing thing, where when we send the read
> command as two different packets (first the two command bytes, then
> the 8 bytes of offset/length), and wait for the AA ACK in between,
> something times out on the Mares side.
> 
> But if I send the command byte as *one* 10-byte packet, it all just 
> works.
> 
> Which is really strange, because the Mares app itself actually sends
> it as two packets, but apparently sends them quickly enough together
> that the Mares doesn't go "where's the rest?" and give up on us.
> 
> Anyway, the attached patch to libdivecomputer makes it work for me.
> I'm really not all that happy with the patch, but hey, it actually
> removes more lines than it adds, and it does make my loaner Mares Quad
> Air happy, so it's clearly doing something good.
> 
> 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.

So I'm afraid that applying this fix, and sending everything in one go 
again, will break the Mares Matrix (and maybe also some of the other 
models). For the Icon HD it should still work, but that model is a bit 
different from the others.

So yes, this will definitely require a lot more testing on several 
models in the iconhd family before changing this.

Jef


More information about the subsurface mailing list