<div dir="ltr">Thanks for the info.  I'm not an expert mac developer either - so I switched to using a linux box for what I'm trying to do. (A raspberry pi with built in bluetooth is acting in that role now)<div><br><div><div>The device I'm working on uses BLE - it looks like the <a href="http://configure.ac" target="_blank">configure.ac</a> always marks the bluetooth_le transport as being unsupported. </div><div><br></div><div>What do you think is the easiest way to test / debug adding a new BLE device? I was hoping to use the simple dctool as a way to test things as I implemented it - but maybe there's a better approach? Do I need to build my own simple test app that sets up the ble connection and then hands things over to libdivecomputer? </div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 6, 2021 at 4:32 AM Jef Driesen <<a href="mailto:jef@libdivecomputer.org" target="_blank">jef@libdivecomputer.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/05/2021 00:36, Ryan Gardner wrote:<br>
> I'm hoping to add a new bluetooth dive computer to libdivecomputer. I've spent a <br>
> fair amount of time reverse engineering the sync protocol between it and the <br>
> android app that it uses, and have a general idea of how it communicates.<br>
> <br>
> I'm primarily on a mac - looking at the source for it, when I do my normal <br>
> configure operation it claims:<br>
> <br>
> Transports:<br>
> <br>
> Serial: yes<br>
> USB : yes<br>
> USBHID: yes<br>
> IrDA: no<br>
> Bluetooth : no<br>
> BLE : no<br>
> <br>
> It looks like it uses bluez or windows bluetooth apis - is there something I <br>
> need to do to get it to work with bluetooth on OS X? I can work on an older <br>
> linux machine as well - but it will take a bit longer to get it set up to do <br>
> development on.<br>
<br>
That's correct. Unfortunately libdivecomputer does not have a built-in bluetooth <br>
transport on Mac. That's mainly because I'm not a Mac developer. I simply do not <br>
have any experience with the Mac apis to write such a transport. For other <br>
transports this wasn't a problem because the api is standard unix (serial) or <br>
there are cross-platform libraries available (usb and usbhid).<br>
<br>
Applications can always use a custom I/O implementation to work around this <br>
limitation. That means implementing the low-level communication in the <br>
application (using the native api for your platform), and wrap it inside a <br>
libdivecomputer transport using dc_custom_open.<br>
<br>
Does Mac supports serial port emulation? Because in that case you could also use <br>
the serial transport, and let the OS take care of the bluetooth part.<br>
<br>
Jef<br>
</blockquote></div>