Heartrate with Coded PHY example from nRF Connect SDK with nRF52833 - Range is disappointing

Hi,

I am using two Fanstel BM833 dev kits which feature an nRF52833 to test the coded PHY feature. The advertised range is up to 1500m line of sight with the PCB antenna. I used the "peripheral_hr_coded" and "central_hr_coded" examples from the nRF Connect SDK. As-is, this code gives me a range of about 100-150m line-of-sight before the terminal tells me it lost the connection.

  • What could make me increase the range further from this example? I saw a few mentions of increasing the output power but it's not clear to me where to set that.
  • Also, is the heartrate example optimized for range or are there ways to increase the range further?

1-way communication (peripheral to central only) is acceptable in our application. An example that is optimized for range would be fantastic to evaluate the potential quickly!

Thanks for your help

Parents
  • As-is, this code gives me a range of about 100-150m line-of-sight before the terminal tells me it lost the connection.

    That is unacceptably dissapointing results. Can you please make sure in the logs or sniffer that you in fact have a coded phy connection? Also what is the TX power for each set to?

  • Hi Susheel,

    I wish I could externally confirm that the connection is a coded phy connection but as far as I can tell from the devzone (here, here and here), the nRF Sniffer doesn't support coded phy. Has this changed? I tried running a sniffer on an nRF52840-DK and I can't see any traffic from the two devices, but they are happily exchanging information.

    As far as TX power goes, I haven't changed it from the examples. How can I set this to the maximum for the SoC?

    Thanks for your support!

  • You are right, nRF sniffer cannot pack extended adv packets so it cannot support coded phy.

    Even though the connection is established in the phy that is used by adv/scanner, you can try to initiate a phy update procedure in the connected event (just after the connection) using sd_ble_gap_phy_update. You will then get the details of which phy your connection is on and you can show that on the logs. Something similar to what is explained in this thread.

    Felix Cormier said:
    As far as TX power goes, I haven't changed it from the examples. How can I set this to the maximum for the SoC?

    sd_ble_gap_tx_power_set

  • Correct me if I'm wrong, but both the suggestions you made use the SoftDevice libraries (S113). However, as far as I can tell, the "peripheral_hr_coded" and "central_hr_coded" examples that I'm using from the nRF Connect SDK (\v1.9.0\nrf\samples\bluetooth) don't use S113 (unless they do under the hood?). These examples already implement coded phy, that's why I'm trying to start from them. They use the libraries from (\v1.9.0\nrf\include\bluetooth). Is there a way to do these two things using those libraries?

    1. Ensure the connection is really coded phy
    2. Adjust the TX power

    Thanks for your help,

Reply
  • Correct me if I'm wrong, but both the suggestions you made use the SoftDevice libraries (S113). However, as far as I can tell, the "peripheral_hr_coded" and "central_hr_coded" examples that I'm using from the nRF Connect SDK (\v1.9.0\nrf\samples\bluetooth) don't use S113 (unless they do under the hood?). These examples already implement coded phy, that's why I'm trying to start from them. They use the libraries from (\v1.9.0\nrf\include\bluetooth). Is there a way to do these two things using those libraries?

    1. Ensure the connection is really coded phy
    2. Adjust the TX power

    Thanks for your help,

Children
  • I am really sorry that i got stuck on the softdevice API even though you clearly mentioned nRF Connect SDK.

    Felix Cormier said:
    Ensure the connection is really coded phy
    bt_conn_get_info will give you info where you can check info->le->phy to know which phy you have tx and rx on.
    You can also do a force bt_conn_le_phy_update to coded phy just after the connection just to be sure.
    Felix Cormier said:
    Adjust the TX power

    I normally use this code snippet in my hobby testing projects. It might be helpful to you in your case.

    static void set_tx_power(uint8_t handle_type, uint16_t handle, int8_t tx_pwr_lvl)
    {
    	struct bt_hci_cp_vs_write_tx_power_level *cp;
    	struct bt_hci_rp_vs_write_tx_power_level *rp;
    	struct net_buf *buf, *rsp = NULL;
    	int err;
    
    	buf = bt_hci_cmd_create(BT_HCI_OP_VS_WRITE_TX_POWER_LEVEL,
    				sizeof(*cp));
    	if (!buf) {
    		printk("Unable to allocate command buffer\n");
    		return;
    	}
    
    	cp = net_buf_add(buf, sizeof(*cp));
    	cp->handle = sys_cpu_to_le16(handle);
    	cp->handle_type = handle_type;
    	cp->tx_power_level = tx_pwr_lvl;
    
    	err = bt_hci_cmd_send_sync(BT_HCI_OP_VS_WRITE_TX_POWER_LEVEL,
    				   buf, &rsp);
    	if (err) {
    		uint8_t reason = rsp ?
    			((struct bt_hci_rp_vs_write_tx_power_level *)
    			  rsp->data)->status : 0;
    		printk("Set Tx power err: %d reason 0x%02x\n", err, reason);
    		return;
    	}
    
    	rp = (void *)rsp->data;
    	printk("Actual Tx Power: %d\n", rp->selected_tx_power);
    
    	net_buf_unref(rsp);
    }

Related