1. #bluetooth
  2. Bluetooth mesh and Central role simultaneously

Bluetooth mesh and Central role simultaneously #bluetoothmesh #bluetooth

Andreas
 

Hello, on my nRF52 board I am planning to have a Bluetooth mesh node running and then eventually (e.g. on button press) create a connection to a smartphone (nRF52 in Central, smartphone in Peripheral GAP role) simultaneously.

 

The intended sequence is like this

  1. Start scanning and connect to the smartphone’s BLE advertisement
  2. Read data from smartphone
  3. Send data to neighbor mesh node for processing
  4. Receive result from neighbor mesh node
  5. Send result to smartphone
  6. Terminate connection to smartphone.

 

I tried a lot and always run into some problem, e.g.

  • If I start the mesh with bt_mesh_init() and afterwards call bt_le_scan_start() then I get the -EALREADY error.
  • If instead I add me to the list of scan callbacks using bt_le_scan_cb_register() then I even see a crash (not further investigated why this happens).
  • If I first start scanning and then start the mesh, then I get a -EIO error when I call bt_conn_le_create().

 

So my question: is the scenario to run Bluetooth mesh and Central GAP role simultaneously supported by Bluetooth Low Energy standard?

If so, is such scenario also supported by the Zephyr Bluetooth stack?

 

Thanks for your time!

Andreas

 

(I am testing with Zephyr OS version 2.3.0)
Johan Hedberg
 

Hi Andreas,

On 11. Jun 2020, at 11.37, Andreas <andreas.schmidt@...> wrote:
So my question: is the scenario to run Bluetooth mesh and Central GAP role simultaneously supported by Bluetooth Low Energy standard?
If so, is such scenario also supported by the Zephyr Bluetooth stack?

There’s nothing in the standard that prohibits it, but it will reduce the efficiency of the mesh network. The mesh advertising bearer is designed in such a way that assumes the nodes to be scanning as close as possible to 100% duty cycle (LPN nodes are an exception). Any connections that you do will reduce the time the controller can spend scanning, and hence reduce the duty cycle.

Currently the Zephyr mesh stack is designed so that it assumes ownership of the advertising and scanning operations, which is why you’ll easily get conflicts and errors if you try to do those yourself. We do have plans to improve this co-existence with the help of multiple advertising instances, but we don’t yet have support for this in the native Zephyr controller (AFAIK). That still wouldn’t help with the central role though, and for that we have plans to introduce HCI-extensions so that the controller would be aware of Mesh-specific scanning and legacy scanning. However, I don’t think there’s any timeline or commitment to getting it done.

To implement what you need with the current stack, and without compromising the efficiency of the mesh network, I’d suggest to consider a HW setup where you have two controllers: one dedicated for mesh and another for the central role.

Johan
Andreas
 

Hi Johan,

 

thank you very much for your help in that matter.

I am aware of the reduced scanning time for the mesh. It’s just that in my scenario the mesh is running all day long, and occasionally some BLE smartphone touches the device and then I need that fast ad-hoc connection.

 

With saying “LPN nodes are an exception”: do you think that the targeted coexistence with BLE Central role could be possible with a LowPower node? 

 

I understand that we will not have a solution for my scenario short-term, so I might really have to think about using two controllers to get started.

Overall I am quite impressed about the status of the BLE implementations in Zephyr and am looking forward to the next steps.

 

Best wishes,

Andreas

 
Johan Hedberg
 

Hi Andreas,

On 1. Jul 2020, at 15.47, andreas.schmidt@... wrote:
I am aware of the reduced scanning time for the mesh. It’s just that in my scenario the mesh is running all day long, and occasionally some BLE smartphone touches the device and then I need that fast ad-hoc connection.
 
With saying “LPN nodes are an exception”: do you think that the targeted coexistence with BLE Central role could be possible with a LowPower node? 

No, I don’t think that combination would make sense. One option I forgot to mention is the bt_mesh_suspend() & bt_mesh_resume() APIs. You could try suspending mesh operations (advertising & scanning) for the duration of performing what you need in central role, and then calling bt_mesh_resume() again. The effect will basically be the same as taking the mesh node out of range from the mesh network for that duration.

Johan
1 - 4 of 4