Dive import from Ratio IX3M2 PRO after update

[zorcik]

Similar to #66 but it did not resolve the problem.

After update to 5.2.11/016 I am getting 0 m and 0 minutes.

Here is my log.

subsurface2.log.txt

[mikeller]

Similar to #66 but it did not resolve the problem.

No surprise there.

Subsurface: v6.0.5675.1, built with libdivecomputer v0.10.0-devel-Subsurface-NG

Your version of Subsurface is from before this fix was applied. Get the latest version from https://subsurface-divelog.org/latest-release/.

[zorcik]

@mikeller not really. I used a patched version from here: subsurface/subsurface#4911 to get the log. But here is the one from the newest version. I have even used nightly builds. None of this works.

subsurface3.log

[zorcik]

@mikeller I've seen that you have applied a patch subsurface/libdc#121
I've checked this PR Windows build - subsurface/subsurface#4931 but the problem still exists. I attach a log file with 3 dives - one of them is correctly recognized.

subsurface4.log

[zorcik]

IX3M2 PRO Firmware 50211016 — Protocol Change Analysis

Summary

Firmware 50211016 changed the record type field in sample records, causing libdivecomputer to skip all dive samples (treating them as non-sample metadata records). This results in 0m depth and 0min time for every imported dive.

Root Cause

The sample record type field at byte offset 52 (a uint16_le) changed its value for ordinary profile samples:

Firmware	Record Type Value	Interpreted As
50206016 (old, works)	0x0000	REC_SAMPLE ✅ → parsed
50211016 (new, broken)	0x800E	unknown → skipped ❌

What happens in the code

In divesystem_idive_parser.c:

// Get the record type.
unsigned int type = ISIX3M(parser->model) ?
    array_uint16_le (data + offset + 52) :
    REC_SAMPLE;

// APOS5 uses 0x8006 for ordinary profile samples.
if (firmware_major >= 5 && type == REC_SAMPLE_APOS5_COMPAT)  // 0x8006
    type = REC_SAMPLE;

if (type != REC_SAMPLE) {
    // Skip non-sample records.    ← ALL 0x800E samples end up here!
    offset += samplesize;
    continue;
}

A previous fix already mapped 0x8006 (REC_SAMPLE_APOS5_COMPAT) → REC_SAMPLE for APOS5 firmware. But firmware 50211016 now uses 0x800E instead, which is not handled.

Evidence from the Log

From subsurface4.log, 4 dives were downloaded — 2 recorded with each firmware version:

Dive	Date	Firmware	Record Type	Samples	Result
1	2026-08-19 14:58	50211016	0x800E	318	❌ 0m/0min
2	2026-08-19 13:16	50211016	0x800E	341	❌ 0m/0min
3	2026-07-31 17:01	50206016	0x0000	274	✅ Correct
4	2026-07-31 15:07	50206016	0x0000	375	✅ Correct

Note

Dive 3 (July 31) is the one you mentioned imports correctly — it was recorded with the older firmware 50206016 where rec_type=0x0000 (standard REC_SAMPLE).

The Pattern

The record type field is evolving across APOS5 firmware sub-versions:

Firmware	rec_type for samples
APOS4 (4xxxxxxx)	0x0000
APOS5 early	0x8006 (already patched)
50206016	0x0000
50211016	0x800E

The high bit (0x8000) may be a flag meaning "sample record" with the lower bits encoding a sub-type or version. Without vendor documentation this is speculative.

Proposed Fix

The fix in divesystem_idive_parser.c should be one of:

Option A — Add 0x800E as another known alias (narrow fix)

 #define REC_SAMPLE_APOS5_COMPAT 0x8006
+#define REC_SAMPLE_APOS5_800E   0x800E

 if (firmware_major >= 5 && type == REC_SAMPLE_APOS5_COMPAT)
     type = REC_SAMPLE;
+if (firmware_major >= 5 && type == REC_SAMPLE_APOS5_800E)
+    type = REC_SAMPLE;

Option B — Treat anything except REC_INFO as a sample (broader fix)

-if (firmware_major >= 5 && type == REC_SAMPLE_APOS5_COMPAT)
-    type = REC_SAMPLE;
+// APOS5 firmware uses various non-zero record types for ordinary
+// profile samples (0x8006, 0x800E observed). Treat any type that
+// is not REC_INFO (0x01) as a sample record.
+if (firmware_major >= 5 && type != REC_INFO)
+    type = REC_SAMPLE;

Important

Option B is more future-proof but riskier if new non-sample record types are introduced.
Option A is safer but will break again if the record type changes once more.

[jefdriesen]

I received the necessary info from Ratio and will push a fix soon.