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/Li...
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
On 6/03/2025 06:55, Angus wrote:
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
That's correct. The bluetooth classic implementation is only available for Linux and Windows.
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/Li...
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).
In theory it should be possible to use the Obj-C wrappers. For example libusb seems to use this approach:
https://github.com/libusb/libusb/blob/master/libusb/os/darwin_usb.h https://github.com/libusb/libusb/blob/master/libusb/os/darwin_usb.c
But I never tried it.
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?
At the moment there is indeed no built-in BLE implementation available in libdivecomputer. That means every application needs to provide its own custom I/O. The ble.h header defines a few ioctl's (and a couple of helper functions for converting UUID's), but the actual code needs to be implemented in the custom I/O.
I have been working on a built-in BLE implementation. It's already functional in the sense that it can be used to download dives successfully from most BLE dive computers, but the code isn't production ready quality yet. The goal is to integrate this into libdivecomputer, just like the bluetooth classic one.
I have some pre-build binaries available on the libdivecomputer website which have this prototype BLE code included:
https://libdivecomputer.org/builds/experimental/linux/dctool-ble https://libdivecomputer.org/builds/experimental/windows/dctool-ble.exe
This prototype code is again Linux and Windows only. The reason is the same as for the bluetooth classic implementation. Unlike the other transports, there is no common api (e.g. win32/termios for serial) or cross-platform library (e.g. libusb and hidapi for USB) for doing bluetooth communication. Each platform has its own very platform specific API. That makes it difficult to add support, especially for someone with no experience with the platform or its api.
Jef
-
Angus -
Jef Driesen