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