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 

[Edvin]

Hello Mickael,

The Nordic Distance Library is supporting the nRF52 and nRF53 series, and will be so going forward as these devices will not support Channel Sounding. The code used is still marked as experimental, but this is only as it will allow us to change the APIs if needed. The quality is the same as for non-experimental code. We do not have any plans to depricate this today, but for the time being, we are not adding any new features either. 

The nRF54 Series will be the supported devices for Channel Sounding, and we are adding features here. There are areas where the Nordic Distance Toolbox have advantages over Channel Sounding, and vice versa, so we will keep both going forward.

Best regards,

Edvin

[mkopp]

Hi Edvin,

Thank you for your response and the info!

Did you see my comment about the high precision calculation? Do you have any ideas?

Best,

Mickael

[Edvin]

The High Precision algorithm returns NaN if the dataset is too poor to give a good estimate. Are you sure it reports "0", and not "NaN"?

BR,
Edvin

[mkopp]

Hi Edvin,

Yes you are right, it returns "NaN". The float is multiplied by 100 (to get cm) and then cast to uint16_t, which results in 0.

From a different post on devZone, I read the following:

nrf_dm_high_precision_calc can sometimes return NaN when it is not able to do an estimation with the measurements provided. The algorithm uses these tone_sinr_indicators to determine the quality of collected IQ measurements. If multiple of the tones are of quality worse than medium then the nrf_dm_high_precision_calc will likely return NaN.

https://devzone.nordicsemi.com/f/nordic-q-a/110747/using-high-precision-measurement-in-nordic-distance-toolbox/481581

However I print all the sinr_indicators before the high_prec calculation and they are all NRF_DM_SINR_INDICATOR_HIGH. 

I originally accepted that high precision does not work last year but now I want to see if I can get it to work after all. Thank you for your help!

Best,

Mickael

[Edvin]

Is this the unmodified sample, or did you add the distance measurement library to another sample?

I read that it can also return NaN if the heap is too small, but I have not encountered it yet. Is it possible for me to reproduce what you are seeing using a couple of nRF52840 DKs?

Best regards,

Edvin

[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