Unable to configure nodes using mesh provisioner example over CODED PHY

[Susheel]

Hello,

I am able to successfully provision and configure all the nodes in the network using the provisioner example(provisioner node is another nrf52840) over the standard 1M PHY. However, when I switch the PHY to CODED, I am unable to configure the nodes over configuration client messages. Also, the provisioning process take a lot longer when compared to the provisioning done over standard 1M PHY. 

Since the coded PHY works at 128Kbps instead of 1Mbps, I am suspecting there to be some configuration parameters that need to be changed with regards to the data length/number of segments etc. Please advice.

Observation. I have tried provisioning the nodes over 1M and later reflashed the nodes to use coded PHY and they work just fine. I think this is because the data messages being sent after the node is provisioned and configured are small in length. 

In my use case, there are several sensor server and client pairs and one control node which doubles as the provisioner. The configuration parameters of the provisioner are as follows

CONFIG_INIT_STACKS=y
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_BT_RX_STACK_SIZE=4096
CONFIG_BT_MESH_ADV_STACK_SIZE=1024
CONFIG_BT_BUF_EVT_RX_SIZE=128
# The Bluetooth API should not be used from a preemptive thread:
CONFIG_MAIN_THREAD_PRIORITY=-2

CONFIG_BT=y
CONFIG_BT_TINYCRYPT_ECC=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_OBSERVER=y
CONFIG_BT_BROADCASTER=y

CONFIG_BT=y
CONFIG_BT_HCI=y
CONFIG_BT_CENTRAL=n
CONFIG_BT_PERIPHERAL=y
#CONFIG_BT_CONN=y
CONFIG_BT_USER_PHY_UPDATE=y
# CONFIG_BT_PHY_UPDATE=y
CONFIG_BT_EXT_ADV=y
CONFIG_BT_HCI_MESH_EXT=y
CONFIG_BT_CTLR_ADV_EXT=y
CONFIG_BT_LL_SOFTDEVICE=y
CONFIG_BT_CTLR_PHY_CODED=y

CONFIG_BT_MESH=y
CONFIG_BT_MESH_SUBNET_COUNT=1
CONFIG_BT_MESH_APP_KEY_COUNT=1
CONFIG_BT_MESH_ADV_BUF_COUNT=64
CONFIG_BT_MESH_TX_SEG_MAX=32
CONFIG_BT_MESH_TX_SEG_MSG_COUNT=10
CONFIG_BT_MESH_RX_SEG_MAX=32
CONFIG_BT_MESH_MODEL_GROUP_COUNT=2
CONFIG_BT_MESH_LABEL_COUNT=0
CONFIG_BT_MESH_CFG_CLI=y
CONFIG_BT_MESH_HEALTH_CLI=y
CONFIG_BT_MESH_BEACON_ENABLED=n
CONFIG_BT_MESH_RELAY=y
CONFIG_BT_MESH_RELAY_RETRANSMIT_COUNT=3

CONFIG_BT_MESH_PROVISIONER=y
CONFIG_BT_MESH_PROV_DEVICE=n
CONFIG_BT_MESH_CDB=y
CONFIG_BT_MESH_CDB_NODE_COUNT=16
CONFIG_BT_MESH_CDB_SUBNET_COUNT=3
CONFIG_BT_MESH_CDB_APP_KEY_COUNT=3

CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y
CONFIG_BT_MESH_RPL_STORE_TIMEOUT=600
CONFIG_BT_MESH_CRPL=100

CONFIG_BT_MESH_DEBUG=y
CONFIG_BT_MESH_DEBUG_SETTINGS=n
CONFIG_BT_MESH_DEBUG_NET=n
CONFIG_BT_MESH_DEBUG_MODEL=n
CONFIG_BT_MESH_DEBUG_TRANS=n
CONFIG_BT_MESH_DEBUG_ACCESS=n
CONFIG_BT_MESH_DEBUG_BEACON=n
CONFIG_BT_MESH_DEBUG_ADV=n
CONFIG_BT_MESH_DEBUG_PROV=n
CONFIG_BT_MESH_DEBUG_PROVISIONER=n
CONFIG_BT_MESH_DEBUG_PROV_DEVICE=n
#CONFIG_BT_MESH_DEBUG_LOW_POWER=y
#CONFIG_BT_MESH_DEBUG_CRYPTO=y

#CONFIG_BT_MESH_LOW_POWER=y

CONFIG_PARTITION_MANAGER_ENABLED=n
CONFIG_PM_SINGLE_IMAGE=n
CONFIG_PM_PARTITION_SIZE_SETTINGS_STORAGE=0x2000
CONFIG_FLASH_MAP_CUSTOM=n
CONFIG_BT_MESH_PROXY_USE_DEVICE_NAME=n

#CONFIG_BT_PHY_UPDATE=y

I do know where to start looking in order to investigate. Please advice. I am using ncs 1.9.1.

[tesc]

Hi,

Bluetooth mesh is built on top of Bluetooth 4.2, which means it does not support coded phy. While it may be technically possible to run the Bluetooth mesh stack on top of coded phy, it will not be qualifiable.

Since the coded phy works at 128Kbps, all packets take eight times as long to send, which increases the probability of packet collisions as well as packet loss due to spikes and bursts of RF noise. There is a tradeoff there, between improving the link budget (providing range) on the one hand, and on the other hand needing a longer contiguous period of time without disturbance. Because of this, you may experience in some situations that coded phy provides worse reliability than 1Mbps, or even 2Mbps.

A better alternative, for Bluetooth mesh, may be to increase TX power, if that is allowed in the given jurisdiction. The TX power capabilities of our SoCs vary, with e.g. the nRF52840 at +8 dBm. Another option is using a front-end module (FEM) such as the nRF21540, which can do up to +21 dBm.

Regards,
Terje

[Susheel]

Hello, thanks for your reply. I understand that this is going to be a proprietary case.

There definitely seems to be a timing issue. I have tried to set a delay between each of the consequent messages in my application and it seems to work with some glitches. l have also tried playing around with the scan intervals/windows and advertising intervals but nothing seems to work smoothly. I understand mesh wasn't developed with Coded phy in mind but I'm assuming Bluetooth applications(non-mesh) send and receive messages over Coded PHY just fine..?

I have enabled debug logs at different layers in the mesh stack on both server and client . The network/transport layer of the receiver doesn't even pick up consecutive messages sometimes where I see the message sent at the transport layer on the sender. This leads me to believe the issue is at the radio layer. There should be something I am missing here.

[tesc]

Hi,

As you write, there is nothing preventing coded phy from working in principle, however packets will take longer to send which will also affect timing requirements in the mesh stack. There might be timeouts in the stack that needs to be eight times as long, and also things like the rule of maximum 100 network PDUs during the 10 second sliding window might need changing for better overall network performance.

Since we have not tested use of coded phy internally, we do not have an overview of the required changes, but if you have identified specific problem areas then we can have a look too see if we have any suggestions. In the case of configuration, there are some long messages, for instance the composition data for the node. This data is sent as one message. For the configuration there are also a few messages back and forth, where some may consist of several segments, depending on the model or configuration setting. Have you identified spesific parts of configuration that often fails, and/or seen any error messages or warnings? Or, is it merely that messages do not arrive or get responded to?

Regards,

Terje