Hello Nordic team,
I'm running Channel Sounding for ranging and localization research with two nRF54L15 DKs. I compared the Ranging Service (RAS) with IPT using ras_initiator/ras_reflector and ipt_initiator/ipt_reflector samples. I have two questions: a controller crash that only happens with IPT, and whether concurrent CS connections work with IPT.
ENVIRONMENT
- Hardware: 2x nRF54L15 DK (one initiator, one reflector)
- nRF Connect SDK v3.4.0, Zephyr v4.4.0
1. CONTROLLER ASSERT 142, 151 FOLLOWED BY A HARD FAULT (IPT ONLY)
On the IPT initiator, the SoftDevice Controller asserts with 142, 151 and the board hard-faults, then resets and resumes. Over about 70 minutes of IPT capture I logged 51 of these faults. Over about 190 minutes of RAS capture I logged none.
I have attached the log screenshot for this question -
I found no public thread with assert 142/151. The closest I found is this - https://devzone.nordicsemi.com/f/nordic-q-a/129033/softdevice-controller-asserts-23-587-and-135-301-under-channel-sounding-load-on-nrf54l15-ncs-v3-4-0
Questions:
(a) What do asserts 142 and 151 mean?
(b) Is this a known issue, and is it fixed in a newer SDC or NCS release?
(c) Is there a recommended workaround? My hypothesis is that heavy UART logging at IPT's faster procedure rate delays controller timing. Does that fit what you know?
HOW TO REPRODUCE:
1. Hardware: two nRF54L15 DKs (initiator and reflector). The faults occur with the on-board antennas and with external antennas on the initiator or on both boards.
2. Build ipt_initiator and ipt_reflector from NCS v3.4.0 for nrf54l15dk/nrf54l15/cpuapp. Modifications to the samples: 
No config file changes were done.
3. Flash both boards and log the initiator's console UART (115200 baud) to a file.
4. Power both boards at a fixed distance. I saw the fault at distances between 0.97 m and 6.58 m.
5. Let it run. The initiator prints one block of ~75 per-channel IQ lines ("--- IPT IQ START ---" ... "--- IPT IQ END ---") followed by a distance estimate roughly every 250 ms. The assert occurs in the middle of the IQ lines, shortly after "CS aborted" messages, then the board hard-faults ("Fault during interrupt handling", thread sysworkq), resets and resumes. In my logs this happened about 0.7 times per minute on average (51 faults in about 70 minutes of capture), so it reproduces within a few minutes.
2. CONCURRENT CS CONNECTIONS: DOES THE LIMITATION APPLY TO IPT?
This was being discussed in another thread - https://devzone.nordicsemi.com/f/nordic-q-a/121934/concurrent-channel-sounding-procedures
I want several fixed anchors (initiators) to range one mobile reflector. I read DevZone thread ("Concurrent channel sounding procedures"). A Nordic engineer said there that sequential measurements should work, but concurrent ranging "has not been tested much" and the sample is not designed for it. The thread does not mention IPT, and it does not say what application changes would be needed.
I want to confirm whether the same applies to IPT (ipt_initiator/ipt_reflector) on NCS v3.4.0. The docs say the number of CS connections is set by BT_CTLR_SDC_CS_COUNT, but they don't say how procedures are scheduled across connections or whether IPT works with several.
Questions:
(a) Does the limitation from that thread also apply to IPT, or is IPT on several concurrent connections supported?
(b) Is concurrent CS on several connections supported in v3.4.0, or should I use sequential single-link ranging? Thread - https://devzone.nordicsemi.com/f/nordic-q-a/129033/softdevice-controller-asserts-23-587-and-135-301-under-channel-sounding-load-on-nrf54l15-ncs-v3-4-0 reports controller asserts with three concurrent connections on v3.4.0.
(c) Does running IPT on several concurrent connections need application code changes beyond Kconfig (BT_MAX_CONN, BT_CTLR_SDC_CS_COUNT)? If so, which changes, and is there a reference sample?
(d) How does the controller schedule CS procedures across several connections? The docs cover connection interval and subevent length for a single connection, but not how procedures from different connections are arranged relative to each other, or what happens if their timing overlaps.
(e) Which layout do you recommend: the tag as reflector to several initiators, or the reverse?
