mesh nodes: concurrent advertising and scanning

[DavideDN]

We are developing a project where we have a BLE Mesh netrwork where each node is implementing generic ON OFF client and server, a specific vendor model (derived from the Nordic's Chat example), and DFU target.

After some hard work, everything is working as expected using the latest nRFConnect SDK (2.5.0).

Next phase in our project is to be able to do "observing"  and "beaconing" while not disturbing the mesh stack.

We know that we have to be careful and not to use these functions heavily to avoid disturbing the mesh stack itself, anyway we lack any code example to start with.

I discovered by browsing around and with some trial and error that after node initialization, I can register a callback for every adv packet received using:

bt_le_scan_cb_register(&scan_callbacks);

This way implementing the scan_callbacks we are "observing", and it apparently works! BUT: is this the correct approach inside a Mesh node project?

Then, to try something regarding the beaconing function I tried:

	err = bt_le_adv_start(BT_LE_ADV_NCONN_IDENTITY, ad, ARRAY_SIZE(ad),
			      sd, ARRAY_SIZE(sd));
	if (err) {
		printk("Advertising failed to start (err %d)\n", err);
		return;
	}

But it does not work returning "Advertising failed to start (err -12)"

Please do note that we know the mesh node is already advertising with a "normal" ble peripheral message (before being provisioned) and also is advertisig using "mesh Beacon", but what we need is the ability to add a different beacon packet, it will have a specific payload related to our application.

Can you provide a complete reference example of a BLE Mesh node that give the developer to run a custom becaon and a custom observer?

I found some mention to such an application inside the obsolete nRF5.0.0 Mesh documentation here but it is of no help.

[Hung Bui]

Hi David, 

We don't have a sample doing observer and beacon at the same time with mesh.

But we do have example doing advertising and peripheral with mesh. Please take a look at the nrf/samples/bluetooth/mesh/ble_peripheral_lbs_coex. After you flash the sample you can find it will advertise with 2 advertising sets one as an unprovisioned mesh and one with LBS UUID. 

The reason that the observer is usually not showed concurrently with mesh is that there will be conflict. For a mesh node to be able to operate it need to scan for BLE ADV packets. If you do scanning at the same time at mesh you will reduce the time the mesh stack can scan for mesh packet. So there will be some compromise here. But from my point of view it should be fine in the code to do so, just need to reduce the duty cycle of scanning to minimum as possible (then you have less chance to catch your message when you do scanning)

Another better option is to piggybacking your scanning with the mesh scanning. I don't think it's support in the mesh stack. You will have no callback in your application when the mesh stack scan and find a packet. This ticket is related to it: https://lists.zephyrproject.org/g/devel/topic/bt_le_scan_of_node_in_mesh/27269871

What the ticket suggested was to implement your code inside bt_mesh_scan_cb() in \zephyr\subsys\bluetooth\mesh\adv to add your own callback in. 

[DavideDN]

Hi Hung,

Thank you for the answer.

I believe there is no need to have or risk scan conflicts: the BLE mesh stack *HAS* to rely on a continuous scanning activity to work, our need is to simply have a copy of each scan event also inside our application code. We do not need any new scanner instance to be activated.

Following this idea I discovered and tried bt_le_scan_cb_register(&scan_callbacks); as said in my first message.

Can you comment on it? is this a "correct" approach to listen to other applications advertising messages?

br

 Davide

[Hung Bui]

Hi Davide, 

Sorry that I misread what you wrote. I will check with the team to see if what you do is correct or if they have another opinion. 

[Hung Bui]

Hi again, 

You are right, bt_le_scan_cb_register() is the way to go. What I suggested earlier was outdated. 

You can find the practice of doing this in how we scan for Enocean beacons in the nrf/samples/bluetooth/mesh/silviar_enocean sample. 

We declare bt_le_scan_cb_register() inside bt_enocean_init() in \nrf\subsys\bluetooth\enocean.c  to process the Enocean advertising packet when mesh scanning.

enocean.c is used by \nrf\subsys\bluetooth\mesh\vnd\silvair_enocean_srv.c server.

[DavideDN]

OK, thank you for the "scanning" approach confirmation.

Later I am checking the advertising part copying the relevant snippets from the "ble_peripheral_lbs_coex" as you suggested.

[DavideDN]

OK, I tested it. It failed at the first try, but after adding some line into proj.conf it worked!

CONFIG_BT_EXT_ADV=y
# 5 sets are used by Bluetooth mesh, 1 is needed for the sample advs.
CONFIG_BT_EXT_ADV_MAX_ADV_SET=6
CONFIG_BT_MAX_CONN=2
CONFIG_BT_ID_MAX=2

At the end it looks reasonable and correct, but sometime it is a little hard to understand all the pieces that are needed to bi stitched together!

Good, Thank for the right hints!

you may close this ticket now.

[Hung Bui]

Excellent. Glad to know that it works now.