Scenario

Performance issue

We are using a Samsung S21 Ultra 5G. The phone is set up to range with two UWB sensors. Also, the phone acts as a controlee. We are able to get ranging results from both sensors with decent update rate. However, when one sensor is blocked, the blocked sensor no longer produce any ranging results which is expected, but the unblocked sensor also experience slower update rate (e.g., previously 4Hz, now 1Hz).

Tentative solution

We tried to time out the blocked sensor, and allow the unblocked sensor to produce ranging results with normal update rate (e.g., about 4 Hz). This turns out to be quite problematic due to a potential bug(or missing feature) described below. We tried to put ranging logic in one thread, separate threads, and even in multiple processes (by extending the Service class), none of them worked. At some point, restarted ranging sessions will stop responding or produce ranging results with much lower update rates. When we try our multiple process set up, if we only ranging with one sensor on a first process, we get ranging results from the sole sensor, but if we start ranging with a second sensor on a second process, the second process starts to report ranging results, but the first process stops reporting ranging results. We also noticed a ranging already started exception. We figured multi-process may not be supported.

Tests and Findings

When core uwb creates SessionScopes in core.uwb.impl.UwbManagerImpl.kt using method createGmsClientSessionScope, it will creates a uwbClient variable from gms.Nearby. When we use the phone to range with two UWB sensors, we will need to call this method twice, which causes two UwbClient instances get created.

If we follow normal workflow, we get ranging results through the callback in core.uwb.impl.UwbManagerImpl.kt, more specifically the onRangingResult result callback.

However, when we timeout one of the UWB sensors in testing because it is blocked (and hence stop producing ranging results and causes the other sensor to produce results with slower update rate), we invoked the uwbClient.stopRanging(callback: RangingSessionCallback) function. Things started to get messy from this point on. It seems like current core.uwb implementation can only reliably work with a single UwbClient. There are several scenarios that may happen:

• After we call stopRanging on the uwbClient for sensor 1, uwbClient for sensor 1 may be suspended (reported by onRangingSuspended in core.uwb.impl.UwbClientSessionScopeImpl.kt) and this is what we want!!!. In this situation, if we restart the ranging session for sensor 1 with a new uwbClient, we get ranging results with normal date rate (e.g., 4hz)
• After we call stopRanging on the uwbClient for sensor 1, uwbClient for sensor 2 may be suspended (which is wrong). When this happens, continue to call stopRanging on the uwbClient for sensor 1 makes no difference, the uwbClient for sensor 1 won't be suspended. Also, if we call stopRanging on the uwbClient for sensor 2, it also gives no response. This means uwbClient for sensor 1 is acting like a dangling object. No way to close it unless we close our app and reopen it, which is unfortunately not permitted in our experiment case. When this happens, we noticed two possible outcomes after restarting ranging sessions
  • Ranging with both sensors still work, but with much slower update rate (e.g., from 4Hz to 1Hz)
  • Ranging with both sensors does not work, and in fact, the two parties (phone and sensors) can't get ranging started, they may finish exchanging parameters through BLE just fine.

One additional finding we noticed is that the ranging suspended reason, though normally will be 4, but sometimes can be 1. Four means ranging stopped by peer, while one means wrong parameters. This may or may not be helpful.

Code changes we made in our testing

We disabled RxJava and Kotlin's Flow in core.uwb implementation, and tried with both release Alpha 07 and Alpha 05. The reason we disabled RxJava and Kotlin Flow is that we can call stopRanging on uwbClient instances when we want to and make sure RxJava and Kotlin Flow play no part in the issue we observed.

I hope the detailed writing provides enough details for you to debug.