DWM3001CDK Background Mode Ranging Nearby Interaction

Hello, I saw that Apple recently released support for background mode ranging with third-party anchors. They state that a new GATT bluetooth service needs to be implemented to transfer the accessory configuration. I’ve been working with the DWM 3001CDK and was wondering if it is possible to range with multiple (4-5) Qorvo anchors in background mode.


1 Like

Hi rpraka,

I recently purchased a DWM3001CDK and want to use the new NI background mode as specified by Apple in the NI Protocol Spec R2 (iOS 16) section 4. The GATT service referenced is “Nearby Interaction Service = 48fe3e40-0817-4bb2-8633-3073689c2dba”

Can you provide the steps I need to flash the board with this new GATT service? Any help is appreciated.

Hi bmalbuck,

I personally have not gotten around to writing the background mode into the DWM3001CDK’s firmware. My primary issue was the restriction of advertising only a single BLE service at a time. This would require merging the new background mode GATT and the current code relying on the advertising protocol for foreground mode. You should be able to find more docs and samples about writing the relevant BLE code on NordicDevZone forums. Please let me know if you figure it out, I too have been wanting to implement this for a while. Thanks!

Thanks for the response, @rpraka.

I’m new to BLE firmware development. I’ll need to look at a Nordic nRF tutorial on how to create a service with characteristic and add it to the ble.c array of services. Reading Apple NI sec R2 section 4, sounds like a single primary GATT service with one read only characteristic for Accessory Configuration Data (UWB).

Any tips, pointers, links to help articles would be much appreciated.

@bmalbuck did you make any progress? Thanks!

Inside the “Nearby-Interaction-Accessory-Protocol-Specification-Release-R2.pdf” 4.1, there is a statement says “The Nearby Interaction service is not discoverable by iOS apps directly. It is intended to be used by the Apple device and its subsystems.”, does this mean it only works on Apple devices not other hardwares right now?

@Kai17 I made some progress Adding Apple Nearby Interaction Service per the spec section 4. However, I have yet to get it to work on dev board. The problem I faced was advertising in GATT service due to the 31-bit limit on adv packet. Documents suggest using the scan response to add the new service and characteristic. When I did this the other primary service (NUS) needed to communicate UWB configuration (tx/rx) over UART is no longer being recognized during BLE scans. I’d be happy to share the source changes if you have any ideas.

So yeah, Apple NIS is not suppose to be discoverable by your (3rd party) apps. It is used internally in Core Bluetooth framework to establish sessions and exchange data even when your app is in the background or suspended - Core Bluetooth will wake the app to establish session. I suppose it can be implemented on other platforms with a bit of work but this is core to Apple as part of their U1 compatibility MiFi program - so yes very specific for Apple devices using the U1 chip.

Yeah, after quite intensive work I have managed to make the background mode work. Just follow the steps that the WWDC2022 Nearby Interaction video explained. You have to implement the new NI service as well as the characteristic defined in Chapter 4 of the NI protocol spec R2. Your mobile running iOS16 won’t find the service but one running lower iOS version can, you can check from there. In my case I used an iPhone XR. In summary all you need to do is

  1. Implement the new NI service and characteristic

  2. Trigger Pairing. By default, the BLE does not require pair. But when you increase the NUS RX characteristc security level to for SEC_OPEN to SEC_JUSTWORKS, as simply read for the NUS RX characteristic will trigger a pairing. The peer id needs to be saved for the NINearbyAccessoryConfiguration call in IOS16 to use.

  3. When you send the Accessory Configuration Message form FW to mobile App, you also set the value for the newly created characteristic of the NI service, which later will be used by iOS NI session to double check, although this is not under you App’s control. If you don’t do this, the NI accessory configuration data validation will fail. The most tricky thing is that when you set the value, you needs to skip the message type which is the first byte, you only set the payload. So instead of 36 bytes of the conf message you set 35 bytes payload (this has blocked me for a few day!!! almost drove me crazy)

  4. Signing and capabilities setting as required.

In summary, you needs to be familiar with the bluetooth code in Firmware side and the Xcode side of code in the same time, plus extremely careful, otherwise, you have to wait until Qorvo ro Apple released the new NI package.

Unfortunately, I not able to share my code according to my company policy but as long as you are done with above 4 point, it should be working.

Hi @Kai17, I’m trying to reproduce that, so added pairing with basic encryption and new service, but it fails quite early on iOS side with NIERROR_SESSION_FAILED_DESCRIPTION error. I double checked and old fashioned iOS call NINearbyAccessoryConfiguration(data: data) is still succesfull, but new approach fails as described. Any ideas what can be wrong?

Hi @irgu88 !
Your device is already paired, right?

This error seems like a bad configuration.
Can you share your code where you set the configuration variable and then start the NI Session?

Kind regards!

Hi @Kai17 thank you for the sharing – I have managed to make the accessory work with NINearbyAccessoryConfiguration(accessoryData: bluetoothPeerIdentifier:) for background execution.

But, when will the “background mode” start? Is it when the app is minimized (we swipe up the app to background)?

According to the Apple WWDC22: “When your application is in the background, the NISession will continue to run and will not be suspended, so Ultra Wideband measurements are available on the accessory.”

I checked the log of the accessory (using RTT Viewer), the UWB stops when the app is minimized.

Hi @Kai17 ,

Thank you for this detailed reply.

Could you expand a little on point 3 please, specifically this:

you also set the value for the newly created characteristic of the NI service

Am I understanding correctly that this means I have to set it for both the app’s own Accessory Configuration Data as well as Apple’s one (95e8d9d5-d8ef-4721-9a4e-807375f53328), and that for the second one, the message should not have the messageID?

Second question, and this is a bit cheeky of me so please feel free to only respond to the first question, which of the examples from this repository would be best to use as a starting point to implement Nearby Interaction with Apple devices? I am using Makerfab’s ESP32 and their library is rather incomplete in respect to fira specs and interaction with the U1.

So far, I have setup the interaction between the app and the device but am not getting anywhere in respect to the UWB session. I know that my UWBConfigData is incorrect and struggling to understand how to properly implement this aspect. Understanding which example to use would help me get further.

Thank you in advance.

the V3 SDK for DW3000 provides a sample IOS app that scans for both UUID (foreground and background) and the firmware says it supports background too…

so I haven’t tried background, as we don’t use it.