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.
Thanks for the pointer — I definitely hadn’t seen that thread.
On Mon, Apr 14, 2025, at 11:05 PM, Jef Driesen - jef(a)libdivecomputer.org 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:
Jef