On 11/01/2021 20:49, Linus Torvalds via subsurface wrote:
On Mon, Jan 11, 2021 at 11:37 AM Markus Hinkelmann via subsurface
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
