iOS 27 DL-TDoA with QM35: UWB error at session startup

Question

Created 6d

Replies 1

Boosts 0

Participants 1

Hi, I'm testing DL-TDoA with Qorvo QM35 anchors and an iPhone 16 Pro running iOS 27 (24A5430a). A separate DWM3001C receiver successfully receives the QM35 anchor frames, with CRC, STS and MAC integrity checks passing.

The app uses NIDLTDOAConfiguration with BLE discovery, as described in Apple’s DL-TDoA ranging guide .

supportsDLTDOAMeasurement returns true, Location permission is granted, and the app stays foregrounded.

Apple’s logs show our BLE discovery configuration being reassembled and parsed, followed by RangingStarted. Approximately 150 ms later, we see FatalChipError and a session suspension for ErrorHandling. The phone’s firmware report contains:

ASSERTION FAILED: hmd.c:5723: nchains_enabled >= 2, 0, 0

The app receives no DL-TDoA measurements. We’ve reproduced the same assertion after rebooting the phone and with both QM35 UWB sessions stopped, leaving only BLE discovery active. Incoming anchor transmissions therefore aren’t required to trigger this failure.

Has anyone encountered this assertion during DL-TDoA startup? Is there a discovery configuration requirement worth checking, or a known issue with this iOS build?

Happy to share the exact discovery payload and diagnostic logs.

Thanks!

efad25a2-0aaf-49c9-85ee-74d4f384b3ab.rtf

Answer 1

jlo11 OP

6d

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