I’m using a custom PCB based on the Minew ME54BS01 module (nRF54L15 SoC) for both ends of our proof‑of‑concept: one node as a GATT‑based Channel‑Sounding reflector (leveraging Zephyr’s CONFIG_BT_CHANNEL_SOUNDING, CONFIG_BT_RAS, CONFIG_BT_RAS_RRSP) and the same hardware design for the initiator (with CONFIG_BT_SCAN + UUID filter, auto‑connect, MTU/security exchange, GATT Discovery + Ranging‑Requestor flow). Separately, I’ve verified the pure CS reflector sample and the periodic BME280 sensor string broadcaster—both based on Zephyr’s examples—work flawlessly. However, when I attempt to merge connectable CS reflector functionality with dynamic ASCII scan‑response updates on a single advertising set (legacy or extended), the reflector logs HCI errors (0x0C/0x12) during CS configuration, and the initiator only begins matching the CS UUID filter after manually forcing CONFIG_BT_SCAN_UUID_CNT=1. Both nodes run nRF Connect SDK v3.0.2 (Zephyr 4.0.99). I haven’t yet implemented the initiator-side logic to receive and parse the incoming sensor string. Is it possible—and if so, what is the recommended sample or approach—to implement a dual‑role CS reflector + periodic data broadcaster on one advertising handle using our ME54BS01/nRF54L15 hardware?
