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,

we have currently purchased the BT840E which can provide +13 dBM TX. I found some posts on this topic, but they did not help me completely (post 1, post 2). I followed the instructions described in one of the posts, but I can't seem to activate the FEM. 

I used the same same software (nrf_dm) and added the pin definitions to the overlay:

   

/ {
nrf_radio_fem: skyFem {
        compatible = "skyworks,sky66112-11", "generic-fem-two-ctrl-pins";
        ctx-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>;
        crx-gpios = <&gpio0 19 GPIO_ACTIVE_HIGH>;
        cps-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
        chl-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
        rx-gain-db = < 11 >;
        tx-gain-db = < 22 >;
     };
};

In the pry.conf added those flags:

 

CONFIG_MPSL=y
CONFIG_MPSL_FEM=y

After compiling, flashing and comparing both boards (nrf5240DK and BT840E) I got these results:

Both boards have the same distance to the mobile device. This clearly means that I have not activated the fem. What else is needed to make it work?

Thank you very much for your help.

[Michal]

J0sh1101 said:

we have currently purchased the BT840E which can provide +13 dBM TX. I found some posts on this topic, but they did not help me completely (post 1, post 2). I followed the instructions described in one of the posts, but I can't seem to activate the FEM. 

The ranging itself is done with a proprietary NDT protocol, not normal BLE. Those methods are specifically for increasing the BLE range.

J0sh1101 said:

we have currently purchased the BT840E which can provide +13 dBM TX. I found some posts on this topic, but they did not help me completely (post 1, post 2). I followed the instructions described in one of the posts, but I can't seem to activate the FEM. 

Please take a look at our Working with RF front-end modules guide.

Best regards,

Michal

[J0sh1101]

Michal said:

The ranging itself is done with a proprietary NDT protocol, not normal BLE. Those methods are specifically for increasing the BLE range.

Does the NDT protocol not work on top of the BLE. Basically, it uses the advertisement and scanning to estimate the range. Wouldn't increasing the BLE range improve the NDT protocol to some extent?

Michal said:

Please take a look at our Working with RF front-end modules guide.

I did and it describes only to upate the overlay and prj.conf files. Would it possible to know where in the code the pins are set/reset?

[Michal]

J0sh1101 said:

Does the NDT protocol not work on top of the BLE. Basically, it uses the advertisement and scanning to estimate the range. Wouldn't increasing the BLE range improve the NDT protocol to some extent?

No. BLE is only used in the sample for connecting and synchronizing the devices. You theoretically could use another protocol instead for that.

From the documentation:

Where actual ranging is done using the NDT protocol.

J0sh1101 said:

I did and it describes only to upate the overlay and prj.conf files. Would it possible to know where in the code the pins are set/reset?

FEM control is part of the Multiprotocol Service Layer (Front-end module feature). The library itself is unfortunately closed-source, but you can take a look at the API documentation.

Best regards,

Michal

[J0sh1101]

Michal said:

FEM control is part of the Multiprotocol Service Layer (Front-end module feature). The library itself is unfortunately closed-source, but you can take a look at the API documentation.

I did it, although you have to set the chl pin manually to make it work with the SKY66403-11 FEM. I have not found this in the documentation.

Maybe it would be good to update the documentation. I will close the ticket since my question has been answered. Thanks again for the help.