Hi,
I'm new to Bluetooth programming, and I have some basic questions
about the best approach to implement a fairly simple scenario.
I have a small embedded device running Linux, and which supports
Bluetooth 4.0. I'm also developing a mobile app that needs to
exchange some data with the embedded device. The data consists
of only a few JSON-encoded objects and is small in volume. The
communication must happen bidirectionally, though.
Those are pretty much the requirements. Now the questions:
a) On the embedded side, do I need to program a small daemon using
the DBUS-based Bluez API, or can I set up a special device and
read/write to it as if it were a character device?
b) The old interface [1] has been deprecated, right? (It's my
understanding that only the new DBUS-based API should be used.)
c) Is Bluetooth Classic or Bluetooth Low Energy better for this
scenario? (I've read that BLE can dispense with pairing.)
Thanks in advance for your time!
Best regards,
Dario Teixeira
[1] https://people.csail.mit.edu/albert/bluez-intro/
Hello Dario,
On 20 December 2016 at 12:38, Dario Teixeira <[email protected]> wrote:
> Hi,
>
> Thanks a lot for your prompt reply -- it was very helpful!
Good to hear. Thanks!
>
>> Using BlueZ as a peripheral is still behind the --experimental flag so
>> you will need to read up on that.
>
>
> I'm unsure whether I'll need to compile the latest version of Bluez
> or if the version packaged for my distro has all the functionality
> I need. This brings two related questions:
>
> a) How do I query the bluetooth daemon to find out if the required
> functionality is available, and what should I look for?
> (I reckon I'll need to build a GATT server at least)
I am not sure I have a scientific answer for you on this. Maybe one of
the developers can offer better guidance on this if you share the
version in your distro.
My gut feeling on this is that if you read the release notes at
http://www.bluez.org/ then you will see that the GATT D-Bus API gets
mentioned as being updated in recent releases. Unless you have a very
recent version in your distro, I'd upgrade.
>
> b) If the functionality is compiled into the binary, but requires
> the --experimental flag for activation, what's the standard way
> to enable it? I can always modify the bluetooth.service file
> so that bluetoothd starts with the option, but I reckon there
> should be a standard config option, no? (I couldn't find any
> mention of "experimental" in the /etc/bluetooth files)
It is in bluetooth.service that I would normally enable this.
The binary will need to have been built with experimental enabled.
I would think it unlikely that your distro has done that so again
would suggest you need to build from source.
>
> Thanks again for your time!
> Best regards,
> Dario Teixeira
>
Hi,
Thanks a lot for your prompt reply -- it was very helpful!
> Using BlueZ as a peripheral is still behind the --experimental flag so
> you will need to read up on that.
I'm unsure whether I'll need to compile the latest version of Bluez
or if the version packaged for my distro has all the functionality
I need. This brings two related questions:
a) How do I query the bluetooth daemon to find out if the required
functionality is available, and what should I look for?
(I reckon I'll need to build a GATT server at least)
b) If the functionality is compiled into the binary, but requires
the --experimental flag for activation, what's the standard way
to enable it? I can always modify the bluetooth.service file
so that bluetoothd starts with the option, but I reckon there
should be a standard config option, no? (I couldn't find any
mention of "experimental" in the /etc/bluetooth files)
Thanks again for your time!
Best regards,
Dario Teixeira
Hello Dario,
On 19 December 2016 at 17:41, Dario Teixeira <[email protected]> wrote:
> Hi,
>
> I'm new to Bluetooth programming, and I have some basic questions
> about the best approach to implement a fairly simple scenario.
> I have a small embedded device running Linux, and which supports
> Bluetooth 4.0. I'm also developing a mobile app that needs to
> exchange some data with the embedded device. The data consists
> of only a few JSON-encoded objects and is small in volume. The
> communication must happen bidirectionally, though.
>
> Those are pretty much the requirements. Now the questions:
>
> a) On the embedded side, do I need to program a small daemon using
> the DBUS-based Bluez API, or can I set up a special device and
> read/write to it as if it were a character device?
>
> b) The old interface [1] has been deprecated, right? (It's my
> understanding that only the new DBUS-based API should be used.)
>
> c) Is Bluetooth Classic or Bluetooth Low Energy better for this
> scenario? (I've read that BLE can dispense with pairing.)
>
> Thanks in advance for your time!
> Best regards,
> Dario Teixeira
>
> [1] https://people.csail.mit.edu/albert/bluez-intro/
>
I'll take a go at trying to answer this...
To answer your last question first, if you are only exchanging small
amounts of data then I would suggest going with BLE rather than
Classic. There are a couple of resources online that might be helpful
to give you some background.
1) Martin from Bluetooth SIG giving an overview:
https://youtu.be/auApsoMHxtA (There is an issue with the audio for the
first couple of minutes but stick with it)
2) Adafruit introduction to installing BlueZ
https://learn.adafruit.com/install-bluez-on-the-raspberry-pi/overview
Using BlueZ as a peripheral is still behind the --experimental flag so
you will need to read up on that.
There are some BLE examples using DBus API in the BlueZ repository at:
http://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-gatt-server
http://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-advertisement
If you are more familiar with Javascript/Node then you might want to
take a look at:
https://github.com/sandeepmistry/bleno
Good luck!
Regards,
Barry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html