Guidance needed UWB

[rexxdad]

over the last year I have been working on our product design and implementation,
using the DW3000 on the CDK board to provide distance and AoA to our iPhone app.

this works great, great for Iphone 11-13… but starting with 14, the lack of the second antenna wipes out the AoA info, and we only get distance… … angle is the heart of our design

Apples ‘solution’ is to enable camera assist…
BUT

1. our user is blind… so using camera to scan for something is not possible
2. camera cannot find our beacon (not line of sight very often, and blends in to background, by design)
3. camera assist doesn’t work in the dark… we have no control over the implementation locations lighting
4. camera assist pushes our UI (audio and low vision) to the background… which makes it impossible to control

all these work great on 11-13…

anyhow.,… this leads me to believe we need to make our own end user device to attach to a phone (case) and provide the info from the DW3000 based beacons we have built. (basically replicate the Apple Nearby interaction code)

we don’t have an electrical engineer on our startup team… and are having quite a hard time to get something built on the end beacon side. (my prototypes are all wire connected. )

we currently do not have any code that uses the CDK USB interface, and I would like to use some bluetooth type connection between this add on board and the phone. (which insulates us from cable types, phone types, etc)
I don’t know if I can have my own application code run on the dw3000 on top of the Fira stuff, or if I need ANOTHER processor on board to handle that.

our beacon box has an esp32 providing additional logic, via bluetooth, and I have build flash ota from our config app to update those with our new firmware… but not the cdk board… I can’t do that to the cdk board currently.

I don’t like the idea of my user having to flash the adapter… they are blind…

so, what would it take to breadboard this, driven off rechargable battery with custom firmware to provde the interaction with the fira code… (is that only via USB port on the cdk?)…

any guidance welcomed… and offline discussions possible.

[rexxdad]

so I have downloaded the lastest sdk and want to use the cli interface.
my cdk was previously flashed with the FREETOS version in the nearby sdk.

so, use jflashlite and flash (erase chip as it was previously flashed with different version) all ok…

now… how do I connect for cli interaction?
the USB cable connected to J9 gets me a ttyACM0 device, but it doesn’t respond on serial port
the USB cable in J20, does NOT provide a serial port…

the docs says J20 is USB/Serial connection.

on mac JFLASH lite said emulator downlevel, but upgrade failed… have to reboot to get back
on linux said emulator downlevel, but went thru, said flashed, but no progress bars.

J20 doesn’t respond on either system
red light is flashing when connected to j20, not flashing when connected to J9.
as expected.

what did I miss? this should have been the easiest part of the tasks.

[Fhilb]

Hello rexx,
it’s quite interesting to hear that the newer iPhones abandoned one of the antennas, I would have thought it would be more like the other way around but here we are

I can’t really comment on your reply as I never used the SDK but rather interacted with the DW3000 chip through an ESP32, but what I can comment on is your first leading question.

I’d personally not try to build an adapter board of some sort, as it is (as you already stated) quite unpractical for your users, especially blind ones.

What you could do instead would be to have a two antenna design on the beacon itself to basically get the angle of arrival the other way around and send it as data frames back to the iPhone (I suppose you actually do ranging and don’t only send blink messages from the beacon).
Of course you’d have some sort of compass module on the beacon to provide the right angle, as with rotating the beacon the AoA obviously changes as well, so you’d need to account for that. On the iPhone, you could use the integrated compass to get that data as well without the need of the adapter board.

This of course means that you’d have to redesign your chip but on the other hand means that you don’t have to mess with the clients device in any way.

If you want to setup some custom firmware, you might want to check out my GitHub project on the DW3000 to find some guidance on what to configure. It doesn’t have a second antenna but that’s something that could be added of course.

Let me know if you have any further questions

Kind regards
Fhilb

[rexxdad]

thx. the cdk already does the fira ranging application .

the app user wouldn’t know anything about our board, its just a phone case.

[rexxdad]

so I flashed the cdk binaries again, from a different zip file and they DO create a /dev/ttyACM? port on my linux box…

the sample uci app works… but I only get distance, not azimuth… between two cdk boards.

commandline

python uci_uart_fira_test.py -p /dev/ttyACM0 -d 90 -v -c 5  >controller.log

data from controller.log

<RANGE_DATA_NTF: SequenceNumber : 8 SessionID : 42 MACAddress : 1 Status : Ok Distance : 0 AoAAzimuth : 0.0 (0000), AoAAzimuthFOM : 0 AoAElevation : 0.0 (0000), AoAElevationFOM : 0 AoADestinationAzimuth : 0.0 (0000), AoADestinationAzimuthFOM : 0 AoADestinationElevation : 0.0 (0000)AoADestinationElevationFOM : 0>RSSI : -0.0
DEBUG:uci.core:recv: 6b0300212a0000000800000006030100000001000001000000020100000401000005000000
INFO:uci.core:notif: 11, 3: 2a0000000800000006030100000001000001000000020100000401000005000000
DEBUG:uci.core:recv: 62000038090000002a00000000c800000001000000000000000000000101000000070000000000000000000000000000000000000000000000000000
<RANGE_DATA_NTF: SequenceNumber : 9 SessionID : 42 MACAddress : 1 Status : Ok Distance : 7 AoAAzimuth : 0.0 (0000), AoAAzimuthFOM : 0 AoAElevation : 0.0 (0000), AoAElevationFOM : 0 AoADestinationAzimuth : 0.0 (0000), AoADestinationAzimuthFOM : 0 AoADestinationElevation : 0.0 (0000)AoADestinationElevationFOM : 0>RSSI : -0.0
DEBUG:uci.core:recv: 6b0300212a0000000900000006030100000001000001000000020100000401000005000000
INFO:uci.core:notif: 11, 3: 2a0000000900000006030100000001000001000000020100000401000005000000
DEBUG:uci.core:recv: 620000380a0000002a00000000c800000001000000000000000000000101000000040000000000000000000000000000000000000000000000000000
<RANGE_DATA_NTF: SequenceNumber : 10 SessionID : 42 MACAddress : 1 Status : Ok Distance : 4 AoAAzimuth : 0.0 (0000), AoAAzimuthFOM : 0 AoAElevation : 0.0 (0000), AoAElevationFOM : 0 AoADestinationAzimuth : 0.0 (0000), AoADestinationAzimuthFOM : 0 AoADestinationElevation : 0.0 (0000)AoADestinationElevationFOM : 0>RSSI : -0.0
DEBUG:uci.core:recv: 6b0300212a0000000a00000006030100000001000001000000020100000401000005000000
INFO:uci.core:notif: 11, 3: 2a0000000a00000006030100000001000001000000020100000401000005000000
DEBUG:uci.core:recv: 620000380b0000002a00000000c800000001000000000000000000000101000000070000000000000000000000000000000000000000000000000000
<RANGE_DATA_NTF: SequenceNumber : 11 SessionID : 42 MACAddress : 1 Status : Ok Distance : 7 AoAAzimuth : 0.0 (0000), AoAAzimuthFOM : 0 AoAElevation : 0.0 (0000), AoAElevationFOM : 0 AoADestinationAzimuth : 0.0 (0000), AoADestinationAzimuthFOM : 0 AoADestinationElevation : 0.0 (0000)AoADestinationElevationFOM : 0>RSSI : -0.0
DEBUG:uci.core:recv: 6b0300212a0000000b00000006030100000001000001000000020100000401000005000000
INFO:uci.core:notif: 11, 3: 2a0000000b00000006030100000001000001000000020100000401000005000000
DEBUG:uci.core:recv: 620000380c0000002a00000000c8000000010000000000000000000001010000000c0000000000000000000000000000000000000000000000000000
<RANGE_DATA_NTF: SequenceNumber : 12 SessionID : 42 MACAddress : 1 Status : Ok Distance : 12 AoAAzimuth : 0.0 (0000), AoAAzimuthFOM : 0 AoAElevation : 0.0 (0000), AoAElevationFOM : 0 AoADestinationAzimuth : 0.0 (0000), AoADestinationAzimuthFOM : 0 AoADestinationElevation : 0.0 (0000)AoADestinationElevationFOM : 0>RSSI : -0.0

i checked out the file dates for the uci scripting support in a bunch of different zip files checking for newer code maybe… but didn’t find any…

the doc says there should be angles too…

any help welcomed.

[rexxdad]

well, THAT was short lived…

Does DWM3001CDK supports angle of arrival?

Hello, I am using DWM3001CDK boards for distance measurement and angle of arrival calculation. I followed some steps in the developer guide provided in the documentation section to get my result. I used two boards one as an anchor and the other as a tag, for both the boards I dumped the hex file given in the guide folder named uci. Then run the Python scripts provided to make one an initiator and the other a responder, I think it has the algorithm for distance measurement and other things. Then …

[rexxdad]

So, followon guidance for development testing…

I think this said I need to use the

QM33120WDK1

as one side of the TWR to get AOA using a CDK on the other end.
this would be the same architecture as the iphone with 2 antennas doing TWR with the CDK (which works)

am I correct?
I want to do standard Fira ranging one to many 3220(controller) , Dual Antenna to 3110 (controllees/tag)

so the kit says daughter board with dual and single antenna, but it gives a wide range of chips…
do i select a daughterboard to get the chip I want?

dang this kit is expensive for us startups.

[rexxdad]

any feedback on my questions?

[alliv]

Decawave names
Dw3x20 chips are AoA
Dw3x10 chips are non-AoA
Dw31xx chips are WLCSP package
Dw32xx chips are QFN package

Dw3720 is AoA in WLCSP (this is analog of dw3120 with improvements, see datasheets)

Qorvo names
QM33120 is Aoa in WLCSP (analog of dw3720)
QM33110 is non-AoA in WLCSP
I am not aware of QFN devices.

[jamesbob1]

I am making an attachable tag to go on phone cases for about $20. I’d like to get it working on UWB phones as well. You had opened a conversation with me earlier and would love to discuss with you more. My application for phone uses the ranging only, I don’t need AoA, but I am using the DT-Tag listener TDoA hyperbolas and wanted to see if I can process that on the Qorvo separate tag.
Two approaches, two different data needs:

Approach 1 - phone-native. The phone listens one-way to my fixed,
transmit-only beacons and self-positions from the DL-TDoA timing. This
is now a platform feature: Android 17 Beta 2 added a FiRa 4.0 DL-TDoA
listener API (privacy-preserving - the device positions itself, the
anchors never see it), with an AOSP ranging sample to start from. For
basic hyperbola positioning the app gets the solve from the OS - I do
NOT need raw CIR / first-path / raw timestamps on this path. That shifts
the “phone UWB is closed” read, at least on Android. iOS still has no
public equivalent, so the dedicated tag stays in play there.

Approach 2 - separate QM35 listener tag. This is the only place the raw
data matters. A QM35-based tag (nRF52833 host driving the UWB IC over
SPI) doing finer synthetic-aperture processing across motion, which
needs the full raw FiRa data - CIR / accumulator, first-path index,
per-anchor timing, RSSI. It talks to the phone over BLE and the heavy
processing lives off-phone. So my earlier “I need the raw timing/CIR”
ask was only ever about this tag, not the phone path - sorry for
muddying it.

The one thing common to both is the anchor side: I need fixed,
transmit-only DT-Anchors that an Android 17 FiRa 4.0 listener can
actually lock onto - standards-compliant DTMs plus inter-anchor sync.

Where your experience would really help:

1. Anchor sync - for fixed transmit-only DT-Anchors, did you build the
   anchor firmware + inter-anchor sync yourself, get it under NDA, or
   lean on a partner stack? (Pinpoint’s SATlets self-sync over the air,
   which is why I keep eyeing them.) Feels like the gating piece for the
   phone path.
2. Raw CIR off the chip - were you able to pull raw CIR / accumulator +
   first-path index off the DW3110 (or QM35) in a passive RX mode from
   the nRF host? That’s the single thing Approach 2 lives on.
3. Have you looked at the Android 17 Beta 2 DL-TDoA API / AOSP sample
   yet? Curious whether it moots the adapter board for Android users.

Glad to take it offline.

Blessings,
Bob

[rexxdad]

Interesting.. Android 17 beta 2

in my solution, I cannot deploy anchors or other infrastructure. so the phone has to do everything

where the phone IS in the physical space is not important..
the angle and distance to a selected target are.. my targets are stationary, only the phone moves

sorry, I cannot answer your other questions