Concerns about Distance Measurement library

[paul]

Hi Nordic,

I am working on code which utilizes the DM library on many devices in a room. Can you please help with a few questions?

1. Some devices are always initiators, while others are always reflectors. Devices never switch roles like the DM example does. Is this ok, or is there some benefit to exercising both roles?
2. I use a different sync mechanism than the DM example does. How should I tune the initiator and reflector delay (CONFIG_DM_INITIATOR_DELAY_US and CONFIG_DM_REFLECTOR_DELAY_US)? Trial and error?
3. In the dm_request struct, how best to use the fields bt_addr and access_address? I can fill bt_addr with a nonsense value and it still works (at least on the initiator). But access_address seems to need a match. 
4. Most importantly, the performance is not great. When I place devices 1m apart, DM library reports 1.5m to 2m distance using MPCD. Quality is DM_QUALITY_OK. I was expecting better accuracy based on the webinar. How can I improve it?

thanks,

Paul

[Elfving]

Hello again,

Some devices are always initiators, while others are always reflectors. Devices never switch roles like the DM example does. Is this ok, or is there some benefit to exercising both roles?

This is ok.

I use a different sync mechanism than the DM example does. How should I tune the initiator and reflector delay (CONFIG_DM_INITIATOR_DELAY_US and CONFIG_DM_REFLECTOR_DELAY_US)? Trial and error?

The only way there is through trial and error unfortunately. 

In the dm_request struct, how best to use the fields bt_addr and access_address? I can fill bt_addr with a nonsense value and it still works (at least on the initiator). But access_address seems to need a match. 

I believe this should be documented somewhere. Might be that it is just used for is_request_exist, but I will have to get back to you on that.

though I wouldnt say that what the demo does is what is recommended. We just picked a value that fit our use case. 

Most importantly, the performance is not great. When I place devices 1m apart, DM library reports 1.5m to 2m distance using MPCD. Quality is DM_QUALITY_OK. I was expecting better accuracy based on the webinar. How can I improve it?

I see. First of all, the test presented in the webinar was done in rather ideal conditions, so it might be hard to get the exact same results.

Was the estimation method you used also considered "best" among the ones MCPD gave you? MCPD gives you multiple after all, some (like RSSI) will most often perform rather bad no matter what. I believe the webinar stated very different results depending on what method was used, a test using IFFT (with a median 3 filter) should get you a standard deviation of 80cm, which is rather close to what you've reported. 

I just tried it myself and got this. Though it does vary a lot.

 

In this example, IFFT performs best. If you want it, or any of the methods to perform better you could add filtering (eg. median3, which is what we've typically done).

Though if you want a higher precision than this I would recommend going for the High Precision option, our sample doesn't have this implemented by default though, unfortunately.

Regards,

Elfving

[paul]

Thanks for the details, though I can't see the image you posted.

Some follow ups:

• In most cases, the dm_request does not result in a callback with a dm_result. I suspect this indicates a sync issue. Is there a way to make the DM attempt the procedure for longer to account for an inexact start delay? 
• Any other recommendations to improve the number of dm_results?
• I've read the docs several times and browsed the code. I'm still not quite sure how bt_addr and access_address are intended to be used. If you find any additional details, it would help.

thanks,

Paul

[Elfving]

Hi again,

I've had a talk with the R&D team responsible.

It is possible that dm_request does not result in a dm_result callback. The cause may be:

• Synchronization inaccuracy. If the nrf_dm_proc_execute function returns a status other than NRF_DM_STATUS_SUCCESS, the callback will not be called.
• Too many requests. There must be a gap between measurement windows (timeslots), defined by DM_MIN_TIME_BETWEEN_TIMESLOTS_US
• Too many devices. For example, if there will be 1 advertiser and 2 scanners, a specific measurement at a given time will make between the two.

To adjust the synchronization, you can use the delay and extend the length of the measurement window. Recently was added to the dm structure parameter https://github.com/nrfconnect/sdk-nrf/blob/main/include/dm.h#L143.

You can see what the synchronization looks like by connecting a logic state analyzer to the gpio. https://github.com/nrfconnect/sdk-nrf/blob/main/subsys/dm/Kconfig#L89-L103. In the sample CONFIG_DM_GPIO_DEBUG=y is enabled.

bt_addr is used to distinguish devices. This way the application knows that a given measurement result refers to a specific device.

access_address now rng_seed see: https://github.com/nrfconnect/sdk-nrf/pull/9254  is used by nrf_lib_dm to generate the hopping sequence.

Regards,

Elfving