nRF54L15 Channel Sounding test

[wjw2025]

*** Booting nRF Connect SDK v3.1.1-e2a97fe2578a ***
*** Using Zephyr OS v4.1.99-ff8f0c579eeb ***

Hi,

   I purchased several nrf54L15 development boards and am preparing to conduct the Channel Sounding test. 

   I used two development boards. One burned the Channel Sounding Initiator Sample, and the other burned the Channel Sounding Reflector Sample, and then conducted the Channel Sounding test.  The actual test shows that the distance measurement effect is not good. Could it be that I operated something wrong somewhere?  Could you please give me some guidance? 

The two modules are approximately 6 meters apart. Below is the serial port output of the Initiator.

[10:55:33.053]收←◆I: Dropped subevent results. Waiting for ranging data from peer.

[10:55:33.731]收←◆I: Distance estimates on antenna path 0: ifft: nan, phase_slope: 12.207678, rtt: 17.174965
I: Sleeping for a few seconds...
I: Dropped subevent results. Waiting for ranging data from peer.

[10:55:33.970]收←◆I: Ranging data dropped as peer ranging counter doesn't match local ranging data counter. (peer: 58, local: 57)

[10:55:34.553]收←◆I: Dropped subevent results. Waiting for ranging data from peer.

[10:55:34.911]收←◆I: Ranging data dropped as peer ranging counter doesn't match local ranging data counter. (peer: 61, local: 62)
E: Tried to parse empty step data.

[10:55:35.803]收←◆I: Dropped subevent results. Waiting for ranging data from peer.

[10:55:36.113]收←◆I: Ranging data dropped as peer ranging counter doesn't match local ranging data counter. (peer: 66, local: 67)
W: Mismatch of local and peer step mode 2 != 1

[10:55:38.052]收←◆I: Dropped subevent results. Waiting for ranging data from peer.

[10:55:38.303]收←◆I: Dropped subevent results. Waiting for ranging data from peer.

[10:55:38.465]收←◆I: Ranging data dropped as peer ranging counter doesn't match local ranging data counter. (peer: 75, local: 74)

[10:55:38.743]收←◆I: Distance estimates on antenna path 0: ifft: nan, phase_slope: 12.207678, rtt: 17.174965
I: Sleeping for a few seconds...

[10:55:40.053]收←◆I: Dropped subevent results. Waiting for ranging data from peer.

[10:55:40.318]收←◆I: Ranging data dropped as peer ranging counter doesn't match local ranging data counter. (peer: 83, local: 84)

[10:55:40.517]收←◆W: Mismatch of local and peer step mode 2 != 1

[10:55:40.806]收←◆E: Tried to parse empty step data.

[10:55:41.307]收←◆E: Tried to parse empty step data.

[10:55:42.053]收←◆I: Dropped subevent results. Waiting for ranging data from peer.

[10:55:42.303]收←◆I: Dropped subevent results. Waiting for ranging data from peer.

[10:55:42.659]收←◆I: Ranging data dropped as peer ranging counter doesn't match local ranging data counter. (peer: 91, local: 93)

[10:55:43.753]收←◆I: Distance estimates on antenna path 0: ifft: nan, phase_slope: 12.207678, rtt: 17.174965
I: Sleeping for a few seconds...
I: Dropped subevent results. Waiting for ranging data from peer.

[Elfving]

Hi,

I am a bit uncertain about some things, like this:

[10:55:40.517]收←◆W: Mismatch of local and peer step mode 2 != 1

Did you use the samples from the nRF repo? this and this?

ifft: nan,

Looks like the quality is too bad for it to give an output here, is this a particularly rf-noisy area? I think changing the threshold for the quality needed for an output there is something that can be changed in the code though.

Though keep in mind that CS isn't UWB; the best you can expect is ±0.5m. Differentiating between ±0.5m would be impossible/hard.

Secondly, it is tempting to simply say that you should disregard anything but the IFFT measurements from the sample, as IFFT might be the most developed algorithm we have there, but the truth is rather that all of these metrics work best in different situations. RSSI is okay in short range for instance, and RTT is best for very long ranges (and I wonder if the phase slope might get you a max range, but don't quote me on that). This old webinar (which is meant to describe how our old "Distance Toolbox" worked, but the tech is almost the same) goes a bit further into the details of what separates these measurements. 

Most importantly: if you really want a good accuracy for your product, what you would typically do is to buy a third party algorithm that gets you a better accuracy than what our free code does. I assume the better algorithms combine all of these metrics in some fancy way. If you contact your local regional sales manager I bet he would be able to put you in contact with someone selling third party CS algorithms.

 

Regards and happy holidays,

Elfving

[wjw2025]

Hi,

Booting nRF Connect SDK v3.1.1-e2a97fe2578a
Using Zephyr OS v4.1.99-ff8f0c579eeb

I'm currently using this version without any modifications. I directly compiled and downloaded it to the development board through vscode. Now I want to use the development board for verification and then develop and apply it to my own products. 

thank you.

[Elfving]

I dont think that bootbanner necessarily implies any of the two. Please have a look at what sample you used. Is it from the nRF repo?

[wjw0]

I updated to the latest sdk3.2.1, but the test results were still not good.

I used the official latest test demo, and the test results were very unsatisfactory. I don't know if it's a problem with my testing method or something else. I hope to get your help .

I used two development boards, one to download the initiator and the other to download the reflector. Then, the two boards were placed approximately 6 meters apart. The serial port log of the initiator is as follows: 

I think even if it's a test routine, the effect shouldn't be so bad. 

[11:07:12.922]收←◆Estimated distance to reflector:
- Round-Trip Timing method: 28.480282 meters (derived from 5 samples)
- Phase-Based Ranging method: 24.135538 meters (derived from 36 samples)
[11:07:18.123]收←◆Estimated distance to reflector:
- Round-Trip Timing method: 34.925819 meters (derived from 5 samples)
- Phase-Based Ranging method: 14.190191 meters (derived from 36 samples)
[11:07:22.524]收←◆Estimated distance to reflector:
- Round-Trip Timing method: 23.133982 meters (derived from 6 samples)
- Phase-Based Ranging method: 17.695242 meters (derived from 36 samples)
[11:07:27.924]收←◆Estimated distance to reflector:
- Round-Trip Timing method: 23.358829 meters (derived from 6 samples)
- Phase-Based Ranging method: 23.644922 meters (derived from 36 samples)
[11:07:32.523]收←◆Estimated distance to reflector:
- Round-Trip Timing method: 25.167574 meters (derived from 5 samples)
- Phase-Based Ranging method: 14.368811 meters (derived from 36 samples)
[11:07:37.573]收←◆Estimated distance to reflector:
- Round-Trip Timing method: 30.518871 meters (derived from 5 samples)
- Phase-Based Ranging method: 23.053284 meters (derived from 36 samples)

[Elfving]

CS doesn't perform as well as UWB, but I agree that it should do better than this. It can take some time before it settles to a certain range, but I am not getting the impression you've observed this either.

Whether it was from the zephyr repo or the nRF one is what I am after.

We provide more support for the nRF one, and that is the one we've made ourselves. Channel sounding is somewhat new as well, so it might be that the zephyr one does perform differently. Though with that said: I wouldn't expect either of the two to perform this bad. You can also check what the default name of the sample is. That should tell me all I need to know.

Regards,

Elfving