Does the nRF Distance Measurment application support TX power be increased to 4/8 dBm?

[J0sh1101]

Hi,

I am trying to measure the distance of two objects, which can vary from 20 to 350 meters. We have tried the nRF Distance Measurement with Bluetooth LE discovery, which worked fine up to 120 meters. I would like to increase the range by increasing the transmit power to 8 or at least 4 dBm.

I took this code snippet we found here and added it to the RF Distance Measurement with Bluetooth LE discovery. This is what I added to the code:

	err = service_ddfs_init();
	if (err) {
		printk("DDF Service init failed (err %d)\n", err);
		return 0;
	}
	
	set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV,0, 4);
	
	err = bt_enable(NULL);
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
		return 0;
	}
	

After running the code I got an exception fromt hci core:

*** Booting Zephyr OS build v3.3.99-ncs1 ***
Starting Distance Measurement example
E: ***** MPU FAULT *****
E:   Data Access Violation
E:   MMFAR Address: 0x14d31
E: r0/a1:  0x00000000  r1/a2:  0x00000004  r2/a3:  0x00014d31
E: r3/a4:  0x2000f700 r12/ip:  0x00000022 r14/lr:  0x00032e59
E:  xpsr:  0x21000000
E: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
E: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
E: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
E: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
E: fpscr:  0x00000000
E: Faulting instruction address (r15/pc): 0x0003c76a
E: >>> ZEPHYR FATAL ERROR 19: Unknown error on CPU 0
E: Current thread: 0x20007698 (unknown)
E: Resetting system

After looking in the zehpyhr.lst file to see where the program counter was before the exception occurred, I couldn't find anything helpful:

0003c75e <z_handle_obj_poll_events>:
{
   3c75e:	4603      	mov	r3, r0
	return list->head == list;
   3c760:	6800      	ldr	r0, [r0, #0]
	if (!sys_dlist_is_empty(list)) {
   3c762:	4283      	cmp	r3, r0
   3c764:	d008      	beq.n	3c778 <z_handle_obj_poll_events+0x1a>
	sys_dnode_t *const next = node->next;
   3c766:	e9d0 3200 	ldrd	r3, r2, [r0]
	prev->next = next;
   3c76a:	6013      	str	r3, [r2, #0]
	next->prev = prev;
   3c76c:	605a      	str	r2, [r3, #4]
	node->next = NULL;
   3c76e:	2300      	movs	r3, #0
	node->prev = NULL;
   3c770:	e9c0 3300 	strd	r3, r3, [r0]
		(void) signal_poll_event(poll_event, state);
   3c774:	f7ff bf99 	b.w	3c6aa <signal_poll_event>
}
   3c778:	4770      	bx	lr

I also tried to change the TX  power with configuration flag defined in the prj.conf, but It did not improve or help anything:

CONFIG_BT_CTLR_TX_PWR_PLUS_8=y

Can someone explaine me what is happening?

Thanks for the help!!!

OS: Windows

SDK: 2.4.0

IDE: Visual Studio Code

Hardware: nRF52840 DK

[J0sh1101]

Update: 

I think I managed to set the TX power to 8 dBm with the configuration flag.

At the beginning, I added the configuration flags to dynamically change the transmit power. I added these flags to prj.conf:

# dynamically change the TX power level
CONFIG_BT_LL_SW_SPLIT=y
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y
CONFIG_BT_CTLR_CONN_RSSI=y

Adding these flags leads to the exception I posted above. That shouldn't really happen, right?

After I removed the flags and added only the CONFIG_BT_CTLR_TX_PWR_PLUS_8. The application seemed to work.

I set the TX to 8 dBm and to -40 dBm to check if I could see a difference in the RSSI on the phone. There was a difference; the TX 8 dBm showed -20 dBm and the TX -40 dBm showed -69 dBm on the phone.

I would still like to dynamically adjust the TX power. Is this possible?

Thanks for the help!

[Susheel Nuguru]

J0sh1101 said:

I would still like to dynamically adjust the TX power. Is this possible?

Yes you should be able to use HCI power control API and dynamically control the TX power. In your case it is hard to say what went wrong. Can you please enable the below in your config and run your application again?

CONFIG_BT_LL_SW_SPLIT=y  #not sure why you want to use Zephyr controller?
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y
CONFIG_BT_CTLR_CONN_RSSI=y
CONFIG_NO_OPTIMIZATIONS=y
CONFIG_THREAD_NAME=y

The aim is to get the thread name which is causing the fault. My best guess is that enabling all these features might be causing a stack overflow of some system queue or workqueue. Increasing the stack sizes of some of these common queues will help, but we need to know the thread name causing exception first.

[J0sh1101]

Hi Susheel,

After re-enabling the BLE flags in the configuration file and running the application again, I found that the assert is being triggered in the hci_core.c file at line 330:

The code tries to send the reset to the BLE controller. Acquiring the semphore "sync_sem" returns the value -11, which means that the function has timed out. This happens in the main thread. You can also see the calling stack or frame on the left.  The question here is why the semaphore is not released. 

"CONFIG_BT_LL_SW_SPLIT=y  #not sure why you want to use Zephyr controller?"

If I don't do that, I get this warning message:

Is it possible to enable the BLE long range on the  nRF Distance Measurement with Bluetooth LE discovery? I modified the connected function like this:

BT_CONN_CB_DEFINE(conn_callbacks) = {
	.connected = connected,
	.disconnected = disconnected,
	.le_phy_updated = on_le_phy_updated,
};

static void connected(struct bt_conn *conn, uint8_t conn_err)
{
	adv_param = &adv_param_noconn;
	k_work_submit(&adv_work);
	int ret;

    my_conn = bt_conn_ref(conn);
	//ret = bt_hci_get_conn_handle(my_conn, &my_conn_handle);
	if (ret) {
		printk("No connection handle (err %d)\n", ret);
		return;
	}

    //Update the PHY mode 
    const struct bt_conn_le_phy_param preferred_phy = {
        .options = BT_CONN_LE_PHY_OPT_NONE,
        //.pref_rx_phy = BT_GAP_LE_PHY_2M,
        //.pref_tx_phy = BT_GAP_LE_PHY_2M,
		.pref_rx_phy = CONFIG_BT_CTLR_PHY_CODED,
        .pref_tx_phy = CONFIG_BT_CTLR_PHY_CODED,
    };
    ret = bt_conn_le_phy_update(my_conn, &preferred_phy);
    if (ret) {
        
	}
	
	void on_le_phy_updated(struct bt_conn *conn, struct bt_conn_le_phy_info *param)
{
	// PHY Updated
	if (param->tx_phy == BT_CONN_LE_TX_POWER_PHY_1M) {
		printk("PHY updated. New PHY: 1M");
	} else if (param->tx_phy == BT_CONN_LE_TX_POWER_PHY_2M) {
		printk("PHY updated. New PHY: 2M");
	} else if (param->tx_phy == BT_CONN_LE_TX_POWER_PHY_CODED_S8) {
		printk("PHY updated. New PHY: Long Range");
	}
}

The function on_le_phy_updated was never called as I never connected to any BLE device. I think I need to tell the BLE controller to the use the modulation scheme/ Coded PHY when it is advertising, right? Do you know how do I do that. 

I noticed that you did the BLE long range test. As you may have read in the first post, we measure the distance of two large objects, which can be between 20 and 350 metres, with an accuracy of 10 metres. Do you think it is possible to do that with this library and the RTT algorithm?  If not, do you have another idea how to do it with BLE?

According to this BLE range estimator , that should be possible, but that's just theory:

Thank you for your answears. 

[Michal]

Hello, I took over the case from Susheel.

I would like to ask you to use the SoftDevice Controller, since that is what we support and can help with. I would recommend looking at for example the Bluetooth: Peripheral Heart Rate Monitor with Coded PHY for the correct configurations.

The issue with Coded PHY in your setup is that you are only turning it on in the connected callback, which means that advertising is NOT done in Coded PHY.

That means that if the devices are too far away from each other at the beginning or if the connection is lost, they won't be able to connect even at a distance supported by Coded PHY.

Best regards,

Michal

[J0sh1101]

Hi Michael,

thanks for taking over the case. 

Michal said:

I would like to ask you to use the SoftDevice Controller, since that is what we support and can help with

I do not completly understand it, because I mainly use the Nordic tools and Nordic software. Shouldn't I then use the SoftDevice controller by default, or am I overseeing something here?

Michal said:

I would recommend looking at for example the Bluetooth: Peripheral Heart Rate Monitor with Coded PHY for the correct configurations.

I looked at the code and updated the nrf_dm with these two lines:

struct bt_le_adv_param adv_param_conn =
	BT_LE_ADV_PARAM_INIT(BT_LE_ADV_OPT_CONNECTABLE |
			     BT_LE_ADV_OPT_NOTIFY_SCAN_REQ |
				 BT_LE_ADV_OPT_EXT_ADV | // this is also needed for the BLE long range
				 BT_LE_ADV_OPT_CODED,  // this flags enables the BLE long range
			     BT_GAP_ADV_FAST_INT_MIN_2,
			     BT_GAP_ADV_FAST_INT_MAX_2,
			     NULL);

struct bt_le_adv_param adv_param_noconn =
	BT_LE_ADV_PARAM_INIT(BT_LE_ADV_OPT_USE_IDENTITY |
			     BT_LE_ADV_OPT_SCANNABLE |
			     BT_LE_ADV_OPT_NOTIFY_SCAN_REQ,
			     BT_GAP_ADV_FAST_INT_MIN_2,
			     BT_GAP_ADV_FAST_INT_MAX_2,
			     NULL);


struct bt_le_adv_param *adv_param = &adv_param_conn;

I just added the flag to enable extended advertising support and the flag to enable BLE long distance. After compiling and running, I get this console output:

I: SoftDevice Controller build revision: 
I: e0 7e 2e c1 5e 05 85 23 |.~..^..#
I: 46 15 dc fa 8e 29 7d 70 |F....)}p
I: 10 93 a5 fc             |....    
I: HW Platform: Nordic Semiconductor (0x0002)
I: HW Variant: nRF52x (0x0002)
I: Firmware: Standard Bluetooth controller (0x00) Version 224.11902 Build 2231721665
I: Identity: E6:B0:76:20:0E:41 (random)
I: HCI: version 5.4 (0x0d) revision 0x1077, manufacturer 0x0059
I: LMP: version 5.4 (0x0d) subver 0x1077
DM Bluetooth LE Synchronization initialization
Failed setting adv data (err -134)
Failed to start advertising (err -134)
Synchronisation init failed (err -134)

The error code -143 is ENOTSUP, which means that the value is not supported. After debugging the code, I found that these two if statements trigger the failure:

Basically, the code tells me that if the advanced advertising is activated, either only the scan packet or the advertising can be sent, but not both. How can this be resolved? The nRF distance measurement needs both (advertising and scanning options).

One way to increase the range is also to increase the antenna gain. We are currently using the nrf9160 DK and nrf52840 boards. Does nordic know of a good, suitable antenna for our current boards that provides a few dBi to increase our range?

I've seen a few suggestions here on the Nordic forum, but I'm not sure how efficient they are, and besides, you have to tune the Atenna, right?

Links:

 Improve / increase range between nRF52840DK and custom peripheral attaching external antenna to DK?  External SMA Antenna on nRF52840 DK   

Thanks again for the help!

[Michal]

Hello,

J0sh1101 said:

I do not completly understand it, because I mainly use the Nordic tools and Nordic software. Shouldn't I then use the SoftDevice controller by default, or am I overseeing something here?

CONFIG_BT_LL_SW_SPLIT is a config for enabling the Zephyr Bluetooth controller. the SoftDevice Controller should be enabled by default if you remove it, as you can see in the documentation.

J0sh1101 said:

The error code -143 is ENOTSUP, which means that the value is not supported. After debugging the code, I found that these two if statements trigger the failure:

J0sh1101 said:

Basically, the code tells me that if the advanced advertising is activated, either only the scan packet or the advertising can be sent, but not both. How can this be resolved? The nRF distance measurement needs both (advertising and scanning options).

I have to ask our bluetooth experts and I will get back to you.

J0sh1101 said:

One way to increase the range is also to increase the antenna gain. We are currently using the nrf9160 DK and nrf52840 boards. Does nordic know of a good, suitable antenna for our current boards that provides a few dBi to increase our range?

I've seen a few suggestions here on the Nordic forum, but I'm not sure how efficient they are, and besides, you have to tune the Atenna, right?

I would recommend creating a new case for that, so that our hardware experts can look into it. And yes, we do offer antenna tuning if needed.

For the cellular antennas you may want to take a look at our list of Nordic Solution Partners.

Best regards,

Michal

[J0sh1101]

Okay, thanks for the upate.

[PaKa]

You need to use the SoftDevice Controller subsystem (SDC) with NDT as it uses the MPSL. MPSL is only supported with SDC and not with the Zephyr controller.

NDT should NOT be used with coded PHY as all ranging is performed with non-coded PHY so trying to use coded PHY may make the devices visible further away but if you can't see them with 1Mbps then you can't range between them anyway so no benefit.

Advertising on coded PHY uses extended advertising and that to my knowledge does not support scan response, probably because it uses data channels in combination with advertising channels to do the job.

[J0sh1101]

PaKa said:

You need to use the SoftDevice Controller subsystem (SDC) with NDT as it uses the MPSL. MPSL is only supported with SDC and not with the Zephyr controller.

Okay. So both SDC and MPSL are a set of libraries, interrupts, to control the radio.

PaKa said:

NDT should NOT be used with coded PHY as all ranging is performed with non-coded PHY so trying to use coded PHY may make the devices visible further away but if you can't see them with 1Mbps then you can't range between them anyway so no benefit.

This is something I don't quite understand. There are many sites (one site) and videos (one video) that claim you can increase your range with ble long range (PHY). If you can get your package to travel a longer distance, then that also means you can measure a longer distance using the RTT method. What am I missing here? The only problem is that the receiver cannot decode a single symbol due to very poor SNR.

PaKa said:

Advertising on coded PHY uses extended advertising and that to my knowledge does not support scan response, probably because it uses data channels in combination with advertising channels to do the job.

What a bummer!! Afterwards I read also that this is not defined in the BLE specifications.