UCI ranging messages

Wireless Connectivity Ultra-Wideband
1

I am adding a new transport to the SDK 1.1.1 UCI on Murata Type2AB.

all works great, start up and shutdown, ranging on the controlee reports the 0x62 Ranging NTF’s
(which means the controller side is sending some signal to be processed at the controlee, and I get good distance and angle values.)

however, on the controller side, I do NOT get the 0x62 ranging NTF’s reported in debug logging.
the app setup string is identical to the one produced by the python app, and then status NTFS report ready and active, same as the python app..

but nothing.. is there a state where TWR does only one way?
the only functional mod is to take the input from a different buffer and call out from the reporter for handling the Ranging reports..

any ideas where else to look? I’ve added debug in all the places to look, the transport is attached, then backends are open,

the code is conditional compile controller vs controlee, but only in handling the appropriate buffer mechanisms. I have intentionally not modified any of the UCI.. i modified controlTask to get the data from a different buffer..

my generated setup config string and the python script version below

21.03.00.6A.01.00.00.00.1B.00.01.01.11.01.01.03.01.00.01.01.02.06.02.00.00.04.01.09.22.01.01.02.01.00.12.01.03.2E.01.0B.27.02.08.07.28.06.01.02.03.04.05.06.0D.01.01.2B.08.00.00.00.00.00.00.00.00.14.01.0A.15.01.02.08.02.60.09.09.04.C8.00.00.00.1B.01.19.32.02.00.00.2C.01.00.13.01.00.2D.01.00.05.01.01.07.02.01.00.24.01.00.35.01.01
21.03.00.6a.02.00.00.00.1b.00.01.01.11.01.01.03.01.00.01.01.02.06.02.00.00.04.01.09.22.01.01.02.01.00.12.01.03.2e.01.0b.27.02.08.07.28.06.01.02.03.04.05.06.0d.01.01.2b.08.00.00.00.00.00.00.00.00.14.01.0a.15.01.02.08.02.60.09.09.04.c8.00.00.00.1b.01.19.32.02.00.00.2c.01.00.13.01.00.2d.01.00.05.01.01.07.02.01.00.24.01.00.35.01.01

only thing different is the case of the hex digits, also the same on the controlee side..which works.

I see the diff is 6a.01, vs 6a.02

I think that is the session handle

2

Anybody have any ideas why controller side might not notify Ranging NTFs while saying active?
(and controlee side happily reporting NTFs of the session.. )

If I swap hardware ends the controller side fails..

so this is a software problem. not hardware.

I retested with the as shipped binary, and get ranging ntfs.
added some debug and get ranging ntfs
my version doesn’t.

only the ranging NTFs don’t come thru
all the other status and command responses come thru fine.

3

Hi,

Think of the diff: this code is working, but when I’ve added something, it don’t.

What about “ added some debug” ? I.e. when you adding some debug especially if you did it in unbuffered way (e.g. direct print over uart), these debugs may take significant time.
So if you added those into time-critical sections, they could break the timings resulted in no reception of the RRRM message from the responder…

Take your time to understand

4

thanks.. I’m a month into this specific problem. I am aware of how to debug a multi-tasking system, and the potential issues.

I am not using the USB port. except for power.

all debugging is into the Segger RTT in memory buffer.

the controlee side works as expected. the controller side doesn’t. using the same firmware infrastructure. keeping as close to the existing UCI processing design as possible for those very timing issues.

stuff a message in a buffer and put on the queue, just like USB version. stock UCI code handles it all from there. code is waiting for the response. which comes back async thru the callback

there is nothing going on at the time. started ranging, was acknowledged as active by UWB subsystem. then nothing.

debugging with Ozone.

both the ranging startup and shutdown notifications occur as expected and match the USB version.

up to the actual ranging messages missing from the controller side.

the transport only provides one callback address for responses.

I placed debugging as close to the front of the callback to verify activity, but nothing other than the status messages for state changes.

if I got a fatal error, or ANY error, I could work on that.

5

found it at last!!!..
had to add the FreeRTOS heap and stack overflow hooks..

the ranging task tried to allocate heap memory after start notification, but it failed.
and didn’t report the failure ( I consider this a bug )

fixed heap size and now get ranging reports..

6

It would be great if you could supply a patch file or a ref such others could benefit from your kindness.

7

I’m not part of the Qorvo dev team. So I don’t have any way to create an issue to ref.

It’s always possible to get a failure from dynamic memory allocation. The system didn’t crash, but the function didn’t work. But nobody knew.

Not many will be trying to do what I am.