Can't Import dives from Mares Quad Air

[Jef Driesen]

On 11/01/2021 20:49, Linus Torvalds via subsurface wrote:
> On Mon, Jan 11, 2021 at 11:37 AM Markus Hinkelmann via subsurface
> <subsurface at subsurface-divelog.org> wrote:
>>
>> I tried to import my dives from my Mares Quad Air using the Interface „Mares BLUELINK Pro“ to subsurface.
> 
> I'm afraid that the Mares BlueLink Pro has been the most problematic
> piece of BLE hardware we have ever seen.
> 
> It has been known to work - often very very slowly - but it has always
> been extremely flaky. I've never figured out why.

The Bluelinkpro is indeed trouble.

There is the outstanding issue of sending the commands "all at once" versus "in 
two pieces". In some cases the former seems to work better, while in other cases 
it's the other way around. So far I haven't been able to find any pattern. It 
could depend on the dive computer model, the operating system, the bluetooth 
stack, etc.

>> The computer was able to connect to the interface using the mode „BT-classic“ but the import fails.
> 
> I didn't even know that it supported BT-classic at all. I've only ever
> seen it do BLE.
> 
> I was going to say that BT-classic cannot possibly work, but:

Both log files have transport=32, so that means BLE was used. Maybe subsurface 
automatically falls back to BLE if rfcomm isn't available?

>> A dump file was not created, but I was able to create a libdivecomputer log file (see attachment).
> 
> Strangely, it actually partially does seem to have worked. There are a
> few valid reply packets with the valid '0xAA' packet reply byte, and
> the communication actually starts. Color me I'm surprised.
> 
> So that log shows us sending several commands to it, and starting to
> do a data transfer.  Yeah, we get a few NAK packets (0xEA) back
> instead of 0xAA, and a couple of "no reply at all" cases, but even
> then the re-try ends up working a few times.
> 
> But then at some point, even when retrying, it just returns an
> all-ones (0xff) answer, and after five failres for that command we
> just give up.
> 
> Honestly, this _might_ be one of those cases where "if you try again,
> eventually it might work".

I suspect the single byte 0xEA response, indicates the device received the 
command packet, but can't answer for some reason. Maybe the received command was 
corrupted, and couldn't be interpreted as a valid command, or the dive computer 
wasn't ready yet to process the next command? But it's still responding somewhat 
normal, and retrying usually works just fine.

Then we have a few cases where we have no response at all. Difficult to tell 
what is going on behind the scenes. Retrying often seems to work at first, but I 
have the impression it all starts to go downhill from here. After a while we 
start to receive garbage data, and we aren't able to recover anymore. We're 
probably out of sync with the dive computer somehow. And that garbage data is 
probably some data send by the dive computer in response to one of the earlier 
commands that happens to arrive too late?

One thing that could contribute to the problem is that the iconhd protocol 
doesn't use any form of checksums. So it's nearly impossible to detect corrupt 
packets. Only the commands have a small protection in the sense that the type 
byte is repeated (with the second byte xor'ed with 0xA5). That could explain why 
it's difficult to recover once things start to go wrong. Of course that doesn't 
explain why things start to go wrong in the first place.

> But equally honestly, I've pretty much given up on the Mares BlueLink
> adapter. I don't know why it's so flaky. The Mares mobile app seems to
> be able to talk to it, but when I did a packet trace, I didn't see it
> do anything special, so I don't know what is going on. It might be
> some very subtle timing issue that the Mares app is aware of.

If I remember correctly, we haven't seen any errors at all in the traces from 
the Mares application. I also have no idea why it seems to just work there, but 
not for us. It looks like they just don't seem to hit this problem. Strange.

The Mares applications sends the command in two parts:

W: CMD CMD ^ 0xA5
R: ACK(0xAA)
W: CMD_DATA
R: RSP_DATA
R: EOF(0xEA)

I've always assumed this is done because the dive computer first acks the 
command byte to indicate it's ready to receive the command payload. At this 
point it knows how many bytes to expect, and is ready with whatever it needed to do.

The only thing that could screw up is some extra latency (due to a slow BLE 
link) that exceeds some internal timeout. In that case the dive computer will 
see the CMD bytes without the payload. Of course we did still send those bytes, 
and the dive computer will get those later. And then it will probably start to 
interpret those as the next command.

If we send the whole command at once, without first waiting for the ack, we 
avoid the extra roundtrip latency. But depending how this is implemented in the 
firmware and the amount of buffering, the command payload could be arriving too 
fast, before the firmware is ready to receive those byte, and they could get 
dropped.

There are certainly some differences in the hardware. For example the iconhd 
uses CDC-ACM, so this is probably a feature of the microcontroller, while some 
of the other models use an external (silabs) usb-serial chip. Timings can also 
be different on the different operating systems and bluetooth stacks.

Jef