Error while downloading from Mares Nemo Wide 2

[Carlo Spigoli]

Hi, I'm trying to download my latest dives from my Nemo Wide 2.

Last time I did it was in october of 2025 and it worked fine. Today I get the following error. What should be the error?

Important: with original Mares software it worked fine.

Thanks

Carlo

Subsurface: v6.0.5404.0, built with libdivecomputer v0.9.0-devel-Subsurface-NG (26221352623426bbc36166c9eccde923d1879cb9)
[0.000001] INFO: Open: name=COM5
[0.064840] INFO: Configure: baudrate=115200, databits=8, parity=2, stopbits=0, flowcontrol=0
[0.069064] INFO: Timeout: value=3000
[0.069181] INFO: DTR: value=0
[0.069529] INFO: RTS: value=0
[0.070194] INFO: Purge: direction=3
[0.121959] INFO: Write: size=2, data=C267
[0.124960] INFO: Read: size=1, data=AA
[0.138585] INFO: Read: size=140, data=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004E656D6F20576964652032000000000030322E30302E30310200010032382D30332D313791314E656D6F20576964652032000000000000000000000000000000000000000000
[0.138643] INFO: Read: size=1, data=EA
[0.138652] DEBUG: Version: size=140, data=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004E656D6F20576964652032000000000030322E30302E30310200010032382D30332D313791314E656D6F20576964652032000000000000000000000000000000000000000000
Event: vendor=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004E656D6F20576964652032000000000030322E30302E30310200010032382D30332D313791314E656D6F20576964652032000000000000000000000000000000000000000000
[0.138959] INFO: Write: size=2, data=E742
[0.139922] INFO: Read: size=1, data=AA
[0.140161] INFO: Write: size=8, data=0C00000004000000
[0.147569] INFO: Read: size=4, data=CC3A0100
[0.147611] INFO: Read: size=1, data=EA
Event: model=25 (0x00000019), firmware=0 (0x00000000), serial=80588 (0x00013acc)
[0.147674] INFO: Fingerprint: size=10, data=150029001E0000007000
[0.147894] INFO: Write: size=2, data=E742
[0.148826] INFO: Read: size=1, data=AA
[0.149075] INFO: Write: size=8, data=0120000004000000
[0.156557] INFO: Read: size=4, data=7F7F7F7F
[0.156598] INFO: Read: size=1, data=EA
[0.156609] ERROR: Ringbuffer pointer out of range (0x7f7f7f7f). [in src/mares_iconhd.c:882 (mares_iconhd_device_foreach_raw)]

[Carlo Spigoli]

Here the memory dump

[Jef Driesen]

On 6/05/2026 12:42, Carlo Spigoli wrote:
> [0.147894] INFO: Write: size=2, data=E742
> [0.148826] INFO: Read: size=1, data=AA
> [0.149075] INFO: Write: size=8, data=0120000004000000
> [0.156557] INFO: Read: size=4, data=7F7F7F7F
> [0.156598] INFO: Read: size=1, data=EA
> [0.156609] ERROR: Ringbuffer pointer out of range (0x7f7f7f7f). [in src/
> mares_iconhd.c:882 (mares_iconhd_device_foreach_raw)]

The reason why the download fails is because the ringbuffer pointer contains an
unexpected value. It should be either a valid value or 0xffffffff to indicate
the backup one should be used.

But there is something strange going on here, because it's not just the
ringbuffer pointer that contains that 0x7f pattern. It's present elsewhere in
the memory dump too. The ringbuffer pointer value that is stored in the memory
dump is 0xffff7fff, which is also different from the value. When I import the
dives from the memory dump in subsurface, I also see some data corruption in the
dive profiles. See the attached screenshot. So I suspect the data might be
corrupted during the communication. Unfortunately the Mares communication
doesn't use checksum, so this is difficult to detect. Can you try downloading
another memory dump, so I can compare whether there are differences?

I have an idea how I can implement a workaround for the unexpected ringbuffer
value. That would already allow you to download your dives, but I also want to
confirm whether there is indeed a data corruption problem or not.

Jef

[Carlo Spigoli]

Hi,
thanks for your support.
You are right, the problemi seems to be in downloading. I've dowloaded a new dump and it si really different from first. (in attach).
Probably my interface is in fault....

Carlo

-----Messaggio originale-----
Da: Jef Driesen <j...@libdivecomputer.org>
Inviato: giovedì 7 maggio 2026 11:18
A: subsurfac...@googlegroups.com; Carlo Spigoli <carlo....@gmail.com>
Oggetto: Re: Error while downloading from Mares Nemo Wide 2

[Carlo Spigoli]

I' tried again and, today, it worked.

Before, last days, it failed almost 20 tries. It’s probably an interface fault or something in connection. I’ll check it gain with oscilloscope to see if there is something wrong in signalling.

Thanks

Carlo

 

 

 

 

-----Messaggio originale-----
Da: Carlo Spigoli <ca...@spigolitondi.it>
Inviato: venerdì 8 maggio 2026 12:27
A: 'Jef Driesen' <j...@libdivecomputer.org>; subsurfac...@googlegroups.com; 'Carlo Spigoli' <carlo....@gmail.com>
Oggetto: R: Error while downloading from Mares Nemo Wide 2

[Robert C. Helling]

wet contacts or low dive computer batteries are the usual suspects. Turns out transmitting data often puts more strain on the battery than recording dives or operating the display.

R.

[Carlo Spigoli]

Computer report “BAT OK” and contact are dry, but are possible either low batter or poor contact condition. I’ll check and report you next days.

ThanksùCarlo

 

Da: 'Robert C. Helling' via Subsurface Divelog <subsurfac...@googlegroups.com>
Inviato: venerdì 8 maggio 2026 16:52
A: 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 visit https://groups.google.com/d/msgid/subsurface-divelog/f74e5194-dc60-47ab-906e-b4b55a34f92bn%40googlegroups.com.

[Jef Driesen]

On 2026-05-08 14:27, Carlo Spigoli wrote:
> I' tried again and, today, it worked.
>
> Before, last days, it failed almost 20 tries. It's probably an
> interface fault or something in connection. I'll check it gain with
> oscilloscope to see if there is something wrong in signalling.

I suspect the data corruption happens during the communication where
some random bits are flipped during transit. If that happens at an
important value like the ringbuffer pointer, then it can causes the
download to fail. If it's somewhere less critical, like in the dive
profile data, then it will show up as an artifact like a depth spike in
the dive profile. I have no idea what causes this. If the communication
protocol did use checksums we could detect this and retry failed
packets. But unfortunately that's not the case.

Anyway, I pushed a small fix that fixes the downloading when the
ringbuffer pointer isn't the expected 0xffffffff value:

https://github.com/libdivecomputer/libdivecomputer/commit/8254edb110d95d98e81e4a13cb5361816d68981f

Of course that doesn't fix the underlying data corruption problem.

Jef