- devel - libdivecomputer.org

Timeout for Halcyon Symbios
by libdivecomputer.vanity547＠simplelogin.com 30 Dec '25

30 Dec '25

Hi, I am currently testing the download from a Halcyon Symbios device using a BLE connection, and I noticed very frequent timeouts. To compare, the same code works very reliably with Shearwater devices, I own also a Perdix and a Petrel 2. I noticed the timeout is the same for Halcyon Symbios and Shearwater: https://github.com/libdivecomputer/libdivecomputer/blob/4f5abbddc66843c83fa… https://github.com/libdivecomputer/libdivecomputer/blob/4f5abbddc66843c83fa… ``` // Set the timeout for receiving data (3000ms). status = dc_iostream_set_timeout (device->iostream, 3000); ``` In my tests, the Halcyon device often timeouts immediately while negotiating the connection: ``` 2025-12-28 17:17:49.451313+0100 0x90987 Info 0x0 36508 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Connecting to device: C4037FA6-7E9F-962F-79AF-1F4978C8A443 2025-12-28 17:17:49.452269+0100 0x90987 Info 0x0 36508 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Successfully opened device: C4037FA6-7E9F-962F-79AF-1F4978C8A443 2025-12-28 17:17:52.661264+0100 0x90991 Error 0x0 36508 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Download failed with status: Timeout (-7) 2025-12-28 17:17:52.661388+0100 0x90987 Info 0x0 36508 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Disconnecting from device: C4037FA6-7E9F-962F-79AF-1F4978C8A443 ``` or after downloading the first dive: ``` 2025-12-28 17:17:05.026093+0100 0x904fa Info 0x0 36165 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Connecting to device: C4037FA6-7E9F-962F-79AF-1F4978C8A443 2025-12-28 17:17:05.027610+0100 0x904fa Info 0x0 36165 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Successfully opened device: C4037FA6-7E9F-962F-79AF-1F4978C8A443 2025-12-28 17:17:11.716335+0100 0x904fb Debug 0x0 36165 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Dive callback called: size=12524, downloaded so far=0, maxDives=Optional(3) 2025-12-28 17:17:11.725085+0100 0x904fb Debug 0x0 36165 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Dive processed successfully, returning 1 (continue) 2025-12-28 17:17:16.944712+0100 0x904fb Error 0x0 36165 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Download failed with status: Timeout (-7) 2025-12-28 17:17:16.944939+0100 0x904fa Info 0x0 36165 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Disconnecting from device: C4037FA6-7E9F-962F-79AF-1F4978C8A443 ``` From various tests, it looks like Symbios often requires up to 5s. I changed the timeout to 10s and it works quite reliably now. In my binding I implemented the `set_timeout` callback to set the timeout specifically for this device type, so that I don't need to change/customize the libdivecomputer C source code and maintain a fork. However, I am wondering if this is a change you would be interested to apply directly to the libdivecomputer C code, considering you have per-device timeouts. If so, I can likely provide a patch. Let me know what do you think. And thanks for the amazing lib! Best, -- Simone

2 2

[ANNOUNCE] Version 0.9.0 now available
by Jef Driesen 30 Jun '25

30 Jun '25

Hi, The v0.9.0 release is now available! https://libdivecomputer.org/releases/libdivecomputer-0.9.0.tar.gz The v0.9.0 release adds support for several new devices. It also introduces some important parser api changes to be able to add some new features and remove a few deprecated ones. Some BLE enabled dive computers also required some extra additions to the BLE I/O layer. Due to all these api changes, this release is not backwards compatible. New features: * Add support for new backends: - i330r: Aqualung i330R, Apeks DSX - symbios: Halcyon Symbios * Add support for some new devices: - Aqualung: i100 - Cressi: Leonardo 2.0, Nepto, Archimede - Heinrichs Weikamp: OSTC 5 - Mares: Puck Air 2, Sirius, Quad Ci, Puck 4, Puck Lite - Ratio: iDive 2, iX3M 2 GPS - Scubapro: G3, Luna 2.0, Luna 2.0 AI - Seac: Tablet - Shearwater: Tern, Tern TX, Peregrine TX - Uwatec: Aladin One * Add the sensor index to the ppO2 sample * Add a TTS field to the deco sample * Add a usage field to the tank and gas mix * Export the filter function in the public api * Add ioctl's for the bluetooth authentication * Add ioctl's for reading and writing BLE characteristics * Add helper functions to convert UUID to/from strings * Add a new field to report the GPS location Removed/changed features: * Change the units for the sample time to milliseconds * Pass the sample struct by reference * Remove the backend specific calibration functions * Remove the clock parameters from the constructor * Remove the dc_parser_set_data function * Use separate data structures for USB and USB HID * Replace the dc_descriptor_iterator function Jef

1 0

Recording data exchange under Windows 11
by divebuddy.berlin＠gmail.com 08 May '25

08 May '25

Good morning to the community I have been given a new dive computer to test, which is currently not supported by Libdive. It is the "SEAC Tablet". I have been trying to record the data exchange between the software and the device under Windows 11 for a few days now. However, I seem to be too stupid for it, I can't find any tools that work either serially or via BLE. The actually good instructions at https://libdivecomputer.org/contribute.html no longer seem to work under Windows 11. Does anyone have any other ideas on how I can get the data so that the dive computer can be supported by Libdive in future? I am hoping for integration in Subsurface. Many thanks Andreas

3 5

could not build 0.9 fresh from github.
by ostc 27 Apr '25

27 Apr '25

Hi all Downloaded everything fresh from github. tried to compile the libdivecomputer today, but could not pass ./configure, see error below. should I go back to version 0.80 instead of 0.9? checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for windres... no checking for gcc... (cached) gcc checking whether the compiler supports GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to enable C11 features... (cached) none needed checking whether gcc understands -c and -o together... (cached) yes checking dependency style of gcc... (cached) gcc3 ./configure: line 14315: syntax error near unexpected token `newline' ./configure: line 14315: ` '''

2 2

Using libdivecomputer dctool with Shearwater Perdix on macOS
by libdivecomputer.vanity547＠simplelogin.com 23 Apr '25

23 Apr '25

Hello, I’m exploring this library and started by trying to use libdivecomputer to download dives from my Perdix computer on macOS. I experimented with dctool, but haven’t had any success so far. I also read several threads in this list dating back to 2021 but couldn’t find any recent examples. Here’s the baseline command I’ve been running for testing: $ dctool -v -l perdix-download.log -d perdix download -f raw -o perdix-download.raw I’ve gone back and forth between using serial and ble as transport methods, but neither has worked. However, I can successfully connect to the Perdix via both MacDive and Subsurface. I initially tried the serial transport, based on a 2021 post mentioning issues with Bluetooth on macOS. For the serial attempt, I’m bridging the BLE connection to a serial interface: $ core-bluetooth-tool bridge FE25C237-0ECE-443C-B0AA-E02033E7029D Created /dev/ttys003. Ready to communicate. Scanning for devices with service UUID FE25C237-0ECE-443C-B0AA-E02033E7029D… Connected to BLE device via ble://FE25C237-0ECE-443C-B0AA-E02033E7029D. But this results in the following failure: dctool -v -l ~/Downloads/perdix-download.log -d perdix download -f raw -o perdix-download.raw /dev/ttys003 DATETIME 2025-04-14T17:17:52Z (1744651072) VERSION 0.8.0 Opening the I/O stream (serial, /dev/ttys003). INFO: Open: name=/dev/ttys003 Opening the device (Shearwater Perdix). INFO: Configure: baudrate=115200, databits=8, parity=0, stopbits=0, flowcontrol=0 INFO: Timeout: value=3000 INFO: Sleep: value=300 INFO: Purge: direction=3 Registering the event handler. Registering the cancellation handler. Downloading the dives. Event: progress 0.00% (0/4294967295) INFO: Write: size=8, data=FF010400228010C0 INFO: Read: size=0, data= ERROR: Failed to receive the packet. [in shearwater_common.c:239 (shearwater_common_slip_read)] ERROR: Failed to receive the response packet. [in shearwater_common.c:358 (shearwater_common_transfer)] ERROR: Failed to read the serial number. [in shearwater_petrel.c:173 (shearwater_petrel_device_foreach)] ERROR: Error downloading the dives. [in dctool_download.c:230 (download)] INFO: Write: size=9, data=FF0105002E902000C0 ERROR: Timeout After inspecting the Subsurface logs, I noticed it uses the ble transport, so I tried that as well. Unfortunately, dctool doesn’t even find the device. I’m not sure about the expected format of the <devname> argument when using BLE, so I may be using the wrong value (I used the device UUID): dctool -v -l ~/Downloads/perdix-download.log -d perdix download -f raw -o perdix-download.raw -t ble EE4DCD15-387F-249F-B006-6F879C1D430C DATETIME 2025-04-14T17:20:25Z (1744651225) VERSION 0.8.0 Opening the I/O stream (ble, EE4DCD15-387F-249F-B006-6F879C1D430C). ERROR: Error opening the I/O stream. [in dctool_download.c:170 (download)] ERROR: Unsupported operation Below is the beginning of a successful connection log from Subsurface. I tried to reverse-engineer the correct options for dctool from this, but I haven’t had any luck: Subsurface: v6.0.5365.0, built with libdivecomputer v0.9.0-devel-Subsurface-NG (d2874be4fcb58385a62b335b7132aa17c4294925) [0.000001] INFO: Open: transport=32 [0.000441] INFO: Configure: baudrate=115200, databits=8, parity=0, stopbits=0, flowcontrol=0 [0.000448] INFO: Timeout: value=12000 [0.000453] INFO: Sleep: value=300 [0.303744] INFO: Purge: direction=3 [0.305630] INFO: Write: size=10, data=0100FF010400228010C0 [0.369066] INFO: Read: size=18, data=010001FF0C006280103337304434433145C0 [0.369273] INFO: Write: size=10, data=0100FF010400228011C0 [0.430419] INFO: Read: size=21, data=010001FF0F0062801156393320436C6173736963C0 [0.430584] INFO: Write: size=10, data=0100FF010400228050C0 [0.481059] INFO: Read: size=12, data=010001FF06006280508D6CC0 Event: model=6 (0x00000006), firmware=93 (0x0000005d), serial=... (...) [0.482590] INFO: Write: size=10, data=0100FF010400228021C0 [0.545530] INFO: Read: size=19, data=010001FF0D00628021018000000000020080C0 I’d really appreciate any pointers on how to get dctool working with the Perdix on macOS, especially using BLE. Thanks, -- Simone

2 3

macOS, Bluetooth, and BLE
by Angus 06 Mar '25

06 Mar '25

So I was digging into a minor mystery with some dive info, and remembered reading about dctool and thought it would be a quick way to see what info a dive computer was providing. I ended up going down quite the libdivecomputer rabbit hole. BLUETOOTH If I’m understanding everything correctly, libdc doesn’t support Bluetooth (classic) on macOS, as BLUETOOTH is never defined for macOS in bluetooth.h. After digging around, found some old threads about it. [1] [2] [1] Native bluetooth communications https://libdivecomputer.org/pipermail/devel/2014-May/000285.html [2] Is there a way to build with bluetooth support on a mac? https://libdivecomputer.org/pipermail/devel/2021-May/001187.html As for the call for macOS help, I’m not an expert macOS programmer (or C coder for that matter) and have no experience with Bluetooth. I do know Apple’s best documentation is often in their header files. Alas, it looks like Apple has depreciated some of their C API for the IOBluetooth framework [3]. I didn’t check when, but at least as far back as macOS 10.9. [3] https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX11.3.sdk/System/L… I never liked Objective-C, and am not very experienced with it. It’s a superset of C, and I don’t believe it would be straightforward to use the Obj-C IOBluetooth API from C code. (Side note: IOBluetooth is macOS only, supports classic Bluetooth. The other framework, CoreBluetooth, is more BLE forcused, cross platform, but does not support most classic profiles). BLE After looking at the device table in ldc, it seemed putting effort into Bluetooth Classic on macOS might not even be worth it as not many devices support Bluetooth Classic. Many more support BLE, so I started to look into if that’s supported on macOS. ble.c didn’t have much in it, and couldn’t find much of a ble transport implementation in ldc. Is that being provided by the applications (SubSurface, iOS MacDive) vs in libdivecomputer itself? Assuming that is true, is that because the BLE frameworks were very platform specific? Are apps implementing BLE as custom I/O as described in the I/O layer refactoring back in 2018? Thanks for any corrections or pointers to things I’ve missed. Angus

2 1

Re: Cressi Archimede support
by Tom Staut 06 Feb '25

06 Feb '25

Hello Jef, In the mean I tried to connect multiple times, with the same result. From Cressi, I received the following: -- Good afternoon, thank you for contacting us. I am sorry but we cannot provide the requested documentation. The interface was made for us by another company so we do not have the requested data. If you have any questions, please write to me and I will try to help you. Thank you and have a nice day, -- This means that we have to sort out the protocol ourselves. I will try this weekend to get the old Win95 machine running. What should I install to capture the USB communication into a file that you can analyse? Sorry to keep contacting you, but I need some help with this as I am not that experienced in IT. Kind Regards, Tom. Op di 4 feb 2025 om 14:37 schreef Tom Staut <tom.staut(a)gmail.com>: > Hello Jef, > > I tried to connect several times, but it was always with a different > protocol. > I will try again this evening. > > I do not know how to capture the signals via windows VM, so some help > there would be welcome. > I can also try to revive my old win95 PC for just once in order to try to > capture there the communication, but also with this I would need some > assistance. > > In the mean time, I reached out to Cressi support. > Please see the e-mails below. > Let's hope they can help out for the benefit of not only me. > > Kind Regards, > Tom. > ---------- Forwarded message --------- > Van: Tom Staut <tom.staut(a)gmail.com> > Date: di 4 feb 2025 om 14:29 > Subject: Re: Cressi - New information request 2025-02-01-BBWF4KPA > To: eleonora milanesi <eleonora.milanesi(a)cressi.com> > > > Hello Miss Milanesi, > > Thank you for responding. > I understand that it is no longer supported. > > However, I am currently in contact with developers of "SubSurface", which > is a scuba logging software platform. > Could it be possible to obtain the documentation from Archimede I on how > the dive computer communicates with a PC? > That would help to incorporate the Archimede into this SubSurface platform. > For your information, Subsurface currently provides support for: > https://subsurface-divelog.org/supported-dive-computers/?lang=en > > Kind Regards, > Tom. > > Op di 4 feb 2025 om 14:13 schreef eleonora milanesi < > eleonora.milanesi(a)cressi.com>: > > Good afternoon, > thank you for contacting us. > The Archimede I computer has been out of production for several years. > I am sorry but the interface for the Archimede computer is no longer > updated and is not compatible with the new operating systems. > > If you have any questions, please write to me and I will try to help > you. > I wish you a good day, > Eleonora Milanesi > Da: Cressi <no-reply(a)globosoftware.net> > Inviato: sabato 1 febbraio 2025 23:35 > A: eleonora milanesi <eleonora.milanesi(a)cressi.com> > Oggetto: Cressi - New information request 2025-02-01-BBWF4KPA > > Cressi Logo > Cressi catalogues > > New information request: 2025-02-01-BBWF4KPA > > > > Name + Surname: Tom Staut > Email: tom.staut(a)gmail.com > Country of residence: Belgium > Message: Hello, > I am looking for PC logbook software for my Cressi Archimede (I). > My Win95 PC crashed and I need to install on a new pc. > Preferred platform is Linux. If only drivers for Subsurface > program in Linux, this would also be OK. > I have the original clothes pin USB interface and it is detected > in Linux, but logs can not be downloaded. > In Win10, the USB drivers are missing, so if software is only for > Win, then please also indicate where/how the USB can be accessed. > Please keep my Archimede active, as I am very pleased with the > easy operation and interface and send me a link where I can download the > software, or how I can get Subsurface in Linux to download the logs. > Kind Regards and Let's blow some bubbles, > Tom. >

1 0

Cressi Archimede support
by Tom 03 Feb '25

03 Feb '25

Hello, I recently said farewell to my win95 system running PCLogbook from Cressi to read my Cressi Archimede (I) logs. I currently run Subsurface on my Linux Ubuntu system. I can see the Seiko clothes pin USB connector as: Bus 001 Device 012: ID 04b8:0522 Seiko Epson Corp. USB-Serial Controller I can see Subsurface connecting, but no records are retrieved. I tried different other computers to no avail. Is Cressi Archimede supported, or can support be added? Or can I modify settings from, e.g. PID to 0521, or use some other settings? Thank you for helping me out, Tom.

2 3

Windows 11 ARM64
by Stuart Burton 08 Oct '24

08 Oct '24

Hi, Sven Knoch of divinglog.de suggested I ask here. Having upgraded my tablet to Windows 11 ARM64 (from Android) I decided to install Diving Log 6.0 to test for this years dive trip. The dive computer is Suunto Zoop (not Novo) I am using a USB interface from smartinterface.de and have loaded the latest FTDI signed ARM64 drivers. The interface shows as a serial port on COM3. The dive download fails with error ERROR: DC_STATUS_PROTOCOL after starting communication. Logfile is attached. I have downloaded the latest libdivecomputer version from the Diving Log website. The dive computer has plenty of battery life. Trying Suunto SDM3.1.0 shows some communication with the Zoop (serial number) but does not download dives. There are 46 dives present on the Zoop. I would be grateful for any help making this work. Kind regards, Stuart Burton

3 7

Suunto Ocean
by Dave Sturtz 05 Sep '24

05 Sep '24

Hi! Can anyone tell me if & when the new Suunto Ocean might be supported? Thanks, Dave dave(a)sturtz.org

2 1