Hi linux-bluetooth developers,
I hope my question is not unsuitable for this mailing list.
I have read in the archives of this mailing list that the Bluetooth mesh daemon needs exclusive access to a Bluetooth controller.
If I understand that correctly (just to be clear), it means that when I only have one controller, I have to choose between either using mesh operations or "normal" Bluetooth operations (normal here meaning all operations that the regular Bluetooth daemon already performs).
In my company we are now developing a Bluetooth mesh lighting solution by using the Bluetooth-mesh daemon in an embedded Linux environment (with only one Bluetooth controller attached via HCI). We have a custom mesh application that is using the mesh DBUS api to perform mesh operations. I am currently looking in to how we can additionally allow this application to perform other Bluetooth operations (i.e. acting as an observer, and in the future also as a central device).
When you have time, I would be interested to hear your general thoughts about this topic. Whether or not you believe it is doable or if it perhaps already is a part of a long-term plan.
I am also in general open to help contributing to the project.
Thank you for your time,
Isak
Hi Isak,
Your question is fine for the list. I am part of my companies BlueZ support team, spoecifically supporting
Mesh.
On Wed, 2021-05-26 at 15:30 +0000, Isak Westin wrote:
> Hi linux-bluetooth developers,
>
> I hope my question is not unsuitable for this mailing list.
>
> I have read in the archives of this mailing list that the Bluetooth mesh daemon needs exclusive access to a
> Bluetooth controller.
> If I understand that correctly (just to be clear), it means that when I only have one controller, I have to
> choose between either using mesh operations or "normal" Bluetooth operations (normal here meaning all
> operations that the regular Bluetooth daemon already performs).
That is correct.
> In my company we are now developing a Bluetooth mesh lighting solution by using the Bluetooth-mesh daemon in
> an embedded Linux environment (with only one Bluetooth controller attached via HCI). We have a custom mesh
> application that is using the mesh DBUS api to perform mesh operations. I am currently looking in to how we
> can additionally allow this application to perform other Bluetooth operations (i.e. acting as an observer,
> and in the future also as a central device).
>
> When you have time, I would be interested to hear your general thoughts about this topic. Whether or not you
> believe it is doable or if it perhaps already is a part of a long-term plan.
> I am also in general open to help contributing to the project.
Our roadmap for mesh support includes changes to the linux bluetooth kernel module, that will allow Sending and
Receiving mesh advertising packets over the MGMT interface. When complete, it will be possible for both the
classic Bluetooth daemon (bluetoothd) and the Mesh daemon (bluetooth-meshd) to share a single controller.
We expect this to work OK much of the time... basically when not much is happening with ACL or SCO links. And
even *with* ACL and SCO links, we expect very light outbound traffic to work OK. When there are no ACL/SCO
connections active, things will work pretty much as normal. However, any high-traffic data link oriented usage
will have a very negative affect on a single controllers ability to be an active mesh member, which means that
even *after* the shared-controller system is ready for inclusion in the kernel and bluetooth-meshd daemon, it
will still be recommended that a seperate controller be used in most cases.
> Thank you for your time,
> Isak
>
Best Regards,
Brian
Hi Brian,
Thanks for the response!
> Hi Isak,
>
> Your question is fine for the list. I am part of my companies BlueZ support team, spoecifically supporting Mesh.
>
> On Wed, 2021-05-26 at 15:30 +0000, Isak Westin wrote:
> > Hi linux-bluetooth developers,
> >
> > I hope my question is not unsuitable for this mailing list.
> >
> > I have read in the archives of this mailing list that the Bluetooth
> > mesh daemon needs exclusive access to a Bluetooth controller.
> > If I understand that correctly (just to be clear), it means that when
> > I only have one controller, I have to choose between either using mesh
> > operations or "normal" Bluetooth operations (normal here meaning all operations that the regular Bluetooth daemon already performs).
>
> That is correct.
>
> > In my company we are now developing a Bluetooth mesh lighting solution
> > by using the Bluetooth-mesh daemon in an embedded Linux environment
> > (with only one Bluetooth controller attached via HCI). We have a
> > custom mesh application that is using the mesh DBUS api to perform
> > mesh operations. I am currently looking in to how we can additionally allow this application to perform other Bluetooth operations (i.e. acting as an observer, and in the future also as a central device).
> >
> > When you have time, I would be interested to hear your general
> > thoughts about this topic. Whether or not you believe it is doable or if it perhaps already is a part of a long-term plan.
> > I am also in general open to help contributing to the project.
>
> Our roadmap for mesh support includes changes to the linux bluetooth kernel module, that will allow Sending and Receiving mesh advertising packets over the MGMT interface.
> When complete, it will be possible for both the classic Bluetooth daemon (bluetoothd) and the Mesh daemon (bluetooth-meshd) to share a single controller.
>
Difficult question, I know, but if you were to guess a time frame until this would be fully implemented, what would your guess be?
And let's say that my company decide that sharing controller is the only option for our product, then we would also be open to help contributing to the linux Bluetooth project in order to reach an implementation earlier.
Would that be an option and is it encouraged? And if yes, how does that usually work in practice?
>
> We expect this to work OK much of the time... basically when not much is happening with ACL or SCO links.
> And even *with* ACL and SCO links, we expect very light outbound traffic to work OK.
> When there are no ACL/SCO connections active, things will work pretty much as normal.
> However, any high-traffic data link oriented usage will have a very negative affect on a single controllers ability to be an active mesh member,
> which means that even *after* the shared-controller system is ready for inclusion in the kernel and
> bluetooth-meshd daemon, it will still be recommended that a seperate controller be used in most cases.
>
>
> > Thank you for your time,
> > Isak
> >
>
> Best Regards,
> Brian
>
Best regards,
Isak