we have deployed our system in test, and 1st test site (always isn’t it!) , cannot seem to get any ranging info from the CDK board. but only on iPhone 14 (pro)… the firmware on the CDK is V3.0 not 3.01
the App from the appstore works however.
we have an ESP32 co-located with the CDK board. the ESP32 contains our config info, and thru config processes, the ID returned on the BLE calls. I ported your sample app to work as a plugin in the app infrastructure (Ionic/Vue). and it has been quite reliable.
I had heard there were issues w iPhone 14 from another vendor… so I’m wondering if there were any changes to the config stream to setup the NI data flow. I did not check the source of the sample app in the second SDK release for this difference…
My iPhone App sends activity records to a local ELK stack search system , so I can see the activity.
the app found the ESP32, and the saved CDK id is correct… we can ble scan that much (for the Qorvo UUIDs),
but it never transitions to ranging.
the developers guide for 3.1.0 says
3 Important Notice for iPhone 14, Pro & Max
3.4 Convergence State
Once the UWB session has started,
the application <------ what application? mine sure doesn’t
will guide you through the process of achieving a converged state.
To verify the convergence value, you can use the following function implementation:
-------------------
func session(_ session: NISession, didUpdateAlgorithmConvergence convergence:␣
NIAlgorithmConvergence, for object: NINearbyObject?) {
// Test if NISession converged ----- how does one do THAT? and if not, THEN what???
}
-------------------
Following convergence, the didUpdate function of the NISession delegate will provide the following information:
• horizontalAngle4: The AoA azimuth in radians.
• verticalDirectionEstimate5: An enumerated value that estimates the vertical position of the nearby object,
which can be one of the following: ABOVE, BELOW, SAME, ABOVEORBELOW, or UNKNOWN.
func session(_ session: NISession, didUpdateAlgorithmConvergence convergence:␣ ˓→NIAlgorithmConvergence, for object: NINearbyObject?) {
// Test if NISession converged
}
oh by the way it says
The convergence is obtained using the iPhone’s sensors (mainly camera sensor).
oh, in my environment, the camera is not allowed to be used…
its in the sample app…-----------------------thank you
as a followon… is this ‘convergence’ by accessory device? I think so as its related to the nisession and this NearbyObject
if u turn away from the light, then u would lose convergence…for any devices in that area
the sample app only has a global flag
holy smokes! I got hold of an iphone 14.
ni doesn’t work in low light vs does work on iphone 13.
AND apple has changed the hashValue calc/data so it’s different on iphone 14…
I hope 15’s go back to the 11-13 way
the ‘persistent’ ID is different…
11/12/13 all the same, 14 different, same UWB board
62955885 219432155
25328878 178676619
this is the peripheral.hashValue… qorvo has no control over this, it is an apple provided value
oh joy
SOOOOO… I looked thru the apple sample NI app… it uses the device NAME as the unique ID… not the hashValue… I opened a ticket with Apple development, but I think that will be a deadend as they have marked hashValue as deprecated…
SO… I want to use a new BLE write characteristic on the CDK board to set a unique name to be used at advertise time. if not set use the hard coded name, the default behavior
I don’t see any of the BLE handling in the source. can someone point me to that?
| edit: found it
is there enough space in the NV ram? for a short value, (timestamp, ms) that gets converted to a
string and used like this, maybe an MD5 hash of the ts
“name”:“40:22:d8:3c:47:2a”
but it has to be saved and used persistently
hm… so looking at the code the ble ‘name’ has a value from the nrf chip
snprintf(advertising_name, sizeof(advertising_name), “%s (%08X)”, (char*)BoardName, (unsigned int)NRF_FICR->DEVICEADDR[0]); // <------
ble_init(advertising_name);
the number is the same on both iPhone 12 and 14
So, that deviceAddr is unqiue across all the nrf chips… so I can parse that… hashValue can still be the lookup key, but uniqueID is the deviceaddr value…