Custom BLE packets on mesh network

[AndyM]

Hello

I have a mesh node that needs to broadcast a custom BLE packet

To start advertising I call bt_le_adv_start and it works as expected.

I'm curious about the error that I see in the RTT log

00> [00:08:41.658,050] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 9
00> [00:08:41.658,172] <err> bt_mesh_adv_legacy: Advertising failed: err -120

My understanding is that his is because my app started advertising and the mesh network cannot relay the packet

I tried to call 

bt_mesh_relay_set(BT_MESH_FEATURE_DISABLED,BT_MESH_TRANSMIT(0,1));

before calling bt_le_adv_start  but I get same error -120.

What's the proper way to disable mesh relay?

Is there a way for custom advertising and mesh relay to coexist in a provisioned mesh node?

Thank you

[Mttrinh]

Hi,

Could you provide me with what SDK version you are using?

The error is probably due to you running BLE and Mesh at the same time.

custom BLE packet

Can you elaborate what you mean by custom?

We do have an example in the nRF Connect SDK that shows how you can run BLE and Mesh concurrently. I suggest you have a look at this example and use that as a reference.

[AndyM]

custom = packet type is BT_DATA_MANUFACTURER_DATA (0xFF)

SDK is 1.9.1

I'll take a look at the sample - looks like it does what I need

Thank you

[AndyM]

Just enabling  CONFIG_BT_EXT_ADV causes the program to crash

Any suggestions?

Thanks

00> [00:00:00.286,407] <err> os: ***** BUS FAULT *****
00> [00:00:00.286,407] <err> os: Precise data bus error
00> [00:00:00.286,437] <err> os: BFAR Address: 0xbb672b5[0m
00> [00:00:00.286,437] <err> os: r0/a1: 0x00000020 r1/a2: 0x0bb672b5 r2/a3: 0x0bb672b5
00> [00:00:00.286,468] <err> os: r3/a4: 0x00000020 r12/ip: 0x00000007 r14/lr: 0x00057609
00> [00:00:00.286,468] <err> os: xpsr: 0x81000200
00> [00:00:00.286,499] <err> os: Faulting instruction address (r15/pc): 0x00057562
00> [00:00:00.286,529] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0

[Mttrinh]

Hi,

The sample can be found in nrf/samples/bluetooth/mesh/ble_peripheral_lbs_coex in the nRF Connect SDK folder structure.

[AndyM]

From what I can tell the sample  enables extended advertising and configures 2 advertising sets

But I don't see it doing anything else different from normal mesh initialization or ble advertising initialization 

I enabled extended advertising i.e 

CONFIG_BT_EXT_ADV=y

CONFIG_BT_EXT_ADV_MAX_ADV_SET=2

On a provisioned device I now I get this

[00:05:06.649,291] <wrn> bt_hci_core: opcode 0x2036 status 0x01
00> [00:05:06.649,322] <err> bt_mesh_adv_legacy: Advertising failed: err -5

At this point I have not called ble_adv_start to start advertising my custom packet - this is mesh only

Any ideas?

Thanks

[AndyM]

Any updates? Thanks

[Mttrinh]

Hi,

I will need some time to take a look. Will give you an update by tomorrow.

[AndyM]

Thank you!

Look forward

[Mttrinh]

Hi,

It seems like the Legacy advertiser somehow is configured in. In the mesh Kconfig the used advertising bearer is defined as a choice:

Meaning that it should not be possible to have both active at the same time.

To verify that the extended adv is active you might search the build folder of the project for CONFIG_BT_MESH_ADV_EXT=y. If it is not there is something wrong in the prj.conf most likely.

The build config can be found in [Project path]/build/zephyr/.config.

[AndyM]

My proj.conf file only had CONFIG_BT_EXT_ADV set but not CONFIG_BT_MESH_ADV_EXT

When I set CONFIG_BT_MESH_ADV_EXT=y I got a warning that CONFIG_BT_MESH_ADV_STACK_SIZE=2048 could not be set because it requires BT_MESH_ADV_LEGACY.

Not increasing CONFIG_BT_MESH_ADV_STACK_SIZE causes my program to crash after the device is provisioned.

Any ideas how to resolve this?

Than you

[AndyM]

Any  updates on my latest issue? I'm stuck

[AndyM]

OK, figured it out 
Turns out the TX thread stack size was too small for multiple advertising sets.
Found a very cool trick that helped pinpoint the problem:
CONFIG_RESET_ON_FATAL_ERROR=n
By default the OS resets on fault so it's hard to figure out where the crash occurred. With reset  disabled I saw the thread name in the log which happened to be "BT TX"
So I looked at its stack size and found a setting to increase it
CONFIG_BT_HCI_TX_STACK_SIZE=2048 did the trick