Mares Quad CI

[José R. González]

Hi there all¡, new here and first message to the forum, first of all thanks for your help.

I'm unable to connect my new Mares Quad CI with Subsurface and import diving, I've tried to do it with all the Mares computers supported in Subsurface without success.

Could you add support with this computer, or I must try in another way?.

I'm abvsolutely useless with logs, libdive computers , and things such as.

Thanks a lot and saludos,

José Rogelio González.

[Walter Kraft]

Same here,

Since many years I was diving with a Cressi Leonardo, works perfect for the import of my dives. Now I bought the mares quad ci, but no chance to import my dives. Mares is here a little unique I guess.

If I can support somehow with log files to implement this computer, let me know.

Thanks to all of you for this great pice of software :-) 

Walter

[Ben Linders]

Hi,

I'm having trouble with the Mares Quad (the one without integrated air), can't get my dives into Subsurface. 

Anyone with a Mares Quad and Bluelink who knows how to download dives into Subsurface?

Ben Linders 

Op za 10 aug 2024 23:45 schreef Walter Kraft <wka...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/96f5eb50-c69b-4941-9798-b0ba34ea1fd0n%40googlegroups.com.

[Dirk Hohndel]

The Mares Quad CI is only supported by the latest release (6.0.5231) - which version are you trying to use?

/D

[Ben Linders]

That is the version that I installed this morning and which I am using. 

Ben Linders 

Op do 15 aug 2024 16:58 schreef 'Dirk Hohndel' via Subsurface Divelog <subsurfac...@googlegroups.com>:

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/373054F2-1686-4D0F-9538-BC3433B094E9%40hohndel.org.

[Dirk Hohndel]

Cool.

Are you able to expand on what you mean by "having trouble"?

The dive computer fell off the table while you connected?

There was an earthquake and power went out?

You got an error message? Mind sharing that message?

Something else? How about a screenshot and some more context?

/D

On Aug 15, 2024, at 08:00, Ben Linders  wrote:

That is the version that I installed this morning and which I am using. 

[Ben Linders]

Hi Dirk,

Apologies, this is vague indeed.

I either get no connection at all with the Mares Quad through the Bluelink, the led on the Bluelink stays blue. The best I had was the Bluelink led weny green and downloading the last 2 dives and then it stopped suddenly. There are 9 dives not yet imported. I als tried downloading all dives (over a hundred), but no dives at all or maximum 2 dives download.

I attached the log files.

Ben Linders 

Op do 15 aug 2024 18:26 schreef 'Dirk Hohndel' via Subsurface Divelog <subsurfac...@googlegroups.com>:

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/5F0CE092-62E8-41CC-99BF-C64FB81A20FA%40hohndel.org.

[Dirk Hohndel]

Hmm, the log file is fairly non-conclusive. the Subsurface log is missing the start (which would verify the specific versions that you are using, both of the app and the OS / device).

And the libdc log is essentially empty - even though we can see in the main log that the Bluelink is indeed recognized.

So in general, the Bluelink is known to be a bit finicky and often cause timeouts, and the simple recommendation is usually "keep trying" (right, super frustrating).

One thing that has helped me in situations like this is to try and get into an "RF quiet" environment. So quite literally find a spot where there aren't tons of other devices. Take your phone and the dive computer out into the yard, away from computers, speakers, cars, fridges, anything else that tries to create BLE connections.

I don't have a Bluelink device myself, so I don't have more specific suggestions (others please speak up)!

/D

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CA%2Bhd0CAe623emuCehhRLr4cJuz4dojmiD5GyxMrzU889yJVk_w%40mail.gmail.com.
<Aug 15 Ben Linders subsurface.log><Aug 15 Ben Linders libdivecomputer.log>

[Jef Driesen]

On 15/08/2024 19:10, 'Dirk Hohndel' via Subsurface Divelog wrote:
> Hmm, the log file is fairly non-conclusive. the Subsurface log is missing the start (which would verify the specific versions that you are using, both of the app and the OS / device).
> And the libdc log is essentially empty - even though we can see in the main log that the Bluelink is indeed recognized.

The libdivecomputer log file shows an attempt to use serial communication
instead of the BLE connection:

Subsurface: v6.0.5231.0, built with libdivecomputer v0.9.0-devel-Subsurface-NG
(73e3b194463db6750110ff343d5c2464b82ad5da)
[37.499509] INFO: Open: name=
[37.499520] ERROR: No such file or directory (2) [in
/__w/subsurface/subsurface/libdivecomputer/src/serial_posix.c:296 (dc_serial_open)]

Not sure how that's possible, but this can never work at all.

Jef

[José R. González]

Hi, running the actual release, 6.0.5231.
It seems as Subsurface not connect with the Quad CI, via bluelink and PC.
The message error is "No se pudo abrir COM4 Mares (Quad CI)"
Attached the subsurface.log.
The libdivecomputer is not created, or is the subsurfcace file same, or I cann't find at the pc.
Thanks Dirk!

[Ben Linders]

Hi Jef and Dirk,

Let me know if there's anything I can try out and create a new proper log file?

Happy to go through steps that you suggest and share the results if that helps.

Ben Linders 

Op vr 16 aug 2024 00:01 schreef Jef Driesen <j...@libdivecomputer.org>:

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/860cb3b9-6fda-4ee3-8d40-c533e8bbdb21%40libdivecomputer.org.

[Ben Linders]

Hi,

I've made another attempt and tried 3 times to download dives. The led on the Bluelink went green but nothing downloaded. It shows the message "connect ..." but the word behind connect falls off the screen of my Samsung phone.

Does this help?

Ben Linders

[José R. González]

Hi all¡,

in my case I've trying to download dives to a PC (windows).

In case it helps, the options of "Dispositivo o punto de montaje" are still on grey, I mean without chance of change, with and without the QUAD CI connected.

I've downloaded today diving from my old Cressi Leonardo with success, port that Subsurface offers is COM3, I've tried with this one from the Mares with the same result as COM 4 or  whatever the others ports, I mean nothing happens.

Hope this could help.

José Rogelio 

[Linus Torvalds]

On Sat, 17 Aug 2024 at 23:29, Ben Linders <benli...@gmail.com> wrote:
>
> I've made another attempt and tried 3 times to download dives. The led on the Bluelink went green but nothing downloaded. It shows the message "connect ..." but the word behind connect falls off the screen of my Samsung phone.
>
> Does this help?

Well, the logs are helpful in the sense that yes, they show that
bluetooth communication actually happens.

But something goes seriously wrong with the communication.

In your "subsurface log 2", I see this (edited down to remove the
uninteresting characteristic UUID etc):

Write "c267"
write confirmation 10 "c267" QLowEnergyService::NoError
notification 7 "aa00000000000000000000000000000000000000"
notification 7 "0000000000000000000000000000000000000000"
notification 7 "00000000"
notification 7 "0000000000000000000000000000000000000000"
notification 7 "0000000000000051756164000000000000000000"
notification 7 "00000030322e30312e30300201000032332d3033"
notification 7 "2d313859ad53564e343030000000000000000000"
notification 7 "000000000000000000000000"
notification 7 "0000000000ea"
Write "b316"
write confirmation 10 "b316"
notification 7 "aa00001000ea"

which actually looks fine: we've written a command, and get reasonable
data back, and then we write the next command etc.

In fact, it looks like it all works fine with what looks like good
data until we start sending the "read command" commands, and at that
point we see

Write "e742"
write confirmation 10 "e742"
notification 7 "aa019b0000ea"

and this is horribly wrong. The "e742" is just the CMD_READ byte: E7
and the 42 byte is the XOR of that with A5. And we haven't actually
written the _address_ we read from - there's 8 more bytes that specify
the address and the length of the read, and they never got sent.

So the end result is broken chaos.

Jef and Michael - the problem is that we have merged with the
libdivecomputer upstream code, because we thought Jef knew better. And
it appears that Jef doesn't actually know better at all.

See my libdivecomputer commit 704ed3f1 ("Add back Mares BlueLink Pro
bluetooth support tweaks"), and the whole "splitcommand" logic. In
particular, in that commit message I say

In particular, it turns out that we really can't send the command bytes,
then wait for the ACK byte, and then send the command argument data as a
separate packet. Because of the delays that the dongle adds, the dive
computer will have given up on the command arguments by the time it sees
them.

and it seems that is still true. The BlueLink dongle does *not* want
the first two bytes to be split out and sent independently.

But that code got removed by the upstream merge in commit d37cb917
("Merge remote-tracking branch 'libdivecomputer/master' into
update_libdivecomputer_202402"), because Jef did

e83732e2 ("Fix the Mares Bluelink Pro communication")
a7e7439c ("Setup the 2 byte command header internally")

and it now sends the first two command bytes as a separate packets
from the the rest.

But from the logs it's pretty clear that the split-command thing is
broken. We never send the address and length at all, just repeating
the "e742" write over and over again.

Which is strange is that the code should at least send the extra 8
command bytes right after the 2-byte packet:

status = dc_iostream_write (device->iostream, command,
sizeof(command), NULL);
if (status != DC_STATUS_SUCCESS) {
ERROR (abstract->context, "Failed to send the command header.");
return status;
}

// Send the command payload to the dive computer.
if (size && transport == DC_TRANSPORT_BLE) {
status = dc_iostream_write (device->iostream, data, size, NULL);
if (status != DC_STATUS_SUCCESS) {
ERROR (abstract->context, "Failed to send the
command data.");
return status;
}
}

but in the subsurface logs, that never happens.

So something is very very wrong with the libdivecomputer iconhd code,
or with the write buffering.

I don't know why the second write seems to just get entirely lost. All
the actual IO and the logging comes from the Qt BLE side (because
subsurface will log the write requests itself only if

if (verbose > 2 || debugCounter < DEBUG_THRESHOLD)

and so the subsurface side is being silent and that log is only about
actually sent and received packets from Qt.

And your libdivecomputer log-file doesn't show this, because it seems
to be from a later - completely failed - download, where it doesn't
even get past the initial "hello" command (that first "c267" thing:
CMD_VERSION). It's reading random stale data that the BlueLink is
sending that is left-over from previous very very confused things.

It might be interesting to get the output from "subsurface -vv", but
it actually looks like *none* of the subsurface.log data comes from
subsurface's own logging. Absolutely everything seems to be just Qt
logging.

I wonder if report_info() and friends are just broken, and don't show
up in subsurface.log at all.

Very annoying.

Linus

[Linus Torvalds]

On Sun, 18 Aug 2024 at 09:54, Linus Torvalds
<torv...@linuxfoundation.org> wrote:
>
> So something is very very wrong with the libdivecomputer iconhd code,
> or with the write buffering.

It looks like it may at least partly be a logging problem. Again, our
subsurface log *only* shows the Qt logging, not actually our own logs,
so the logs are incomplete and hard to read.

Because that "aug\ 17\ Ben\ Linders\ subsurface\ 2.log" file does seem
to show what looks like fairly happy communication initially, even if
I only see the two-byte initial command packet in the logs, not the
8-byte address and length packet.

But then at some point, it looks like the BLE connection just goes
away, and we don't even get the write confirmation for the packet.

So then that log shows all the signs of retry, and during the retry
nothing works at all, because when libdivecomputer tries to do that
initial handshake (CMD_VERSION), it just gets garbage back (a stream
of "ff" bytes or "bf" bytes).

The bluelink thing is just horrible horrible garbage. It's some kind
of broken serial-to-BLE converter, and if you look at it funny it just
falls sideways.

Linus

[Jef Driesen]

This is on purpose, because the problem is a bit more complex. Sending
the command byte and the payload as one packet does indeed work for some
users. But it also causes the communication to fail for others! That's
the reason why I never adopted your fix.

When analyzing some packet captures again from the Mares Android app
(for the Mares Sirius support), I noticed it always sends two BLE
packets (one containing the two byte command and another one containing
the remainder of the data), but without waiting for the ACK in between.
We tested this approach with a few affected users and it worked very
well. Since this fix was merged, I did not receive a single bug report
from Mares users, so I assume I had found the final solution. Until now.

It's probably not a coincidence, but I think the majority of the cases
where sending everything as a single BLE packet did not work, where from
users of applications other than subsurface. So it's not impossible that
there is something specific to the bluetooth stack (different OS), the
framework (Qt vs .NET), or even the applications custom I/O
implementation that behaves a bit different. Especially with something
that I suspect is a timing sensitive issue, that could indeed make a
difference.

Another thing that likely matters here is the fact that some Mares dive
computers (like the Sirius, Genius, and a few others) have the bluetooth
functionality integrated directly in the dive computer and thus don't
require the bluelink dongle. I have no idea how different this
integrated hardware is compared to the bluelink dongle, but I expect
they will also behave a bit different.

Now, what seems to be pretty consistent is that once the communication
fails, it's difficult to successfully recover and get the communication
going again. Retrying sometimes works, but very often it doesn't.
Sometimes the failure is also very subtle. At first sight the retrying
appears to work fine, but a bit later you suddenly start seeing
responses before the command is send (and other weird things). That
indicates that we are completely out of sync and are actually receiving
a late or stale response from a previous attempt. Since the protocol has
no checksums or sequence numbers we don't really have a means to detect
such problems. We only have the 0xAA and 0xEA marker bytes to detect the
begin/end of a frame, and they even fail at that because those bytes can
also appear in the content.

I already tried several approaches to improve the reliability of the
retries: waiting much longer than 100ms (up to several seconds) before
sending a retry in an attempt to let potential timeouts on the dive
computer side (or bluelink dongle) expire. Also reading and discarding
bytes until we find an 0xAA marker to get rid of stale data in addition
to flushing the input buffer. But none of that really helped.

> But from the logs it's pretty clear that the split-command thing is
> broken. We never send the address and length at all, just repeating
> the "e742" write over and over again.
>
> Which is strange is that the code should at least send the extra 8
> command bytes right after the 2-byte packet:
>
> status = dc_iostream_write (device->iostream, command,
> sizeof(command), NULL);
> if (status != DC_STATUS_SUCCESS) {
> ERROR (abstract->context, "Failed to send the command
> header.");
> return status;
> }
>
> // Send the command payload to the dive computer.
> if (size && transport == DC_TRANSPORT_BLE) {
> status = dc_iostream_write (device->iostream, data,
> size, NULL);
> if (status != DC_STATUS_SUCCESS) {
> ERROR (abstract->context, "Failed to send the
> command data.");
> return status;
> }
> }
>
> but in the subsurface logs, that never happens.
>
> So something is very very wrong with the libdivecomputer iconhd code,
> or with the write buffering.

This is indeed strange. Both packets should get send immediately after
each other. There is no write buffering on the libdivecomputer side. As
you mention in your follow-up email, this looks indeed like a problem
with the logging.

Something else, I wonder if this subsurface code is causing us trouble:

https://github.com/subsurface/subsurface/blob/master/core/qt-ble.cpp#L323-L328

If a BLE data packet happens to arrive between sending the two parts, it
will get discarded here. In theory this could happen if the dive
computer sends the 0xAA immediately after receiving the first packet
with the command bytes, and the sending of the second part is delayed
for some reason.

Without the logging, we don't know if this happened or not.

> I don't know why the second write seems to just get entirely lost. All
> the actual IO and the logging comes from the Qt BLE side (because
> subsurface will log the write requests itself only if
>
> if (verbose > 2 || debugCounter < DEBUG_THRESHOLD)
>
> and so the subsurface side is being silent and that log is only about
> actually sent and received packets from Qt.

I usually remove the code in the checkThreshold() function to keep the
logging enabled. Something like this:

https://github.com/jefdriesen/subsurface/commit/2721613f45046101d67755d92e38357863916744

> And your libdivecomputer log-file doesn't show this, because it seems
> to be from a later - completely failed - download, where it doesn't
> even get past the initial "hello" command (that first "c267" thing:
> CMD_VERSION). It's reading random stale data that the BlueLink is
> sending that is left-over from previous very very confused things.
>
> It might be interesting to get the output from "subsurface -vv", but
> it actually looks like *none* of the subsurface.log data comes from
> subsurface's own logging. Absolutely everything seems to be just Qt
> logging.
>
> I wonder if report_info() and friends are just broken, and don't show
> up in subsurface.log at all.

The log is from the Android version, so running with extra command-line
options is not really possible.

Jef

[José R. González]

Hi all, 

after all, do we have to assume that development for the QUAD CI are not going to be possible?.

Thanks¡