This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Custom BLE packets on mesh network

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
Parents Reply Children
  • 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.

  • 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

  • Any  updates on my latest issue? I'm stuck

  • 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

Related