On Thu, May 6, 2021 at 8:43 AM Ryan Gardner ryebrye@gmail.com wrote:
I ran into a few issues that are entirely my fault and not the fault of subsurface - namely I couldn't figure out a way to get my IDE to launch the built subsurface app and attach to it and hit breakpoints inside of libdivecomputer (again - totally my "not normally a c/c++ application developer" problem) - but after spinning my wheels for a while I figured I'd try to see if the dctool from libdivecomputer could be a faster path to "can I get code to communicate with this thing?"
Yeah, I have worked almost entirely from just BLE packet dumps, and just the debug output (both the subsurface debug output and the libdivecomputer logs).
One thing to look out for is to make sure that it all works with some other dive computer if you have one available - just to check that everything works.
The fact that you pair is already a good sign, but usually the pain point is the initial connection, and sometimes it's the GATT descriptors that aren't set up the way most other serial emulation things are.
It's all non-standard. As you may have noticed if you've been looking at the subsurface core/qt-ble.cpp file. We have a number of "we know this dive computer uses this BLE GATT service UUID for rx/tx", with default fallbacks for the common situation.
Worst case, some dive computers want to do flow control. So far we've only seen one that does that (the magic "terminal IO" stuff for the OSTC), but if that's the case things can get quite nasty.
You do seem to have the proper packet logs, so you're probably aware of all this already.
Linus