XIAO nRF54L15 - BLE Coded PHY S=8 for Wireless Sensor Data

Products & Technology XIAO
1

Hi everyone!

I’m currently working on a project during my internship where I’m investigating wireless communication for transmitting sensor data.

The goal is to send relatively small amounts of data (approximately 64 bytes) every 500 milliseconds over a distance of around 100 meters. Since reliability is one of the main requirements, I’ve been experimenting with BLE Coded PHY S=8 using the Seeed Studio XIAO nRF54L15.

So far, I’ve managed to establish BLE connections and successfully transmit data between multiple XIAO boards. However, I’ve run into a few challenges that I’m hoping someone here might be able to help me with.

Verifying Coded PHY S=8

My code reports tx_phy = 4 and rx_phy = 4, which confirms that LE Coded PHY is being used. However, I’m still unsure how to verify whether the actual data transmission uses S=8 rather than S=2. Is there a way to confirm this through software, or would I need additional hardware to measure it?

Low RSSI values

Another issue I’ve noticed is that the RSSI is consistently quite low, usually around -90 to -98 dBm, even when the boards are less than 2 meters apart.

I’m currently using the onboard ceramic antennas, and I suspect this might have something to do with the antenna configuration or RF switch. I’ve looked into the settings for controlling the power to the RF switch and selecting between the onboard and external antenna, but I’m not entirely sure whether everything is configured correctly.

Connection stability

The connection also occasionally drops, sometimes with errors such as 0x08 and 0x28, before reconnecting.

To deal with temporary connection losses, I’ve implemented a buffering system that stores sensor measurements locally and automatically sends them once the connection has been restored. Since the data is intended for offline analysis rather than real-time monitoring, a short delay isn’t a major issue. However, I’d prefer to have a stable connection in the first place and use the buffer mainly as a fallback.

While looking for information, I came across the excellent range tests shared by @msfujino and decided to try his example code. I made a few modifications to run it without the OLED display using nRF Connect SDK v3.4.1. I successfully managed to establish a LE Coded PHY connection, but I’m still experiencing the low RSSI values and occasional disconnections mentioned above.

My main question is: Has anyone here successfully used BLE Coded PHY S=8 on the XIAO nRF54L15 for reliable, periodic sensor data transmission? I’m particularly interested in how you verified S=8 and whether there are specific settings or configurations that could help improve the signal strength, range and overall connection stability.

Any advice, experiences or examples would be greatly appreciated!

Thanks in advance!

2

https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-1-bluetooth-low-energy-introduction/topic/phy-radio-modes/?version=v3.3.0

3

Hi there,

And Welcome here,

So, 2 ways I use to check the Stats.
Look at the connection params in Nrf for Desktop BLE app. shows he connections settings.
or
2. Check the Connection Parameters Event (ESP-IDF / Arduino)

When the connection event callback triggers (ESP_GATTC_CONNECT_EVT or BLE_GAP_EVT_CONNECTED), the connection parameter update structure provides the active coding scheme details. You can read the conn_params or query the link directly:

esp_ble_conn_update_params_t conn_params = {0};
// The connection handle can be used to query active PHY details
esp_ble_gap_read_rssi(param->connect.remote_bda);

In the Nordic or ESP-IDF Bluetooth stack logs, look closely at the debug output when the connection establishes. The stack logs the active LE Coded PHY option explicitly during the PHY update complete callback:

  • BLE_GAP_PHY_CODED with S=8 will show a significantly longer packet transmission duration and lower throughput profile in the link layer logs compared to S=2.

2. Verify via Air Time / Range Benchmark

Because you cannot read an explicit s_factor variable directly from standard high-level GATT APIs in some core versions, the most foolproof software verification method is measuring packet round-trip time (RTT) or effective payload transmission time:

  • S=2 doubles the range of uncoded PHY by coding 2 symbols per bit.

  • S=8 quadruples the range by coding 8 symbols per bit, meaning transmission time for your 64-byte payload will take exactly 4 times longer than S=2 under identical conditions.

Your using the SoftDevice so there are Debug modes you can use as well.(look at the call back )

The Low RSSI’s are probably related to the Switch and configuration settings for the Coded_PHY, If you post up the code , Using the code Tags above “</>” paste it in there,
We can look. :+1:

HTH
GL :slight_smile: PJ :v: