I’m trying to upgrade a One-To-Many scenario where I have multiple DW3001CDK anchors, some running on Python scripts derived from Qorvo-Tools library (in particular run_fira_twr), set as initiators. They cannot interfere with each other for now, so they can operate independently.
I plan to use several DW3001CDK as tags, set as responders, up to 8 running concurrently, according to the FiRa stack.
I need to automate the UWB TWR setup process, such that, by relying on BLE in OoB:
- Each DW3001CDK tag uses its BLE to pair and exchange its MAC address, session ID, and UWB parameters with the DW3001CDK anchor;
- Once set, the anchor initiates the UWB TWR, I suppose exploiting UCI commands;
- The DWM3001CDK sends via BLE OoB additional information (suppose a battery status for simplicity) to the anchor, which simply prints both UWB and received BLE info.
The two counterparts need to know a priori the UWB parameters (dest MAC and device MAC) to start TWR.
To do so, considering the last DW3_QM33_SDK_1.1.1, I would need to understand:
- Can the QANI project on the firmware be customized to let DWM3001CDK communicate with each other OoB via BLE, and not with iOS?
- If so, can you provide a brief tutorial on how to do it?
- If not, and so if I need to customize the UCI firmware to perform this, which are the main QANI operations that need to be ported (like
niq_init, CreateQaniTask, ble_init)?
I’m struggling to understand how to change the firmware, so any help is mega appreciated.
QANI depends on some proprietary Apple code.
The device sends in its config on request, and the phone uses this to start its ranging activity
Some time later the Apple runtime calls back with the config the device should use, and it starts its side of the ranging session.
Then the ni framework calls back with the ranging data, distance and angles. The device is dumb., recreating the NI framework env would be challenging
But there is cli and uci that can talk between boards
Just no ble between them
I looked at a similar architecture for Android on top of uci, like QANI, but hit a roadblock as the uci implementation has attached to the UWB hardware and won’t give it up. QANI and uci both think in their design that they are the only app to use the UWB hardware
I spent most of last fall and this winter working on uci over ble. The memory in the 52833 is just too small for all that
The 52840 in the Murata Type2ab does have enough memory. But uci has multiple streams to input based on the parameters required.
This is my first Nordic dev experience and it’s quite a learning curve, and content to learn. Visual studio has been a lifesaver. And Segger’s Ozone source debugger.
Note for the Type2ab board you have to buy a separate segger interface adapter to flash the board and debug for each board involved in the interaction
BLE is interesting too. Scanning , advertising, connecting and reading and writing.
Luckily I had developed an iPhone app using ble to an esp32 so I had the concepts at least.
1 Like
Also the concept of anchor or rtls is different than what QANI provides. QANI is me to that thing not me in relation to 100 other things
In rtls you can imagine a plant floor and you want to know where the robot is. In the total space and it’s different for every anchor to every device at the same time.
The current QANI use of a ble connection makes it hard to have more than one connection at the device..it can be done, but it’s abnormal.
For rtls you want a connectionless design where the tag broadcasts and every anchor hears it and sends their data to a central server which does all the realtime calcs and can instruct the side processor in the tag where to move next.
QANI is guide me to that thing. Think of the last mile for apple findmy. You go to the room but can’t get closer cause gps accuracy isn’t enough. Today the device must
Make a sound and human uses that to discern where it is over repeating cycles
UWB can direct you exactly there.