Is there a way to build with bluetooth support on a mac?

Ryan Gardner ryebrye at gmail.com
Thu May 6 16:43:13 CEST 2021


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)

The device I'm working on uses BLE - it looks like the configure.ac always
marks the bluetooth_le transport as being unsupported.

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?

On Thu, May 6, 2021 at 4:32 AM Jef Driesen <jef at libdivecomputer.org> wrote:

> On 6/05/2021 00:36, Ryan Gardner wrote:
> > I'm hoping to add a new bluetooth dive computer to libdivecomputer. I've
> spent a
> > fair amount of time reverse engineering the sync protocol between it and
> the
> > android app that it uses, and have a general idea of how it communicates.
> >
> > I'm primarily on a mac - looking at the source for it, when I do my
> normal
> > configure operation it claims:
> >
> > Transports:
> >
> > Serial: yes
> > USB : yes
> > USBHID: yes
> > IrDA: no
> > Bluetooth : no
> > BLE : no
> >
> > It looks like it uses bluez or windows bluetooth apis - is there
> something I
> > need to do to get it to work with bluetooth on OS X? I can work on an
> older
> > linux machine as well - but it will take a bit longer to get it set up
> to do
> > development on.
>
> That's correct. Unfortunately libdivecomputer does not have a built-in
> bluetooth
> transport on Mac. That's mainly because I'm not a Mac developer. I simply
> do not
> have any experience with the Mac apis to write such a transport. For other
> transports this wasn't a problem because the api is standard unix (serial)
> or
> there are cross-platform libraries available (usb and usbhid).
>
> Applications can always use a custom I/O implementation to work around
> this
> limitation. That means implementing the low-level communication in the
> application (using the native api for your platform), and wrap it inside a
> libdivecomputer transport using dc_custom_open.
>
> Does Mac supports serial port emulation? Because in that case you could
> also use
> the serial transport, and let the OS take care of the bluetooth part.
>
> Jef
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20210506/dd3c1182/attachment.htm>


More information about the devel mailing list