Issues testing BLE range with different PHY and TX power settings (nRF52840 + nRF5340) – I'm a beginner

[diegonovo02]

Hi everyone, I'm a beginner in Nordic development and currently learning how to work with BLE and Zephyr (NCS 2.9).

I'm using an nRF52840 Dongle as a peripheral and an nRF5340 DK as a central. The dongle periodically sends "PING N" messages using the NUS service, and the DK connects automatically when it detects the device name, subscribes to the service, and measures RSSI and bitrate.

My goal is to perform range tests by changing the PHY (1M, 2M, CODED S=2/S=8) and the TX power (+8, 0, -8 dBm), to observe how they affect signal distance and quality. However, I'm not seeing clear differences in bitrate across the different configurations. I'm currently sending 20-byte packets every 500 ms, and it seems that at this rate the differences are not significant. When I try to send larger packets or reduce the interval, the DK stops receiving them properly — even at short distances.

The full code and configuration files for both boards (central and peripheral) are available here:
 https://github.com/diegonovo02/ble_prueba1

I'd appreciate any suggestions or feedback on how to better configure the setup for these kinds of tests, or if there are any known limitations with the NUS service or Zephyr BLE stack I should consider.

Thanks in advance!

[Sigurd]

Hi!

I suggest double checking that the PHY change is actually updated and used on-air.

I also suggest using a nRF52840-DK instead of the dongle, since the DK have a debugger and it's easier to debug issues with that.

[diegonovo02]

Hi again, thanks for the suggestion!

I've now added a function to check the current PHY, and I can confirm that it does switch correctly between 1M, 2M, and CODED. However, I'm not sure how to verify whether the CODED PHY is actually using S=8 or S=2 — is there a way to check that in Zephyr?

Currently, I'm sending packets of 20 bytes every 500 ms (PING_LEN=20, PING_INTERVAL_MS=500). The data is transmitted correctly, but the bitrate remains almost the same regardless of the PHY used. I assume that's because the data rate is too low to show significant differences.

When I try increasing the packet size to 244 bytes and reducing the interval to 50 ms, the system gets overwhelmed and starts failing — you can see the issue in this screenshot:

My goal is to test all four PHY configurations (1M, 2M, CODED S=2, and CODED S=8) under the same conditions and observe how they affect RSSI and bitrate. But I'm not sure how to force or verify the use of S=2 vs S=8, or how to properly configure the system so it can handle higher data rates without dropping packets.

Any help or advice would be greatly appreciated, especially regarding how to properly stress-test the link and measure real PHY performance in Zephyr with the NUS service.

I have updated the git files

Thanks a lot in advance!

[Sigurd]

Hi!

diegonovo02 said:

However, I'm not sure how to verify whether the CODED PHY is actually using S=8 or S=2 — is there a way to check that in Zephyr?

I don't think so, easiest way to verify here would likely be to use a sniffer: https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le , make sure to enable Coded PHY for the sniffer. See "Interface options" at this page https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-ble-sniffer/guides/running_sniffer.html

To test throughput, I suggest this sample:

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/bluetooth/throughput/README.html

[diegonovo02]

Perfect, thank you very much. I’m using that throughput example you shared with me, but I need to add some functions like measuring RSSI and selecting the transmission power. I think I’ve already added the RSSI part, but selecting the power with something like “config pwr 8” is giving me some trouble. Do you know if that’s possible? I’m looking at the hci_pwr_ctrl example a bit.
Sorry if these questions seem absurd. I’m just getting started with this.
Thank you very much.

[Sigurd]

diegonovo02 said:

but selecting the power with something like “config pwr 8” is giving me some trouble. Do you know if that’s possible?

It's not supported by default in the throughput example, but it can be added

[diegonovo02]

Thank you very much for your assistance and explanations. After considering both options, I have the following question:

Would you recommend—for my throughput and RSSI measurements—managing static TX power levels directly from the prj.conf using entries such as:

# Power TX (enable/disable per build)
CONFIG_BT_CTLR_TX_PWR_PLUS_8=y
#CONFIG_BT_CTLR_TX_PWR_0=y
#CONFIG_BT_CTLR_TX_PWR_MINUS_8=y

and then producing a separate firmware build for each power level I wish to test?

Or, on the other hand, do you believe it would not be overly difficult to implement a config pwr <level> command in the shell (as we discussed) so that I can adjust TX power at runtime without needing to recompile every time?

Thank you!!

[Sigurd]

Hi!

Both options work, if having it runtime configurable with a "config pwr <level> command" makes it easier for you to test, then I suggest you can try implement that.