Value of IOS/Android UWB configuration exchange

Wireless Connectivity Ultra-Wideband
1

We have an app that does UWB ranging with the 3001CDK under iOS using QANI and an app that does UWB ranging on the Murata Type2AB using UCI

Both of the samples have the two sides exchanging configurations.

The sdk Fira twr scripts using USB don’t/cant do that.
My custom firmware on top of the 1.1.1 sdk also does not exchange configs.

Can anyone articulate the value of exchanging the data?

The twr script generated config data has both the source and destination address(real or fake) and tte data flows in the ranging ntf .

2

Hi @rexxdad,

The configuration exchange isn’t required for ranging itself. It’s primarily a mechanism for two devices to agree on a common FiRa session configuration (addresses, session parameters, security settings, roles, etc.).

In the SDK TWR examples, both sides are already provisioned with matching parameters, so no additional exchange is needed. Solutions such as QANI and Android UWB typically exchange configuration data out-of-band because the peers need a way to establish and synchronize the session before UWB ranging can start.

Once both devices have matching configuration, ranging proceeds the same way regardless of how that configuration was obtained.

The SDK examples assume that both devices have already been configured consistently. Configuration exchange becomes useful when the peers do not have pre-arranged session parameters and need to establish them dynamically.

3

thanks, I understand..

I have two devices with OOB communications,
and works with twr script generated contents

but now I have phone devices with a different config layout, connecting to my controlee device

both phone interfaces receive the controlee config and merge it somehow with the local and then start ranging with that merged config.. but currently the controlee has the twr tagged layout, not fixed structure

does the controlee session handle really matter at the controller side?
on my controlee its always 1
and the controlee mac add address would be 1 except for one to many… which these devices don’t do well..
maybe they do matter in the one to many..

I have to add new interfaces for my OOB to handle those exchanges .. just checking the important content..

so I ‘think’ I would take the controller generated content and fixup the controlee generated content with the relevant settings..
on send, extract the pre-merged content from the controlee to send back (all built before ranging requested) (on iPhone it is sent in response to OOB init sent, on Android it is sent in response to OOB connect)

on my existing FW, it is created on command.. with parms to adjust those fields as required..
and I can tell by the OOB connector used.

this made me go look at the spec
which answers more of the questions

After a successful receipt and processing of the Accessory Configuration Data, the Apple device may
send the Apple Shareable Configuration Data message to the accessory.
The Apple Shareable Configuration Data message contains an AppleUWBConfigData field, as
described in reference [5]. The host processor on the accessory should provide the
AppleUWBConfigData field as-is to the UWB middleware. The UWB system should be configured and
ranging should be started on the accessory immediately following this message

this from the R5 spec just released for iOS27
sorry these turned into Apple dev login to view

v4 is here

I can’t provide the data exactly as provided, as I don’t have the middleware interface, but can fixup the twr generated content to match

on the DW3 1.1.1 SDK the libs/nig/Inc/niq.h contains the data structure definition for the Apple config data

also I see niq provides headers for the two functions..
niq_populate_accessory_uwb_config_data
niq_configure_and_start_uwb

4

Your other message response solidifies the result, thanks