nRF Connect SDK 2.8.0 Mesh with Coded PHY (Long Range)

[rmarques]

I am exploring the possibility of using ncs v2.8.0 for Mesh with Coded PHY on the nRF52840dk/nRF52840 board. I know this is not officially supported.

I started with the mesh_provisioner sample and added the following CONFIGs to my prj.conf to activate logging by RTT and what I think is needed for coded phy:

CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=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_CTLR_PHY_CODED=y

I also updated my adv_ext.c:

void bt_mesh_adv_init(void)
{
	struct bt_le_adv_param adv_param = {
		.id = BT_ID_DEFAULT,
		.interval_min = BT_MESH_ADV_SCAN_UNIT(ADV_INT_FAST_MS),
		.interval_max = BT_MESH_ADV_SCAN_UNIT(ADV_INT_FAST_MS),
// #if defined(CONFIG_BT_MESH_DEBUG_USE_ID_ADDR)
// 		.options = BT_LE_ADV_OPT_USE_IDENTITY,
// #endif
		.options = BT_LE_ADV_OPT_CODED | BT_LE_ADV_OPT_EXT_ADV,
	};
	.
	.
	.
}

And adv.c:

static void bt_mesh_scan_cb(const bt_addr_le_t *addr, int8_t rssi,
			    uint8_t adv_type, struct net_buf_simple *buf)
{
    // if (adv_type != BT_GAP_ADV_TYPE_ADV_NONCONN_IND) {
    if (adv_type != BT_GAP_ADV_TYPE_EXT_ADV) {
    	return;
    }
    .
    .
    .
}

int bt_mesh_scan_enable(void)
{
	struct bt_le_scan_param scan_param = {
		.type = active_scanning ? BT_LE_SCAN_TYPE_ACTIVE :
					  BT_LE_SCAN_TYPE_PASSIVE,
		.interval = MESH_SCAN_INTERVAL,
		.options = BT_LE_SCAN_OPT_CODED | BT_LE_SCAN_OPT_NO_1M,
		.window = MESH_SCAN_WINDOW
	};
    .
    .
    .
}

I noticed I was missing some logs on RTT so I added a k_msleep(5000); after printk("initializing"); right in the beginning of the main function.

Then I started seeing the warning and error at the end of the next log:

Initializing...
[00:00:05.007,324] <inf> fs_nvs: 2 Sectors of 4096 bytes
[00:00:05.007,324] <inf> fs_nvs: alloc wra: 0, fe8
[00:00:05.007,354] <inf> fs_nvs: data wra: 0, 0
[00:00:05.007,415] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision: 
                                            fe 2c f9 6a 7f 36 22 2e  a0 79 c0 40 be 2c 03 20 |.,.j.6". .y.@.,. 
                                            40 c2 f3 32                                      |@..2             
[00:00:05.009,338] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:05.009,368] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:05.009,399] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 254.63788 Build 573996906
[00:00:05.009,582] <inf> bt_hci_core: No ID address. App must call settings_load()
Bluetooth initialized
Mesh initialized
Loading stored settings
[00:00:05.270,202] <inf> bt_hci_core: Identity: D2:8E:FC:17:F6:A4 (random)
[00:00:05.270,233] <inf> bt_hci_core: HCI: version 6.0 (0x0e) revision 0x104e, manufacturer 0x0059
[00:00:05.270,263] <inf> bt_hci_core: LMP: version 6.0 (0x0e) subver 0x104e
Created CDB
[00:00:05.270,690] <inf> bt_mesh_main: Primary Element: 0x0001
[00:00:05.282,287] <wrn> bt_hci_core: opcode 0x2041 status 0x12 
[00:00:05.282,318] <err> bt_mesh_adv: starting scan failed (err -22)
Provisioning completed
Configuring self...
Configuration complete
Waiting for unprovisioned beacon...
Waiting for unprovisioned beacon...

I'm worried I'm missing something, this doesn't happen without the changes for the Coded PHY mesh. Should I change something else?

[tesc]

Hi,

I am afraid we do not have time to look thoroughly at this before the holidays, but in general:

• A Bluetooth Mesh solution built on top of Coded Phy is not qualifiable as a Bluetooth Mesh product, since the Bluetooth Mesh Protocol specification mandates use of the ADV_NONCONN_IND PDU type, which by Bluetooth Core specification is for 1M Phy only.
• That being said, there is nothing else in the BLE stack or the Bluetooth Mesh stack which should prevent such a solution from working, with a few caveats covered, e.g.:
  • that there are enough bytes available in the advertising packets used for the full contents of the Bluetooth Mesh related Advertising Data types
  • that advertising parameters and scan parameters used by the stack are compatible with Coded Phy
  • etc.

Now, for a Coded Phy solution to work, every part of the Bluetooth Mesh stack which touches upon advertising or scanning, might potentially need an update, in order to use an advertisement PDU type which is compatible with Coded Phy. I see that your changes are of that nature, but I am not sure if you have covered all the required places. Please note also that features such as GATT Proxy also uses BLE, and for that you may want to use Coded Phy or 1M depending on what can be supported by the central device, typically a smartphone.

To the particular issue that you are seeing right now, error code 22 is "invalid argument". In other words, the scan_param provided to bt_le_scan_start() inside bt_mesh_scan_enable() in adv.c is not considered valid. It might be as simple as the scan failing to start due to MESH_SCAN_INTERVAL / MESH_SCAN_WINDOW not working well with Coded Phy (e.g. too short?) or if the scan type (BT_HCI_LE_SCAN_ACTIVE or BT_HCI_LE_SCAN_PASSIVE, depending on the value of active_scanning) is somehow incompatible with Coded Phy. At least it looks like some change is needed, either for the constants used, or the code itself, for bt_mesh_scan_enable(), in <sdk folder>\zephyr\subsys\bluetooth\mesh\adv.c.

Regards,
Terje

[rmarques]

Hi tesc, thanks for the pointers. I have been experimenting with increasing MESH_SCAN_INTERVAL and MESH_SCAN_WINDOW in adv.c and while it looks like it worked, having returned the defines to the original values it doesn't complain about starting the scan. I may have fixed the issue somewhere else.

Still, I don't see a noticeable difference in the message RSSI with and without long range. I'm going to run some simple tests to count the number of messages arriving successfully to a device with and without long range to see if there's something else other than the RSSI to tell me if this is working or not.

In the meantime, would you be interested in having a look at what's needed for Mesh with Long Range in nRF Connect?

Happy New Year!

Best,

Rúben

[tesc]

Hi,

rmarques said:

I may have fixed the issue somewhere else.

Most likely this would be change of advertising type and/or advertising parameters. Maybe something is different now from then, even though most parameters are back at the initial values.

rmarques said:

Still, I don't see a noticeable difference in the message RSSI with and without long range. I'm going to run some simple tests to count the number of messages arriving successfully to a device with and without long range to see if there's something else other than the RSSI to tell me if this is working or not.

Coded phy does not change RSSI, as the TX power is still the same. The difference is that more time is spent for each symbol, essentially allowing for some error correction, and successful reception at slightly lower RSSI. Please note also that RSSI is received signal strength indication, and not an accurate measurement of the actual signal strength. Rather, it is based on the general power level received from the antenna, at or close to the given frequency, when the packet is being received. It is often a good measure, but there will be some variability.

You should get some indication from power measurements (showing the time spent for each advertisement packet), or from a BLE sniffer (which should show you for each packet what physical layer was used.)

rmarques said:

In the meantime, would you be interested in having a look at what's needed for Mesh with Long Range in nRF Connect?

My previous answer covers the general gist of what must be done. We don't have a full detailed list of what changes are needed. If you run into any specific issues along the way, then we are more than happy to help you overcome those issues.

Regards,
Terje