S8 Coded PHY Instability: Unknown Connection ID (0x02) and Link Layer Response Timeout (0x22) at RSSI ≈−81 dBm and beyond

[Aditya Bhat Handadi]

Hello,

• Goal: We are developing a long-range BLE application using S8 Coded PHY (125 kbps) to operate reliably at extended ranges (RSSI below −80 dBm).

• Devices:

  • Central:  nRF52840 running on Zephyr/nRF Connect SDK v2.5.2.

  • Peripheral:  nRF52833 (Address: F8:F2:B5:33:4C:06).

• Crucial Context: S8 Coded PHY is used for the connection which can be seen from the sniffer's advertisement packets below

  Frame 211: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface /dev/ttyACM0-4.4, id 0
      Section number: 1
      Interface id: 0 (/dev/ttyACM0-4.4)
          Interface name: /dev/ttyACM0-4.4
          Interface description: nRF Sniffer for Bluetooth LE
      Encapsulation type: nRF Sniffer for Bluetooth LE (186)
      Arrival Time: Dec  3, 2025 11:12:02.163584000 CET
      UTC Arrival Time: Dec  3, 2025 10:12:02.163584000 UTC
      Epoch Arrival Time: 1764756722.163584000
      [Time shift for this packet: 0.000000000 seconds]
      [Time delta from previous captured frame: 0.001498000 seconds]
      [Time delta from previous displayed frame: 0.001498000 seconds]
      [Time since reference or first frame: 7.355650000 seconds]
      Frame Number: 211
      Frame Length: 75 bytes (600 bits)
      Capture Length: 75 bytes (600 bits)
      [Frame is marked: False]
      [Frame is ignored: False]
      [Protocols in frame: nordic_ble:btle:btcommon]
  nRF Sniffer for Bluetooth LE
      Board: 0
      Header Version: 3, Packet counter: 225
          Length of payload: 68
          Protocol version: 3
          Packet counter: 225
          Packet ID: 2
      Length of packet: 10
      Flags: 0x21
          .... ...1 = CRC: Ok
          .... .00. = Aux Type: AUX_ADV_IND (0)
          .... 0... = Address Resolved: No
          .010 .... = PHY: LE Coded (2)
          0... .... = Reserved: 0
      Channel Index: 21
      RSSI: -81 dBm
      Event counter: 0
      Timestamp: 2814614713µs
      [Packet time (start to end): 3792µs]
      [Delta time (end to start): 330µs]
      [Delta time (start to start): 1498µs]
  Bluetooth Low Energy Link Layer
      Access Address: 0x8e89bed6
      .... ..00 = Coding Indicator: FEC Block 2 coded using S=8 (0)
      Packet Header: 0x3047 (PDU Type: AUX_ADV_IND, TxAdd: Random)
          .... 0111 = PDU Type: 0x7 AUX_ADV_IND
          ...0 .... = Reserved: 0
          ..0. .... = Reserved: 0
          .1.. .... = Tx Address: Random
          0... .... = Reserved: 0
          Length: 48
      Extended Advertising Header
          ..00 1001 = Extended Header Length: 9
          01.. .... = Advertising Mode: Connectable Non-scannable (0x1)
          Extended Header Flags: 0x09
              .... ...1 = Advertiser Address: Present
              .... ..0. = Target Address: Not Present
              .... .0.. = CTE Info: Not Present
              .... 1... = Advertiser Data Info: Present
              ...0 .... = Aux pointer: Not Present
              ..0. .... = Sync Info: Not Present
              .0.. .... = TX Power: Not Present
              0... .... = Reserved: Not Present
          Advertising Address: f8:f2:b5:33:4c:06 (f8:f2:b5:33:4c:06)
          Advertiser Data Info: 0x1ce2
              .... 1100 1110 0010 = Advertiser Data Identifier: 0xce2
              0001 .... .... .... = Advertiser Set Identifier: 0x1
      Advertising Data
          Flags
              Length: 2
              Type: Flags (0x01)
              000. .... = Reserved: 0x0
              ...0 .... = Simultaneous LE and BR/EDR to Same Device Capable (Host): false (0x0)
              .... 0... = Simultaneous LE and BR/EDR to Same Device Capable (Controller): false (0x0)
              .... .1.. = BR/EDR Not Supported: true (0x1)
              .... ..0. = LE General Discoverable Mode: false (0x0)
              .... ...0 = LE Limited Discoverable Mode: false (0x0)
          128-bit Service Class UUIDs
              Length: 17
              Type: 128-bit Service Class UUIDs (0x07)
              Custom UUID: 38401002-df44-1c14-44c1-d94b0ebbec73 (Unknown)
          Device Name: Peripheral Key
              Length: 16
              Type: Device Name (0x09)
              Device Name: Peripheral Key
      CRC: 0x4c71ef

• Test Environment: Indoors and Outdoor in a open field

• Issue: The Link Layer (LL) handshake either failed completely or was terminated immediately by the Peripheral before the Central's Host stack could signal success and the 3 seconds connection timeout is quite evident.
  

  [  623.252899] <dbg> Central: start_scan: Scanning successfully started
  [  625.945556] <wrn> Central: PriPHY: 4, SecPHY: 4, RSSI: -81
  [  625.945983] <dbg> Central: connect: Connecting to: F8:F2:B5:33:4C:06 (random), coded_phy: 1
  [  625.946014] <wrn> Central: Coded: 1
  [  628.946563] <dbg> Central: disconnected: Disconnected (reason 0x02)
  
  [  823.252899] <dbg> Central: start_scan: Scanning successfully started
  [  825.945556] <wrn> Central: PriPHY: 4, SecPHY: 4, RSSI: -95
  [  825.945983] <dbg> Central: connect: Connecting to: F8:F2:B5:33:4C:06 (random), coded_phy: 1
  [  825.946014] <wrn> Central: Coded: 1
  [  828.946563] <dbg> Central: disconnected: Disconnected (reason 0x22)

• Correlation: This failure mode strongly correlates with a marginal RSSI (≈−81 dBm or worse). The connection is stable at shorter ranges.
• Error Code: BT_HCI_ERR_UNKNOWN_CONN_ID and BT_HCI_ERR_LL_RESP_TIMEOUT
  
  Since S8 is confirmed, what are the most common Link Layer parameters (besides PHY) that, if misconfigured, cause an immediate 0x02 rejection at marginal RSSI? Are there recommended minimum Connection Interval values for S8 Coded PHY operation below −80 dBm? 
  
  Kindly let me know if you need more details.
  
  Any guidance on identifying the specific root cause for the 0x02 Link Layer rejections or suggestions for optimizing our S8 Coded PHY connection parameters would be highly valued.
  
  
  Cheers, 
  Aditya

[Amanda Hsieh]

Hi, 

You can check out this post. 

Regards,
Amanda H.

[Aditya Bhat Handadi]

Hi Amanda, 

Thank you so much for pointing me to the CONFIG_CLOCK_CONTROL_NRF_K32SRC configuration.

This was a huge breakthrough! You are a savior! Our previous setting was $50\text{ ppm}$ (CONFIG_CLOCK_CONTROL_NRF_K32SRC_50PPM). By setting the $\text{Low}$ $\text{Frequency}$ $\text{Clock}$ $\text{Source}$ ($\text{LFXO}$) tolerance to $150\text{ ppm}$, we completely solved the connection stability issues we were seeing indoors! However, the outdoor tests are still pending.

The $0x02$ $\text{HCI}$ errors are gone. This confirms that with the previous $50\text{ ppm}$ setting, the clock drift was just too severe for the slower, longer $\text{S8}$ $\text{Coded}$ $\text{PHY}$ connection events, causing the $\text{Link}$ $\text{Layer}$ to fail.

Are there any potential side effects of using CONFIG_CLOCK_CONTROL_NRF_K32SRC_150PPM over the stricter CONFIG_CLOCK_CONTROL_NRF_K32SRC_50PPM? Specifically, should we be concerned about increased power consumption or reduced timing accuracy in other parts of the application?

Cheers,
Aditya

[Amanda Hsieh]

It would slightly increase power consumption, but it is usually a worthy trade-off for connection stability.