Can't Import dives from Mares Quad Air

[Markus Hinkelmann]

That aren’t very good news. 
Just an additional question. You talk about the iconHD protocol. I use a quad air. Did they use the same protocol? 

Just tell me, if I can provide more details or log files, to help you to debug the problem. 

Markus 

> Am 12.01.2021 um 22:54 schrieb Jef Driesen <jef at libdivecomputer.org>:
> 
> 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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20210116/2ee44402/attachment-0001.htm>