Adding a sanitized log excerpt and the exact BLE discovery payload to help narrow this down. On the iPhone 16 Pro running iOS 27 (24A5430a), Apple's logs show complete 48-byte BLE reassembly, followed by Built FiRa localization packet V2 and RangingStarted. About 147 ms later, the phone reports FatalChipError and suspends the session for ErrorHandling: ASSERTION FAILED: hmd.c:5723: nchains_enabled >= 2, 0, 0 The app implements session(_:didUpdateDLTDOA:), but records no measurements. Apple's analytics also show: TotalClustersDiscovered = 1; TotalAnchorsObserved = 0; TotalRangingBlocksRecieved = 0; This capture is from a fresh phone reboot with both QM35 UWB sessions stopped, leaving only BLE discovery active. A separate DWM3001C receiver recorded no frames on the bench PHY. The app stayed foregrounded and stopped on the first suspension without retrying. The attachment includes the discovery bytes and Apple's parsed radio configuration, including channel, preamble, timing and receive masks. Device/session identifiers and unrelated records are omitted. Our discovery payload is experimental; successful parsing is not proof of FiRa compliance. Does this help identify an unsupported discovery parameter or a known startup issue? A supported minimal discovery example would also help us compare. Thanks! efad25a2-0aaf-49c9-85ee-74d4f384b3ab.rtf

Hi @gorka-mk, I saw your earlier post about DL-TDoA with four anchors. Were you able to resolve the session invalidation and receive measurements from the iPhone? We’re encountering a startup failure with QM35 anchors, described here. Could you share which discovery configuration or setup steps helped you get past startup? Thanks!

Hi, we’re working through this too, using QM35 anchors with an iPhone 16 Pro on iOS 27. Apple’s logs show discovery information being received, followed by RangingStarted, then FatalChipError and a suspension for ErrorHandling. The firmware report contains: ASSERTION FAILED: hmd.c:5723: nchains_enabled >= 2, 0, 0 The app receives no measurements. We’ve reproduced this after rebooting and with the anchors stopped but BLE discovery still active. Is there an infrastructure-side discovery example we could compare against? What would you recommend checking next to distinguish a configuration issue from a phone-side failure?

@estimote. you said "At the moment". Has apple given any indication that they might release an update in the future that allows you to connect to nearby UWB accessories in the background?