Importing dives from Mares Quad with Bluelink on Android phone

[Ben Linders]

I tried to import my dives from my Mares Quad divecomputer into Subsurface using the Bluelink clip on my Android phone.

It takes long, and only 1 or two dives are imported, even when I select to force import all dives (there are 24 dives on the computer).

When I use the Mares app with the Bluelink clip, all dives are imported smootly. But I'm a huge fan of Subsurface. And there doesn't seem to be  a way to export from the Mares app into Subsurface.

I found several converstations of people who had problems with this in the group, but no solutions or cure in those. Is the interface for Mares Quad Bluelink still under development, or is there anything I can do to make it work better?

Thanks!

Ben Linders

[John July]

Hi Ben

I also have the Quad.  I love it, but the log is tricky.  Here is my list of instructions on the long process to get it to Subsurface ...

Computer to Dive logs

Mares QUAD dive computer 6570 (6718) ver 2.01
Mares Computer Communication Device  Dive Link 2 USB
Mares Dive Organizer 2.29.4.11118
Subsurface 5.0.9
www.divelogs.de


Open Dive Organizer app 
Plug Dive Link 2 into USB port
Set Mares QUAD computer to PC / Push ENTER
Clip Dive Link 2 to Mares QUAD dive computer
Dive Organizer / Upper Menu / Computer / Download Logbook (if this is not available, unplug USB and try again.)
   Logbook download ...
   Indexing. Progress: ...
   Parsing. Progress: ...
   Select Dives to Import (bottom button Select All)...
   Import Selected Dives (bottom button) ...
   Importing. Progress: ...
Unplug USB

Within Dive Organizer, select Database → Backup from the main menu and back up the database to the desk top. This creates a zipped file DiveOrganizerxxxxx.dbf.
Rename the file to DiveOrganizerxxxxx.zip. Inside the zipped directory is a file DiveOrganizer.sdf.
Extract the .sdf file from the zipped folder to your Desktop.
The password for accessing the .zip file is mares.

Data should then be imported into www.divelogs.de. ... Login
Select Import Logbook → Mares Dive Organizer from the menu on the left hand side. The instructions must be carefully followed to transfer the dive information (in _.sdf format) from the Dive Organizer database to www.divelogs.de.
Finally, import the dives from divelogs.de to Subsurface, using the instructions below.

Subsurface:
Importing dive information from divelogs.de is simple, using a single dialog box. The Import → Import from Divelogs.de option should be selected from the Main Menu. This brings up a dialog box (see image A). Enter a user-ID and password for divelogs.de and then select the Download button. Download from divelogs.de starts immediately, displaying a progress bar in the dialog box. At the end of the download, the success status is shown (see image B). The Apply button should then be selected, after which the imported dives appear in the Subsurface Dive List panel.

Hope this works for you.

John in Panama

[Jef Driesen]

Do you get some kind of error message?

Can you send a debug log from the download? With the detailed logging, we have
no idea what or why the download fails for you. Instructions are available here:

https://libdivecomputer.org/subsurface.html#mobile

Jef

[Ben Linders]

Hi John,

Thanks for getting back with how you do the synchronization. There are some differences though.

I'm using the Bluelink clip, which is Bluetooth based (not cable). 

And I'm synchronizing with my smartphone on Android (not PC).

Is there a way to download the database in the Mares App that you are aware of?

Or to link the Divelog program on the PC with the Mares App?

Ben Linders

[Ben Linders]

Hi Jef,

Thanks for stepping in, appreciate your help.

I don't see any errors, it just stops after 1, 2, or 3 dives.

I do have the log files from my last attempt (didn't know this debug facility), find them attached.

Ben Linders

[Richard Neville]

I do a similar thing on an iPhone with Dive Log app then going via divelog.de to Subsurface to get around Mares software. Bit of a fiddle but I think of it as useful redundancy having your dive log backed up across several locations and platforms.

Admittedly I go a bit over the top with redundancy running a Garmin Descent and Garmin's Dive app as yet another backup ;-)

Cheers, Richard

--
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/e58f95b0-9864-4e6d-ac08-af87b58068a3n%40googlegroups.com.

[Jef Driesen]

Ben,

You logs shows three types of errors. The first two are pretty standard, but the
third type is interesting.

The first one is the empty response:

[0.608703] INFO: Write: size=2, data=E742
[0.612240] INFO: Write: size=8, data=7091020080000000
[1.198233] INFO: Read: size=1, data=EA
[1.198249] ERROR: Unexpected answer byte. [in
/__w/subsurface/subsurface/libdivecomputer/src/mares_iconhd.c:219
(mares_iconhd_packet)]

I suspect that means the dive computer received something it couldn't interpret
correctly. We get the single byte back after about 500ms, so that's probably the
internal timeout used by the dive computer.

The next one is no response at all, and thus we time out:

[1.530536] INFO: Write: size=2, data=E742
[1.536700] INFO: Write: size=8, data=7090020080000000
[4.539861] INFO: Read: size=0, data=
[4.539878] ERROR: Failed to receive the answer. [in
/__w/subsurface/subsurface/libdivecomputer/src/mares_iconhd.c:213
(mares_iconhd_packet)]

I'm not really sure why we don't get any response at all here, but both these
errors are usually fixed by just retrying the command.

The third type of error is more interesting because it shows how one error can
also cause the retries to fail. First we hit a timeout:

[8.122494] INFO: Write: size=2, data=E742
[8.122663] INFO: Write: size=8, data=708F020080000000
[11.130287] INFO: Read: size=0, data=
[11.130308] ERROR: Failed to receive the answer. [in
/__w/subsurface/subsurface/libdivecomputer/src/mares_iconhd.c:213
(mares_iconhd_packet)]

Next, we retry a few times:

[11.130321] INFO: Sleep: value=100
[11.230536] INFO: Purge: direction=1
[11.231117] INFO: Write: size=2, data=E742
[11.240494] INFO: Write: size=8, data=708F020080000000
[11.415317] INFO: Read: size=20, data=0000000035004F000C00000037004F0000000000
[11.415331] ERROR: Unexpected answer byte. [in
/__w/subsurface/subsurface/libdivecomputer/src/mares_iconhd.c:219
(mares_iconhd_packet)]
[11.415339] INFO: Sleep: value=100
[11.515889] INFO: Purge: direction=1
[11.517474] INFO: Write: size=2, data=E742
[11.517628] INFO: Write: size=8, data=708F020080000000
[11.517798] INFO: Read: size=13, data=1300000036004F000A00000037
[11.517803] ERROR: Unexpected answer byte. [in
/__w/subsurface/subsurface/libdivecomputer/src/mares_iconhd.c:219
(mares_iconhd_packet)]

That didn't really work, but the interesting part is that we did receive some
data now. We see the same data appear in the next retry (more on that later):

[11.517811] INFO: Sleep: value=100
[11.618398] INFO: Purge: direction=1
[11.618760] INFO: Write: size=2, data=E742
[11.619100] INFO: Write: size=8, data=708F020080000000
[11.619341] INFO: Read: size=1, data=AA
[11.619349] INFO: Read: size=20, data=0000000035004F000C00000037004F0000000000
[11.619355] INFO: Read: size=20, data=37004F001E00000036004F001000000037004F00
[11.619360] INFO: Read: size=20, data=2C00000037004F001200000034004F0033000000
[11.619366] INFO: Read: size=20, data=37004F000000000037004F001E00000036004F00
[11.630104] INFO: Read: size=12, data=1300000036004F000A000000
[11.630122] INFO: Read: size=20, data=37004F002000000038004F001D00000038004F00
[11.630131] INFO: Read: size=17, data=2300000039004F000600000037004F00EA

This time the retry worked and we move on to the next request:

[11.635160] INFO: Write: size=2, data=E742
[11.635359] INFO: Write: size=8, data=F08E020080000000
[11.687620] INFO: Read: size=1, data=AA
[11.708476] INFO: Read: size=20, data=0000000035004F000C00000037004F0000000000
[11.719214] INFO: Read: size=20, data=37004F001E00000036004F001000000037004F00
[11.719231] INFO: Read: size=20, data=2C00000037004F001200000034004F0033000000
[11.719240] INFO: Read: size=20, data=37004F000000000037004F001E00000036004F00
[11.740569] INFO: Read: size=13, data=1300000036004F000A00000037
[11.740585] INFO: Read: size=20, data=004F002000000038004F001D00000038004F0023
[11.740592] INFO: Read: size=20, data=00000039004F000600000037004F00EAAA090010

This appears to have worked, but upon closer inspection you can see that the
very last packet already contains the start of the response to the next request
(AA090010). But we haven't send the next request yet!

That means the response we received here is actually the response to one of the
earlier (failed) request, and this start of the next packet is our real
response. So we're getting completely out of sync! Unfortunately the Mares
protocol doesn't use checksums or sequence number, so we can't detect this.

In the next command we see a very similar problem again:

[11.741000] INFO: Write: size=2, data=E742
[11.741157] INFO: Write: size=8, data=708E020080000000
[11.762247] INFO: Read: size=20, data=000A00100035004F001200100035004F00270010
[11.762264] INFO: Read: size=13, data=0035004F002300100032004F00
[11.762273] INFO: Read: size=20, data=3200100031004F000A00100033004F002F001000
[11.762281] INFO: Read: size=20, data=34004F002D0010002F004F007A00180033004F00
[11.773071] INFO: Read: size=20, data=0000100034004F000400100035004F0000000000
[11.773090] INFO: Read: size=13, data=34004F002600000035004F00EA
[11.794021] INFO: Read: size=1, data=AA
[11.889353] INFO: Read: size=2, data=4900
[11.910627] INFO: Read: size=20, data=100037004F002700100035004F001E0010003500
[11.910648] ERROR: Unexpected answer byte. [in
/__w/subsurface/subsurface/libdivecomputer/src/mares_iconhd.c:240
(mares_iconhd_packet)]

I have some ideas on how to make the code more robust against this stale data.
But unfortunately I don't have a build environment ready for building a patched
version of Subsurface mobile. Can you test on Windows too?

Jef