Cressi Donatello over Bluetooth

[# schnitzel]

Dear all,

I am trying to download dives from a Cressi Donatello. I tried both the mobile version of subsurface for Android and the Linux appImage variant (appImages: 6.0.5576 and  6.05711). In all cases the computer was recognised for what it is. Dive data could not be retrieved (neither with the mobile app nor with the appImages).
The contents of the logfile are:

--------
Subsurface: v6.0.5711.0, built with libdivecomputer v0.10.0-devel-Subsurface-NG (a7ffc96032cfc26e56ddf6d1901701b0e7d4ea53)
[18.087493] INFO: Open: transport=32
[18.087509] INFO: Configure: baudrate=115200, databits=8, parity=0, stopbits=0, flowcontrol=0
[18.087512] INFO: Timeout: value=5000
[18.087514] INFO: RTS: value=0
[18.087515] INFO: DTR: value=0
[18.087518] INFO: Sleep: value=100
[18.187637] INFO: Purge: direction=3
[18.187685] INFO: Ioctl: request=0x40006203 (dir=1, type=98, nr=3, size=0)
[18.302310] INFO: Ioctl read: size=21, data=6E400003B5A3F393E0A9E50E24DC10B8FCB2000004
[18.302322] INFO: Ioctl: request=0x40006203 (dir=1, type=98, nr=3, size=0)
[18.457573] INFO: Ioctl read: size=18, data=6E400004B5A3F393E0A9E50E24DC10B83101
[18.457585] INFO: Ioctl: request=0x40006203 (dir=1, type=98, nr=3, size=0)
[18.604085] INFO: Ioctl read: size=18, data=6E400005B5A3F393E0A9E50E24DC10B81100
[18.604109] DEBUG: Version: size=9, data=FCB200000431011100
Event: vendor=FCB200000431011100
Event: model=4 (0x00000004), firmware=305 (0x00000131), serial=45820 (0x0000b2fc)
[18.604245] INFO: Sleep: value=2000
[20.605773] INFO: Write: size=2, data=0200
[25.613900] INFO: Read: size=0, data=
[25.613910] ERROR: Failed to receive the answer. [in src/cressi_goa.c:241 (cressi_goa_device_download)]
[25.613916] ERROR: Failed to read the logbook data. [in src/cressi_goa.c:593 (cressi_goa_device_foreach)]
--------

Best regards,

George

[Dirk Hohndel]

Again the Donatello.

This is the third report, each slightly different, about BLE download not working.

Yours seems to fail very early with a timeout. Others get some responses back, but then things break down.

I don't know what's going on there, but it's odd to get three different reports for the same device within a few weeks.

I assume multiple attempts get the same result? Or do you see different degrees of progress?

How "noisy" is the RF environment. I have seen (with other dive computers) situations where transmissions got unreliable when a LOT of other BLE devices are around (like in my home office 🤣)

Finally, the usual question about "is the dive computer fully charged". We see situations where the dive computer is happy to work and even allows you to dive, but turning on BLE is too much and things go south (so much for "low energy").

Jef, others, please chime in if I'm asking the wrong questions :)

/D

--
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/4861eedf-4089-4477-8c66-84fd11ad57e2n%40googlegroups.com.

[# schnitzel]

Hello Dirk,

thank you for you swift reply :) The computer battery is charged 3/4 full, the interface is brand new and it took 3 weeks to be delivered, so I guess the battery is fresh.
there were 8-10 BT devices listed in the scan, however only 2-3 were like 0.5 meters from the notebook used. The rest were more than 2 m away.
The failing is consistent, I tried 3-4 times and it always failed at this exact points. It gets recognised, serial is shown and no dive gets downloaded.

Best regards,

George

[Dirk Hohndel]

So this looks like we have a real bug here, not some environmental circumstances that just create random errors...

We'll need to dig into this some more.

/D

PS: you sent three messages with essentially the same content, I picked the "best" one... because we get overrun by spammers otherwise, we have this group set to initially require manual approval of posts, so that can take up to a day sometimes, depending on what Michael and I are doing (and timezones, of course)

To view this discussion visit https://groups.google.com/d/msgid/subsurface-divelog/2503c682-2577-4632-b40f-631bed5a3fb7n%40googlegroups.com.

[Michael Keller]

Hi George.

On 14/9/26 02:51, '# schnitzel' via Subsurface Divelog wrote:
> thank you for you swift reply :) The computer battery is charged 3/4
> full, the interface is brand new and it took 3 weeks to be delivered,
> so I guess the battery is fresh.
> there were 8-10 BT devices listed in the scan, however only 2-3 were
> like 0.5 meters from the notebook used. The rest were more than 2 m away.
> The failing is consistent, I tried 3-4 times and it always failed at
> this exact points. It gets recognised, serial is shown and no dive
> gets downloaded.

Thanks, that confirms this is reproducible and happens before Subsurface
receives any logbook data. The device identification itself succeeds,
but the first BLE logbook request times out.

Could you capture one failed attempt on Linux? This would let us compare
the actual BLE exchange with the protocol implementation.

1. Install `btmon` if it is not already available. On Debian/Ubuntu it
is provided by the `bluez` package.

2. In a terminal, start a capture:

   sudo btmon -w cressi-donatello.btsnoop

3. Leave that terminal running, start Subsurface, and perform one
download attempt from the Donatello.

4. Once it fails, return to the terminal and press Ctrl-C.

Please do not post the resulting `.btsnoop` file publicly. It can
contain Bluetooth device addresses and other metadata. Reply here to
confirm that you have it, and we can arrange a private way to transfer it.

Also, does Cressi's own application download the same dives successfully
using this interface? That will help distinguish a device-side protocol
change from a general Bluetooth problem.


Ngā mihi

  Michael Keller

[Jef Driesen]

On 13/09/2026 15:03, '# schnitzel' via Subsurface Divelog wrote:
> [18.187685] INFO: Ioctl: request=0x40006203 (dir=1, type=98, nr=3, size=0)
> [18.302310] INFO: Ioctl read: size=21,
> data=6E400003B5A3F393E0A9E50E24DC10B8FCB2000004
> [18.302322] INFO: Ioctl: request=0x40006203 (dir=1, type=98, nr=3, size=0)
> [18.457573] INFO: Ioctl read: size=18, data=6E400004B5A3F393E0A9E50E24DC10B83101
> [18.457585] INFO: Ioctl: request=0x40006203 (dir=1, type=98, nr=3, size=0)
> [18.604085] INFO: Ioctl read: size=18, data=6E400005B5A3F393E0A9E50E24DC10B81100
> [18.604109] DEBUG: Version: size=9, data=FCB200000431011100
> Event: vendor=FCB200000431011100
> Event: model=4 (0x00000004), firmware=305 (0x00000131), serial=45820 (0x0000b2fc)
> [18.604245] INFO: Sleep: value=2000
> [20.605773] INFO: Write: size=2, data=0200
> [25.613900] INFO: Read: size=0, data=
> [25.613910] ERROR: Failed to receive the answer. [in src/cressi_goa.c:241
> (cressi_goa_device_download)]

What happens here is that the ioctl calls to read the 3 extra BLE
characteristics work fine, so that means we have a working bluetooth connection
with the device. But we receive no response when sending a command to the main
BLE characteristic. I suspect this may be a case where registering the
notification failed. That would explain the above scenario perfectly: the
ioctl's work because they don't need notifications, sending commands works too
but we can't receive anything.

@George: Can you try again and also capture the subsurface debug output.
Normally a failed notification should show up in the subsurface output. Simply
start subsurface from the command-line and use these arguments:

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

Jef

[# schnitzel]

Hello Jef,

finally I got around doing what you asked for. I have sanitized the file and removed all references to other BT devices. The divecomputer MAC starts with E1:D8 here you go:

----------------------
Bluez 5 detected.
Missing CAP_NET_ADMIN permission. Cannot determine whether a found address is of random or public type.
Creating QtBluezDiscoveryManager
Discovered: "E1:D8:92:60:FC:58" "4_b2fc" Num UUIDs 2 total device 3 cached RSSI -46 Class 0 Num ManufacturerData 0
void QBluetoothDeviceDiscoveryAgentPrivate::stop()
Detecting bluetoothd version
Using /proc/<pid>/exe
Using /proc/<pid>/cmdline
Detected bluetoothd version 5.79
Bluetoothd: "5.79"
Discovered: "E1:D8:92:60:FC:58" "4_b2fc" Num UUIDs 2 total device 9 cached RSSI 0 Class 0 Num ManufacturerData 0
QLowEnergyControllerPrivateBluezDBus::connectToDevice()
###### "org.bluez.Device1" QMap(("RSSI", QVariant(short, -45)))
Updating RSSI for "E1:D8:92:60:FC:58" QVariant(short, -45)
###### "org.bluez.Device1" QMap(("Connected", QVariant(bool, true)))
###### "org.bluez.Device1" QMap(("ServicesResolved", QVariant(bool, true))("UUIDs", QVariant(QStringList, ("00001800-0000-1000-8000-00805f9b34fb", "00001801-0000-1000-8000-00805f9b34fb", "0000180a-0000-1000-8000-00805f9b34fb", "0000180f-0000-1000-8000-00805f9b34fb", "0
000fe59-0000-1000-8000-00805f9b34fb", "6e400001-b5a3-f393-e0a9-e50e24dc10b8", "6e400001-b5a3-f393-e0a9-e50e24dcca9e"))))
void QBluetoothDeviceDiscoveryAgentPrivate::stop()
###### "org.bluez.Device1" QMap()
Read Desc: "\x00\x00"
Read Char: "{6e400003-b5a3-f393-e0a9-e50e24dc10b8}" "fcb2000004"
Read Char: "{6e400004-b5a3-f393-e0a9-e50e24dc10b8}" "3101"
Read Char: "{6e400005-b5a3-f393-e0a9-e50e24dc10b8}" "1100"
Read Char: "{6e400003-b5a3-f393-e0a9-e50e24dcca9e}" "00"
Read Desc: "\x00\x00"
Init CCC change to "0100" "{6e400002-b5a3-f393-e0a9-e50e24dc10b8}" "{6e400001-b5a3-f393-e0a9-e50e24dc10b8}"
Write Desc: "{00002902-0000-1000-8000-00805f9b34fb}" "0100"
Read Char: "{6e400003-b5a3-f393-e0a9-e50e24dc10b8}" "fcb2000004"
Read Char: "{6e400004-b5a3-f393-e0a9-e50e24dc10b8}" "3101"
Read Char: "{6e400005-b5a3-f393-e0a9-e50e24dc10b8}" "1100"
Destroying QtBluezDiscoveryManager
----------------------

Thank you and best regards,

George

[# schnitzel]

Hello Michael,

I got around doing what you asked for, so I can send you the file, as soon as I know how & where.

I did not check with the Cressi App, since I need to create an account with an email etc. However I

checked with subsurface mobile from my Android phone and got exactly the same problem.

Best regards,

George

[Michael Keller]

Hi George.

On 19/09/2026 23:21, '# schnitzel' via Subsurface Divelog wrote:
> I got around doing what you asked for, so I can send you the file, as
> soon as I know how & where.
> I did not check with the Cressi App, since I need to create an account
> with an email etc. However I
> checked with subsurface mobile from my Android phone and got exactly
> the same problem.

You can send it to mike...@subsurface-divelog.org.


Ngā mihi

  Michael Keller

[Michael Keller]

Hi George.

On Sunday, September 20, 2026 at 2:20:50 AM UTC+12 gski...@gmx.de wrote:

I got around doing what you asked for, so I can send you the file, as soon as I know how & where.

I did not check with the Cressi App, since I need to create an account with an email etc. However I

checked with subsurface mobile from my Android phone and got exactly the same problem.

Would you be willing to create the required Cressi account and make one successful download from this same Donatello using Cressi’s Android app? A Bluetooth capture of that successful transfer would let us compare Cressi’s command, write method and response timing with the failing Subsurface transfer.

If your phone has Enable Bluetooth HCI snoop log under Developer options:

1. Enable Bluetooth HCI snoop logging.
2. Perform exactly one successful download in the Cressi app.
3. Disable snoop logging again.
4. Generate an Android bug report, which should contain the Bluetooth capture.

Please send the bug-report archive privately to the same address given for your first capture. Also include the phone model, Android version, Cressi app version, and the approximate time of the download so we can locate it in the capture.

Please do not post the archive publicly. Before sharing it, check it as far as practical for account credentials, Bluetooth addresses or other personal data. 

Ngā mihi

  Michael Keller

[Jef Driesen]

On 19/09/2026 13:15, '# schnitzel' via Subsurface Divelog wrote:
> finally I got around doing what you asked for. I have sanitized the file and
> removed all references to other BT devices. The divecomputer MAC starts with
> E1:D8 here you go:
>

> ...

> Init CCC change to "0100" "{6e400002-b5a3-f393-e0a9-e50e24dc10b8}" "{6e400001-
> b5a3-f393-e0a9-e50e24dc10b8}"
> Write Desc: "{00002902-0000-1000-8000-00805f9b34fb}" "0100"
> Read Char: "{6e400003-b5a3-f393-e0a9-e50e24dc10b8}" "fcb2000004"
> Read Char: "{6e400004-b5a3-f393-e0a9-e50e24dc10b8}" "3101"
> Read Char: "{6e400005-b5a3-f393-e0a9-e50e24dc10b8}" "1100"
> Destroying QtBluezDiscoveryManager

This matches the information in the libdivecomputer log, except for the fact
that there is no trace of the command send to the dive computer. The 3 ioctl to
read the extra characteristics are there, but then nothing. There is also lots
of other information missing. So either you sanitized the log too much or the
command really didn't get send out.

Did you exit subsurface before sending the log? Maybe the last part of the log
wasn't flushed to disk yet?

You can email me the full log privately if you don't want to share it in public.

Jef