Status of Nordic Distance Library after release of BT Channel Sounding

[mkopp]

Dear Nordic Support Team,

Could you please provide more information on the current status of the Nordic Distance Library (https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/nrf_dm/README.html#nrf-dm)?

It has been labeled experimental for the longest time and I have been eagerly waiting for an update, especially with the release of BT channel sounding. I was hoping that Nordic would continue to develop this library. However now it seems that its being left behind as new samples have been introduced already in NCS3.0.0 for the nrf54 series.

What about nrf52/53 series? I have implemented this library into my custom application. It works okayish with ifft almost always being the best approximation (high precision calculation keeps returning 0, have never gotten that to work...). I understand that channel sounding is not supported for nrf52 series but are there any plans to continue to develop the distance measurement library for nrf 52/53 series?

Let me know if you have any ideas concerning the high prec calc not working, let me know what you need me to send, thanks!

Best regards,

Mickael 

[mkopp]

Edvin said:

I read that it can also return NaN if the heap is too small

Hey, thank you so so much — I just got my first ever high precision distance measurement working!!

To answer your question: No, I’m not using the sample directly — I’ve integrated the nrf_dm library as a bare-metal implementation into our own project.

Your hint was spot on. The SDK we’re using had a conditional _sbrk() syscall implementation to enable malloc(), but until now it always returned an error. After adding the right defines, it's finally working as intended — and now nrf_dm_high_precision_calc can do its thing!

Do you happen to know how much heap memory that function typically needs?

I first tried with 8kB and it still failed, but 32kB did the trick. I added some debug logs to track sbrk() calls, and it looks like it’s using about 7.8kB total. Is there an internal number you go by, or should I just run it a few times and set my own margin?

Thanks again — really appreciate your help!

Best,
Mickael

[mkopp]

Actually 18,948 bytes from the limited testing this morning. Do you have an official number?

[PaKa]

It's dynamically allocated if I am not mistaken so will depend on input data, if it requires more than available to get a fix then you get NaN