<html><head></head><body>I have an icon HD somewhere. It will require charging as it hasn't been used in a long time...<br><br>/D<br><br><div class="gmail_quote">On September 26, 2018 5:37:55 PM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On Wed, Sep 26, 2018 at 3:21 PM Linus Torvalds<br><torvalds@linux-foundation.org> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><br> After switching to the 16@0 version, that is *exactly* the same<br> command sequence that the Mares App does first too. But when the<br> Mares app does it, it gets the 16 bytes of data.<br><br> Weird.<br></blockquote><br>So it turns out that "BLE is slow" is actually the *reason* for the problem.<br><br>There's some really odd timing thing, where when we send the read<br>command as two different packets (first the two command bytes, then<br>the 8 bytes of offset/length), and wait for the AA ACK in between,<br>something times out on the Mares side.<br><br>But if I send the command byte as *one* 10-byte packet, it all just works.<br><br>Which is really strange, because the Mares app itself actually sends<br>it as two packets, but apparently sends them quickly enough together<br>that the Mares doesn't go "where's the rest?" and give up on us.<br><br>Anyway, the attached patch to libdivecomputer makes it work for me.<br>I'm really not all that happy with the patch, but hey, it actually<br>removes more lines than it adds, and it does make my loaner Mares Quad<br>Air happy, so it's clearly doing something good.<br><br>Jef - I assume your "send first two bytes separately" model is because<br>that's what the Mares app does on a serial line too, and you just<br>followed suite?<br><br>I'm assuming that with a serial line, things are basically so quick<br>that it's simply not an issue. The Qt BLE code is really slow, and<br>we've had timing issues with it before (it caused problems on the<br>Suunto EON Steel/Core too).<br><br>So I think I'll commit this patch, although we *could* make it depend<br>on the transport type (ie BLE vs serial). Although I strongly suspect<br>that the simpler "just send the whole command" model works on a serial<br>line too.<br><br>Does anybody have a Mares in the "Icon HD" family with a serial line<br>or USB to test? My loaner Quad Air didn't come with any PC interface,<br>so now I _just_ have that BlueLink dongle I bought.<br><br>Any of the Mares Matrix/Smart/Icon HD/Pucj Pro/Quad/Quad Air family<br>would be interesting to hear about.<br><br>I do wonder *why* BLE ends up being so slow on this thing - I'm<br>consistently seeing delays of 1s for replies to come in, but while<br>Fabio's trace from the Mares App also shows _some_ of that, it's not<br>nearly as bad. It may just be that the Mares App doesn't actually<br>wait for the AA to come in, so it just streams the BLE traffic better.<br><br>Anyway, after all these oddities, I do have a 100% successful<br>download. Of course, the dive computer I have as a loaner is entirely<br>empty of all dives, so I don't have any *dive* downloads, but it<br>successfully read the memory to see that.<br><br>And to test the BLE IO, I did try to do a libdivecomputer dumpfile,<br>which creates a lot of read activity (even if the data is all 'ff')<br><br> Linus<br></pre></blockquote></div><br>-- <br>From my phone</body></html>