Mares Puck Pro EZ (Puck Lite?)

[Ken Mankoff]

Hello,

According to the Mares app (Android) I have a Mares Puck Pro EZ. According to the QR code on the box that sent me to the manual, it's a "Pick Lite". I believe some model number associated with this is 414177.

I can download dives to the Mares app (Android), but there is no export option that I can find. I assume I may be able to download to Mares Windows app and export, but I'm not sure given I don't have a Windows computer. Wine? Virtualbox? Seems unlikely to work well with Bluetooth.

I'd prefer to use Subsurface on Android or Linux. 

On Android, the phone does not see the dive computer via the phone Bluetooth (the Mares app connects directly). The Subsurface android app (side-load APK) also does not see the dive computer, nor does it show it if I select "Temporarily show all bluetooth" under Advanced Settings. So, no luck on Android.

On my laptop (Debian Trixie) the OS Bluetooth selector shows "Puck" but when I try to connect (no pin or manual pin 0000 or 1234) the computer switches from displaying the MAC address to "CONNECT", but the computer reports "The setup of Pick has failed".

If I don't try to pair at the OS level, and just use Subsurface (Linux) I can see select "Puck Lite" under Dive Computer, and see the MAC address under "Choose Bluetooth download mode". When I then select "Retry download" the Mares computer switches from displaying the MAC address to "Connect". The Subsurface app reports "Starting import...", and then about 10 seconds later errors out with "Dive data import error".

The log file looks similar to (but not identical to) https://groups.google.com/g/subsurface-divelog/c/8RdyU7viDzA/m/sWltlzcSAwAJ .

I have a few questions:

0) The manual has a lengthy section on setting up bluetooth connections https://subsurface-divelog.org/subsurface-user-manual/?lang=en#S_HowFindBluetoothDeviceName  I have not done all of that, because things seem to be working just using the Subsurface GUI (based on the watch responding to the connection). Am I skipping important steps?

1) Should I attach log files here? Or are most communications happening on GitHub?

2) I'm happy to (try!) to write code to help solve this. Is adding support for another computer part of Subsurface, or is it libdc?

Thanks,

    -k.

[Jef Driesen]

On 23 August 2025 07:09:49 CEST, Ken Mankoff <man...@gmail.com> wrote:
>1) Should I attach log files here? Or are most communications happening on
>GitHub?

Yes, without the logs we don't know exactly what went wrong.

Jef

[Jef Driesen]

On 23 August 2025 15:22:24 CEST, Ken Mankoff <man...@gmail.com> wrote:
>Hi Jef,
>
>On 2025-08-23 at 05:31 -07, Jef Driesen <j...@libdivecomputer.org> wrote...

>No dumpfile is generated. The logfile is cut-and-paste below. I'd be happy to try to fix this if you can provide any guidance. Hopefully it's just some small tweaks here? https://github.com/subsurface/libdc/blob/4e4f1f7ac59c8827d2cdd58cbb2ec78f92d038b2/src/mares_puck.c

Don't enable the dumpfile option because it's not supported by all models.

Can you also send the subsurface debug output? Run subsurface from the command-line and redirect the output to a file:

subsurface -v -v > debug.log 2>&1

Jef

[Ken Mankoff]

Hi Jef,

On 2025-08-23 at 05:31 -07, Jef Driesen <j...@libdivecomputer.org> wrote...

No dumpfile is generated. The logfile is cut-and-paste below. I'd be happy to try to fix this if you can provide any guidance. Hopefully it's just some small tweaks here? https://github.com/subsurface/libdc/blob/4e4f1f7ac59c8827d2cdd58cbb2ec78f92d038b2/src/mares_puck.c

Thanks,

-k.


Subsurface: v6.0.5404.0, built with libdivecomputer v0.9.0-devel-Subsurface-NG (26221352623426bbc36166c9eccde923d1879cb9)
[0.000000] INFO: Open: transport=32
[0.001659] INFO: Configure: baudrate=115200, databits=8, parity=2, stopbits=0, flowcontrol=0
[0.001664] INFO: Timeout: value=3000
[0.001666] INFO: DTR: value=0
[0.001667] INFO: RTS: value=0
[0.001668] INFO: Purge: direction=3
[0.003039] INFO: Write: size=2, data=C267
[0.094490] INFO: Read: size=142, data=AA000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005075636B00000000000000000000000030312E30342E30340104040030372D30332D32350000444546494E495245000000000000000000000000000000000000000000000000EA
[0.095845] DEBUG: Version: size=140, data=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005075636B00000000000000000000000030312E30342E30340104040030372D30332D32350000444546494E495245000000000000000000000000000000000000000000000000
Event: vendor=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005075636B00000000000000000000000030312E30342E30340104040030372D30332D32350000444546494E495245000000000000000000000000000000000000000000000000
[0.098144] INFO: Write: size=2, data=E742
[0.189678] INFO: Read: size=1, data=AA
[0.190500] INFO: Write: size=8, data=0000000080000000
[3.193198] INFO: Read: size=0, data=
[3.193207] ERROR: Failed to receive the packet data. [in src/mares_iconhd.c:345 (mares_iconhd_packet_variable)]
[3.193211] INFO: Sleep: value=1000
[4.193636] INFO: Purge: direction=1
[4.195060] INFO: Write: size=2, data=E742
[4.277488] INFO: Read: size=1, data=AA
[4.278770] INFO: Write: size=8, data=0000000080000000
[7.283845] INFO: Read: size=0, data=
[7.283853] ERROR: Failed to receive the packet data. [in src/mares_iconhd.c:345 (mares_iconhd_packet_variable)]
[7.283857] INFO: Sleep: value=1000
[8.284022] INFO: Purge: direction=1
[8.285494] INFO: Write: size=2, data=E742
[8.378991] INFO: Read: size=1, data=AA
[8.380176] INFO: Write: size=8, data=0000000080000000
[11.381565] INFO: Read: size=0, data=
[11.381575] ERROR: Failed to receive the packet data. [in src/mares_iconhd.c:345 (mares_iconhd_packet_variable)]
[11.381580] INFO: Sleep: value=1000
[12.381662] INFO: Purge: direction=1
[12.382955] INFO: Write: size=2, data=E742
[12.475119] INFO: Read: size=1, data=AA
[12.476312] INFO: Write: size=8, data=0000000080000000
[15.484140] INFO: Read: size=0, data=
[15.484152] ERROR: Failed to receive the packet data. [in src/mares_iconhd.c:345 (mares_iconhd_packet_variable)]
[15.484157] INFO: Sleep: value=1000
[16.484498] INFO: Purge: direction=1
[16.485901] INFO: Write: size=2, data=E742
[16.568188] INFO: Read: size=1, data=AA
[16.569492] INFO: Write: size=8, data=0000000080000000
[19.571404] INFO: Read: size=0, data=
[19.571414] ERROR: Failed to receive the packet data. [in src/mares_iconhd.c:345 (mares_iconhd_packet_variable)]

[Ken Mankoff]

Hi Jef,

FYI I've just built subsurface from source. I hope the issue is something I can configure in a pre-built version, but if not, any hints you can provide may be helpful if I can fix this in code.

-k.

[Ken Mankoff]

Hi Jef,

On 2025-08-23 at 07:41 -07, Ken Mankoff <man...@gmail.com> wrote...

> FYI I've just built subsurface from source. I hope the issue is
> something I can configure in a pre-built version, but if not, any
> hints you can provide may be helpful if I can fix this in code.

I've also built libdivecomputer and am able to run ./example/dtcool. But am not sure how to connect it to my Mares. When I show up only a random Pi computer in my house is listed, unlike all the things listed when Subsurface "show all" is selected.

Anyway, if I can send more useful debug info directly from libdivecomputer, let me know.

-k.

[Jef Driesen]

On 24/08/2025 00:28, Ken Mankoff wrote:
> On 2025-08-23 at 07:41 -07, Ken Mankoff <man...@gmail.com> wrote...
>> FYI I've just built subsurface from source. I hope the issue is
>> something I can configure in a pre-built version, but if not, any
>> hints you can provide may be helpful if I can fix this in code.
>
> I've also built libdivecomputer and am able to run ./example/dtcool. But am not sure how to connect it to my Mares. When I show up only a random Pi computer in my house is listed, unlike all the things listed when Subsurface "show all" is selected.

That's because libdivecomputer has no built-in support for Bluetooth Low Energy
(BLE). Hence the low-level BLE communication needs to be implemented by the
application instead. That's why dctool can only find Bluetooth Classic devices.

> Anyway, if I can send more useful debug info directly from libdivecomputer, let me know.

I suspect the reason why the download fails is because your Puck Pro EZ is using
the newer Genius/Sirius variant of the communication protocol. This requires
some changes in the code. Can you apply the attached patch to libdivecomputer,
re-build subsurface and then try to download your dives again with the
libdivecomputer logging enabled.

Note that the patch is incomplete and may still fail. We don't know the correct
model number of this new model yet. In the patch I simply mapped the new ID
string onto an existing model. This correct model number will be in the download
log, and with that info we can add the missing bits and pieces.

In the subsurface log file I also don't see the bluetooth discovery. Can you
generate another subsurface debug log and then scan again for the bluetooth
devices? I need the bluetooth device name to implement the autodetection and
avoid the need to use the "Show all BT devices" workaround.

Does your model have an option to use a USB cable, or is it BLE only?

Jef

[Ken Mankoff]

Hi Jef,

On 2025-08-25 at 03:22 -07, Jef Driesen <j...@libdivecomputer.org> wrote...

> I suspect the reason why the download fails is because your Puck Pro
> EZ is using the newer Genius/Sirius variant of the communication
> protocol. This requires some changes in the code. Can you apply the
> attached patch to libdivecomputer, re-build subsurface and then try to
> download your dives again with the libdivecomputer logging enabled.

I'm choosing model "Puck Pro" in the surface interface. Should I choose something else? Just plain "Puck" "Genius" "Sirius"?

Attached is the log (subsurface.log) and the printed output to the terminal (subsurface_exec.log) from running "./build/subsurface" after recompiling. Also a screenshot that may help.

> In the subsurface log file I also don't see the bluetooth discovery.
> Can you generate another subsurface debug log and then scan again for
> the bluetooth devices? I need the bluetooth device name to implement
> the autodetection and avoid the need to use the "Show all BT devices"
> workaround.

I did this and don't see the device name, but I think it's in the screenshot and in the subsurface_exec.log.

> Does your model have an option to use a USB cable, or is it BLE only?

It is BLE only. But it's new and I can return it and switch to one with USB cable. That is why I sent the other email about the Zoop Novo. That has a USB cable to USB-A (not USB-to-Bluetooth adapter).

I'm a huge fan of cables over bluetooth. I prefer cables for my headphones and custom built mechanical keyboards. I have recently switched to bluetooth headphones but only due to limited options remaining with cables and it's a mature protocol there, not like this. I'm wary of bluetooth here because I see from other threads that even when it works today, if the dive computer updates firmware, it may not work in the future.

I didn't fully understand your other email when I asked about cables. Maybe because I asked about Zoop Novo and you responded about the Mares Bluelink Pro. I don't have that, I just have the Puck Pro EZ with *builtin* bluetooth. But if cables are guaranteed to work, I'd seriously consider switching to Zoop Novo with direct cable interface.

Best,

-k.

[Jef Driesen]

On 25/08/2025 16:14, Ken Mankoff wrote:
> On 2025-08-25 at 03:22 -07, Jef Driesen <j...@libdivecomputer.org> wrote...
>> I suspect the reason why the download fails is because your Puck Pro
>> EZ is using the newer Genius/Sirius variant of the communication
>> protocol. This requires some changes in the code. Can you apply the
>> attached patch to libdivecomputer, re-build subsurface and then try to
>> download your dives again with the libdivecomputer logging enabled.
>
> I'm choosing model "Puck Pro" in the surface interface. Should I choose something else? Just plain "Puck" "Genius" "Sirius"?

The "Puck Pro" option is okay. As long as you choose one of the newer models
it's fine. It doesn't matter which one.

> Attached is the log (subsurface.log) and the printed output to the terminal (subsurface_exec.log) from running "./build/subsurface" after recompiling. Also a screenshot that may help.

It looks like the libdivecomputer submodule wasn't build with the patch I
attached. Did you forgot to apply it, or maybe libdivecomputer wasn't rebuild
correctly?

Anyway, if it's easier for you, you can also try with this custom build of the
dctool command-line client:

https://libdivecomputer.org/builds/experimental/linux/puckpro-ble

Download and execute with these options:

wget https://libdivecomputer.org/builds/experimental/linux/puckpro-ble
chmod +x puckpro-ble
./puckpro-ble -vv -l puck.log -f iconhd -m 0x31 download -o puck.xml -t ble

>> In the subsurface log file I also don't see the bluetooth discovery.
>> Can you generate another subsurface debug log and then scan again for
>> the bluetooth devices? I need the bluetooth device name to implement
>> the autodetection and avoid the need to use the "Show all BT devices"
>> workaround.
>
> I did this and don't see the device name, but I think it's in the screenshot and in the subsurface_exec.log.

It's there now, both in the log and in your screenshot. The bluetooth device
name is "Puck".

>> Does your model have an option to use a USB cable, or is it BLE only?
>
> It is BLE only. But it's new and I can return it and switch to one with USB cable. That is why I sent the other email about the Zoop Novo. That has a USB cable to USB-A (not USB-to-Bluetooth adapter).
>
> I'm a huge fan of cables over bluetooth. I prefer cables for my headphones and custom built mechanical keyboards. I have recently switched to bluetooth headphones but only due to limited options remaining with cables and it's a mature protocol there, not like this. I'm wary of bluetooth here because I see from other threads that even when it works today, if the dive computer updates firmware, it may not work in the future.
>
> I didn't fully understand your other email when I asked about cables. Maybe because I asked about Zoop Novo and you responded about the Mares Bluelink Pro. I don't have that, I just have the Puck Pro EZ with *builtin* bluetooth. But if cables are guaranteed to work, I'd seriously consider switching to Zoop Novo with direct cable interface.

My question regarding USB or BLE was mainly to make sure I mark the model
correctly as supporting USB or BLE. This information is used by applications
like subsurface to offer you BLE or USB. There is no point in offering USB if
that is not supported by the device. That's all.

Whether you prefer an USB enabled dive computer is of course up to you. I
suspect that once we have added the necessary changes for your Puck Pro EZ,
downloading over BLE will work just fine (and has the advantage to also work
with mobile phones, which is not the case for most USB dive computers).

Jef

[Ken Mankoff]

Hi Jef,

On 2025-08-25 at 07:51 -07, Jef Driesen <j...@libdivecomputer.org> wrote...

> On 25/08/2025 16:14, Ken Mankoff wrote:
>> On 2025-08-25 at 03:22 -07, Jef Driesen <j...@libdivecomputer.org> wrote...

> It looks like the libdivecomputer submodule wasn't build with the
> patch I attached. Did you forgot to apply it, or maybe libdivecomputer
> wasn't rebuild correctly?

Strange. I went into both the subsurface and subsurface/libdivecomputer folders (libdivecomputer is a git submodule) and ran "git clean -fdx ." I did apply the batch (git diff shows this to me now). The patch is tiny, just one new line: I then re-ran ./subsurface/scripts/build.sh

{"Puck", PUCK4},

I'm not sure why the log is not what you expect.

> ./puckpro-ble -vv -l puck.log -f iconhd -m 0x31 download -o puck.xml
> -t ble

Looks like it worked! See log and xml attached.

-k.

[Martin Schuessler]

I'm having a similar problem with the Puck Pro Ultra (Supposedly the same as the Lite). Subsurface doesn't find the computer at all when using the app on my laptop and scanning for devices. 

[Jef Driesen]

On 26 August 2025 17:24:30 CEST, Martin Schuessler <martin.s...@gmail.com> wrote:
>I'm having a similar problem with the Puck Pro Ultra (Supposedly the same
>as the Lite). Subsurface doesn't find the computer at all when using the
>app on my laptop and scanning for devices.

I assume you are using Windows? In that case you need to pair the device using the windows control panel first.

Jef

[Jef Driesen]

On 25/08/2025 20:37, Ken Mankoff wrote:
> Strange. I went into both the subsurface and subsurface/libdivecomputer folders (libdivecomputer is a git submodule) and ran "git clean -fdx ." I did apply the batch (git diff shows this to me now). The patch is tiny, just one new line: I then re-ran ./subsurface/scripts/build.sh
>
> {"Puck", PUCK4},
>
> I'm not sure why the log is not what you expect.

Normally in the build log you should see libdivecomputer re-building the
mares_iconhd object:

CC mares_iconhd.lo
CCLD libdivecomputer.la

>> ./puckpro-ble -vv -l puck.log -f iconhd -m 0x31 download -o puck.xml
>> -t ble
>
> Looks like it worked! See log and xml attached.

The model number is the same as the Puck 4. I already pushed the changes:

https://github.com/libdivecomputer/libdivecomputer/commit/461138f7709223a490a61a29519b7199c2f2831c

(That one-liner from my previous patch is the important part.)

Jef

[Ken Mankoff]

Hi Jef,

On 2025-08-27 at 05:22 -07, Jef Driesen <j...@libdivecomputer.org>
wrote...

> The model number is the same as the Puck 4. I already pushed the
> changes:
> https://github.com/libdivecomputer/libdivecomputer/commit/461138f7709223a490a61a29519b7199c2f2831c

Thanks! This is great news. I have just built a custom version of subsurface with your patch applied to ldc (it worked this time) and imported from a Puck Pro EZ.

Do you have any estimates about how long it takes for these commits (I assume on ldc head?) to propagate to official builds of subsurface?

-k.

[Martin Schuessler]

Jef: Thanks for your reply. It took me a while but I got my Puck Ultra to be seen by my Android device. When I tell it to download the dive information, it says "no information was retrieved" (or something like that). I assume the Puck Pru Ultra is basically a rebadged Lite. Do you plan on incorporating this patch to your latest release? The Android App was able to successfully download information from my older Puck Pro using the Mares BT reader. On my PC, the program still doesn't "see" the Puck. It sees my TV and a few other devices, but not the Puck Ultra. I've hit "scan" several times and turned on the option to show all devices.

Thank you for supporting this program though - it's very impressive.

[Martin Schuessler]

I just sideloaded the latest development app (Subsurface-mobile-6.0.5430-CICD-release.apk) from the website to my S25 and now see the Puck Lite and Puck 4 listed. Unfortunately, it still says "no new dives were downloaded" when I tried those two protocols.

[Martin Schuessler]

Shoot - I forgot to mention that Subsurface detects my Puck model as "Puck Pro U LE" (followed by the MAC address)

[Michael Keller]

Hi Martin.

On Tue, 2 Sept 2025 at 08:36, Martin Schuessler <martin.s...@gmail.com> wrote:

Do you plan on incorporating this patch to your latest release?

I have cherry-picked it, it is available in 6.0.5432 (and newer) on https://subsurface-divelog.org/latest-release/.

Ngā mihi

  Michael Keller

--

GCS$/CC/E/IT d- s+ a C++ UL+++/S++ P L++ E-
W++ N o? K? w O(++) M-- V+ PS+ PE+ Y? PGP+ t
5? X R tv b++ DI++ D++ G e+++ h---- r+++ y+++

[Jef Driesen]

On 2025-09-02 00:07, Martin Schuessler wrote:
> I just sideloaded the latest development app
> (Subsurface-mobile-6.0.5430-CICD-release.apk) from the website to my
> S25 and now see the Puck Lite and Puck 4 listed. Unfortunately, it
> still says "no new dives were downloaded" when I tried those two
> protocols.
>
> On Monday, September 1, 2025 at 3:36:18 PM UTC-5 Martin Schuessler
> wrote:
> Jef: Thanks for your reply. It took me a while but I got my Puck Ultra
> to be seen by my Android device. When I tell it to download the dive
> information, it says "no information was retrieved" (or something like
> that). I assume the Puck Pru Ultra is basically a rebadged Lite. Do you
> plan on incorporating this patch to your latest release? The Android
> App was able to successfully download information from my older Puck
> Pro using the Mares BT reader. On my PC, the program still doesn't
> "see" the Puck. It sees my TV and a few other devices, but not the Puck
> Ultra. I've hit "scan" several times and turned on the option to show
> all devices.
>
> Thank you for supporting this program though - it's very impressive.

I suspect the Puck Pro Ultra will also need a small fix in the code
(similar to the EZ one). To get the information I need, can you generate
a debug log and send it to me? You can find the instructions here:

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

Jef

[Martin Schuessler]

Jef: Unfortunately, I have *never* detected either of my Puck devices (Puck Ultra with built-in BLE orPuck Pro with Mares BT adapter) on my PC (Win11). I tried to add/find the device with the built-in Windows BT menu, and using the "Rescan" function in Subsurface (showing "all" devices). I do detect other BT-enabled devices in my house. Do you know what the problem might be?

Alternatively - is there a way to generate the log file from my Android device?

[Martin Schuessler]

Once again - I'm a moron. Apparently you don't need a checkbox to generate the logs as they're generated automatically. I followed the instructions and sent an email to you Jef. Sorry for being dense and not reading ALL the instructions. ;)  Hopefully the logs are useful...

Martin

[Jef Driesen]

On 2/09/2025 20:48, Martin Schuessler wrote:
> Jef: Unfortunately, I have *never* detected either of my Puck devices (Puck
> Ultra with built-in BLE orPuck Pro with Mares BT adapter) on my PC (Win11). I
> tried to add/find the device with the built-in Windows BT menu, and using the
> "Rescan" function in Subsurface (showing "all" devices). I do detect other
> BT-enabled devices in my house. Do you know what the problem might be?

On Windows you first need to pair the bluetooth device using the windows control
panel. Otherwise subsurface won't be able to find it.

I already extracted some information from your log files, but I'm still missing
the model number. I suspect it will be the same as the Puck 4, but I need to
confirm that. In order to do that you need to run a patched version of
subsurface. If you can get the Windows version working, that would be the
easiest option. (On Android it's a bit more annoying because you'll have to
uninstall the official build before you can install a custom build.)

Jef

[Martin Schuessler]

Like I mentioned: I have never been able to detect any of my two computers using the Windows bluetooth settings. It's very frustrating.

It's OK if I need to sideload a development build for Android - I'm currently running Subsurface-mobile-6.0.5430-CICD-release.apk.

Martin

---

From: Jef Driesen <j...@libdivecomputer.org>
Sent: Tuesday, September 2, 2025 3:23 PM
To: subsurfac...@googlegroups.com <subsurfac...@googlegroups.com>; Martin Schuessler <martin.s...@gmail.com>
Subject: Re: Mares Puck Pro EZ (Puck Lite?)