Using libdivecomputer dctool with Shearwater Perdix on macOS
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
On 14/04/2025 19:30, libdivecomputer.vanity547@simplelogin.com wrote:
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
Those options are good. Note that if you use the "-f raw" option, you should also use one of the template placeholders (for example %n) in the output file name. Otherwise all dives will get written to the same file, and you end up with only the last downloaded dive (which will be the oldest dive).
I’ve gone back and forth between using serial and ble as transport methods, but neither has worked.
Which variant of the Perdix do you have? The first generation Perdix, or the newer Perdix AI or Perdix 2? The newer variants support only BLE, while the older variants are dual stack and support both bluetooth classic and BLE. The dctool command-line clients can only use libdivecomputer's built-in transports. If you build libdivecomputer, at the end of the configure step, a summary of the built-in transports will be printed. Unfortunately, on Mac there is no built-in support for bluetooth classic or BLE, so the output will always be something like this: Transports: Serial : yes USB : yes USBHID : yes IrDA : no Bluetooth : no BLE : no At the moment, there is simply no built-in BLE implementation available on any platform. I'm working on an implementation for Windows and Linux. It's already functional, but the code isn't finished yet. The main reason why there is no Mac support, not even in my experimental code, is because I lack the knowledge. I'm not a Mac developer.
However, I can successfully connect to the Perdix via both MacDive and Subsurface.
The reason why these applications can support bluetooth communication is because they use a custom transport to implement the low-level bluetooth communication.
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:
...
I wasn't aware of this core-bluetooth-tool utility, but I doubt it will work for most dive computers because their BLE protocol is a bit more complex than simple serial over BLE. I'm afraid the Shearwater dive computers are on that list.
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
For BLE, the device name would be the MAC address, but as explained above it doesn't matter because there is no BLE implementation available. That's why the application failed with DC_STATUS_UNSUPPORTED (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 ...
This indicates the use of a custom transport for BLE (DC_TRANSPORT_BLE=32).
I’d really appreciate any pointers on how to get dctool working with the Perdix on macOS, especially using BLE.
This won't be possible without first writing a BLE implementation for Mac. See also this discussion: https://libdivecomputer.org/mailman3/hyperkitty/list/devel@libdivecomputer.o... Jef
Hi Jef, Thanks a lot for your very comprehensive follow-up. Since I was able to connect via Subsurface, I somewhat assumed that the BLE transport was fully implemented. I didn’t realize that Subsurface uses a custom one.
See also this discussion:
https://libdivecomputer.org/mailman3/hyperkitty/list/devel@libdivecomputer.o...
Thanks for the pointer — I definitely hadn’t seen that thread. For what it’s worth, I was searching the list from the link under “Contact” (https://libdivecomputer.org/pipermail/devel/), and I didn’t see any conversations after October 2024 — which is why I missed this one. Best, -- Simone On Mon, Apr 14, 2025, at 11:05 PM, Jef Driesen - jef(a)libdivecomputer.org wrote:
On 14/04/2025 19:30, libdivecomputer.vanity547@simplelogin.com wrote:
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
Those options are good.
Note that if you use the "-f raw" option, you should also use one of the template placeholders (for example %n) in the output file name. Otherwise all dives will get written to the same file, and you end up with only the last downloaded dive (which will be the oldest dive).
I’ve gone back and forth between using serial and ble as transport methods, but neither has worked.
Which variant of the Perdix do you have? The first generation Perdix, or the newer Perdix AI or Perdix 2? The newer variants support only BLE, while the older variants are dual stack and support both bluetooth classic and BLE.
The dctool command-line clients can only use libdivecomputer's built-in transports. If you build libdivecomputer, at the end of the configure step, a summary of the built-in transports will be printed. Unfortunately, on Mac there is no built-in support for bluetooth classic or BLE, so the output will always be something like this:
Transports:
Serial : yes USB : yes USBHID : yes IrDA : no Bluetooth : no BLE : no
At the moment, there is simply no built-in BLE implementation available on any platform. I'm working on an implementation for Windows and Linux. It's already functional, but the code isn't finished yet.
The main reason why there is no Mac support, not even in my experimental code, is because I lack the knowledge. I'm not a Mac developer.
However, I can successfully connect to the Perdix via both MacDive and Subsurface.
The reason why these applications can support bluetooth communication is because they use a custom transport to implement the low-level bluetooth communication.
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:
...
I wasn't aware of this core-bluetooth-tool utility, but I doubt it will work for most dive computers because their BLE protocol is a bit more complex than simple serial over BLE. I'm afraid the Shearwater dive computers are on that list.
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
For BLE, the device name would be the MAC address, but as explained above it doesn't matter because there is no BLE implementation available. That's why the application failed with DC_STATUS_UNSUPPORTED (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 ...
This indicates the use of a custom transport for BLE (DC_TRANSPORT_BLE=32).
I’d really appreciate any pointers on how to get dctool working with the Perdix on macOS, especially using BLE.
This won't be possible without first writing a BLE implementation for Mac.
See also this discussion:
https://libdivecomputer.org/mailman3/hyperkitty/list/devel@libdivecomputer.o...
Jef
On 16/04/2025 16:09, libdivecomputer.vanity547@simplelogin.com wrote:
See also this discussion:
https://libdivecomputer.org/mailman3/hyperkitty/list/devel@libdivecomputer.o...
Thanks for the pointer — I definitely hadn’t seen that thread. For what it’s worth, I was searching the list from the link under “Contact” (https://libdivecomputer.org/pipermail/devel/), and I didn’t see any conversations after October 2024 — which is why I missed this one.
That's because I migrated the mailinglists to mailman version 3 and forgot to update the links. It's fixed now! https://libdivecomputer.org/mailman3/ The old mailman 2 web interface is still online for the archives. The archives have also been imported in the new version, but existing links still point to the old instance. So I kept it for now. Jef
participants (2)
-
Jef Driesen -
libdivecomputer.vanity547＠simplelogin.com