I’m trying to test the DWM3000EVB with Apple’s Implementing Spatial Interactions with Third-Party Accessories sample app, using nordics nrf52833dk.
The uwb session starts normally, I get nearby objects update perfectly. But when moving around and the device gets out of range and UWB updates stop.
Moving back in range should get the device reconnected and uwb updates resumed. This happens sometimes, but most of the time it doesn’t until the device is switched off then on, even a soft reset is not enough!
Our current app has an issue (already fixed for future releases) that when either distance or direction fails, the entire info is not updated and you see the label and arrow frozen.
Usually when the app stops respond is because the directions are too close to ±90 degrees, it seems an Apple NI API way to avoid inaccurate measures that normally happen for high and low angles. If you check the Dev Kit log (using J-Link RTT-Viewer) you will see that even when the data is not updated in the iOS App the ranging rounds are successfully completed on the Dev Kit side (actually on both sides, but NI API doesn’t show the result).
Regarding the need to reset the app when disconnected, I will try to reproduce it here.
I’m using the Apple’s Implementing Spatial Interactions with Third-Party Accessories sample app, and when the app stops receiving updates, the J-Link RTT-Viewer updates stop too:
If you are building the app yourself, you can try to change the code inside “func session” for didUpdate.
Now you have something like:
guard let accessory = nearbyObjects.first else { return }
guard let distance = accessory.distance else { return }
guard let direction = accessory.direction else { return }
As you see, if the direction fails (Apple NI API returns “NINearbyObjectDirectionNotAvailable”) will return before updating the data. If you change it to something like this:
if let newDirection = accessory.direction {
// set current value
direction = newDirection
oldDirection = direction
}
else {
// set the previous value
direction = oldDirection
}
When direction fails you will have the updated distance and keep the previous direction on screen, when you have a new valid update for directions it will be shown.
I already did that. but the problem is that the session is invalidated, and a new session (NISession) can’t establish a new UWB communication, it seems that the software on the micro-controller side got stuck in the previous session and does not allow for a new one. When I switch the nRF52833DK power off then back on, the app can establish a new UWB connection successfully ( without restarting the iOS app)
Your Dev Ki is resetting right when sending the “Accessory Configuration Data”. Can you check your power supply and the “nRF power source” position? Once I had this problem with a board and I had to replace it.
Hi @iMan, sorry for the late reply, I had problems to access the forum last Friday.
I did some tests moving around like you, I used a DWM3001-CDK, to check the status on the LEDs, I could see the bad ranging rounds happening and the connection loss.
Every time I approached the iPhone again, if the session didn’t resume I could restart it by closing the previous session (Stop Session button), only once the button was not working which I assume was a BLE connection failure, so I restarted the board and the session could run.
At no time did I have to close the app or restart the iPhone.
I’m going to test again using the nRF-DK + DW3000EVB.
I did one more thing, I intentionally invalidated the NISession after getting some distance and direction values, then trying to connect again failed in the same way, no connection, I had to turn off then on the board to get a new connection, I did NOT have to restart the app.
This makes it obvious that the problem is on the microcontroller software side, when the NISession is invalidated, the microcontroller seems not aware of that and refuses new connection thinking that the previous connection is still alive.
Hi @iMan, just took some time to look deep at this but I still couldn’t reproduce the issue.
First, with the iPhone, I moved away from the device until it stopped showing updates (Connection State was still “Connected”). As I approached the device, updates resumed.
Second, with the iPhone, I moved away from the device until the Connection State changed to “Not Connected”. When I approached the device, it connected again, but updates did not resume immediately, after a few seconds the NI Session was retrieved (it happens before time-out) and updates resumed.
Third, with the iPhone, I moved away from the device until the connection state changed to “Not Connected” and waited for the message “Session with ‘accessory’ timed out”. When I approached the device it connected again but updates did not resume. As the “Run Session” button became available I clicked on it and a new session started.
At no time I had to close the app or restart the iPhone and/or Qorvo device.
Tested with a DWM3001CDK (nRF52833) and with an nRF52840-DK + DWM3000EVB with both versions 1.0 and 1.0.1
Do you have a step by step how to reproduce the problem?
That makes sense, but I’m sticking to your original message, trying to reproduce the problem in regular use.
What I understood so far is, that the Qorvo device is still ranging (UWB) when the iPhone’s NI session has stopped (or invalidated like your test), you can’t resume because the app is back to an initial state and the device is trying to range with a NI session that’s not active anymore.
There are two ways to revert the Qorvo device status, send the “stop” command via BLE or disconnect the BLE. (three if you reset the board)
Probably adding a “Send Stop” button would help to recover, the Qorvo app changes the “Run Session” button to “Stop Session” which action is to send the “stop” command and this is the right way to interrupt a NI session.
But I still don’t know what is invalidating the NI session on your side, or how to reproduce it.
I tried sending the stop command, it didn’t work. I suggested manually invalidating the session because its easily reproducible and then, its possible to debug the software on the device side.
One more thing, I don’t think that the issue is a bluetooth communication issue, its likely within the Qorvo software itself