How to enable long range in pawr

[dede]

Hi,

I am developing Long Range and Pawr using nrf54l15-dk.

For the Long Range example I refer to E:\NCS\v2.8.0\nrf\samples\bluetooth\central_and_peripheral_hr and peripheral_hr_coded.

For the Pawr  example I refer to E:\NCS\v2.8.0\zephyr\samples\bluetooth\periodic_adv_rsp and periodic_sync_rsp.

The central_and_peripheral_hr and peripheral_hr_coded examples didn't give me any help. How do I use long range in the examples for periodic_adv_rsp and periodic_sync_rsp?

I found some methods on this site, but I don't know how to use .https://novelbits.io/bluetooth-long-range-coded-phy/

And some apis don't know where, such as: Switch to using Coded PHY during an existing (1M or 2M) connection via the PHY update procedure.

My goal is to implement the use of long range in the examples for periodic_adv_rsp and periodic_sync_rsp.

Thanks.

[Jakob Ruhe]

Hello dede,

To enable Coded PHY for the periodic_adv_rsp example you should be able to modify the code that creates the Extended Advertising Set like this:

	/* Create a non-connectable advertising set */
	const struct bt_le_adv_param adv_param = {
		.options = BT_LE_ADV_OPT_EXT_ADV | BT_LE_ADV_OPT_CODED,
		.interval_min = BT_GAP_ADV_FAST_INT_MIN_2,
		.interval_max = BT_GAP_ADV_FAST_INT_MAX_2,
	};
	err = bt_le_ext_adv_create(&adv_param, &adv_cb, &pawr_adv);

You also need to enable Coded PHY on both examples (periodic_adv_rsp and periodic_sync_rsp), by adding the following to the corresponding `prj.conf` files:

CONFIG_BT_CTLR_PHY_CODED=y

I have not tested this myself and there might be some more changes needed. But this should give you a good point to start from!

[dede]

Hi,

I enabled Coded PHY on two examples (periodic_adv_rsp and periodic_sync_rsp).

In the periodic_adv_rsp example, I modified the code for creating extended AD sets, Please review the code below. But the maximum distance tested was about 100 meters.I used the pawr+long range test done by nRF54L15-DK, SDK is v2.8.0.

/** Non-connectable extended advertising on coded PHY with private address */
#define BT_LE_EXT_ADV_CODED_NCONN BT_LE_ADV_PARAM(BT_LE_ADV_OPT_EXT_ADV | \
						  BT_LE_ADV_OPT_CODED, \
						  BT_GAP_ADV_FAST_INT_MIN_2, \
						  BT_GAP_ADV_FAST_INT_MAX_2, \
						  NULL)
						  
err = bt_le_ext_adv_create(BT_LE_EXT_ADV_CODED_NCONN, &adv_cb, &pawr_adv);
	if (err) {
		printk("Failed to create advertising set (err %d)\n", err);
		return 0;
	}
	printk("Created adv: %p\n", pawr_adv);

Thanks.

[Jakob Ruhe]

The code looks good to me. Which distance did you expect? Is this line of sight without other radio traffic or in an indoor office environment with traffic from 2.4 GHz WiFi and other Bluetooth devices? Which output power do you plan to use?

[dede]

Hi,

My estimated distance is about 1,300 meters and using 0 dBm Tx power, I refer to Nordic Bluetooth Long Range is 1,300 meters. The links for reference are as follows:

https://blog.nordicsemi.com/getconnected/tested-by-nordic-bluetooth-long-range#:~:text=as%20visual%20indicators.-,The%20results,or%20patterns%20we%20can%20identify.

Is the default Tx power 0 dBm for the periodic_adv_rsp and periodic_sync_rsp examples?

Please refer to the red box and red line for my test environment, which is about 100 meters away. In addition, I also found that if there are many people or cars passing between two nRF54L15-DK, it will affect the pawr communication. In addition to the modification code you provided, do I need to modify other configurations?

Thanks.

[tesc]

Hi,

Please note that the tests were performed at a remote location, with only two devices involved, with line-of-sight, with little to no interference, over water. In an urban setting, you should expect lower range and more packet loss. 100 m might be at the edge of what is possible, in such a setting. In some instances more can be possible, and in some instances even less.

Regarding configurations, I am afraid there isn't really much you can do with interference, high noise floor, or other objects blocking line-of-sight or otherwise changing the signal path. Depending on the issue, higher TX power, or to just repeat the transmission, might work.

For connections, increasing the supervision timeout will allow for more packet loss before the connection is lost.

Regards,
Terje