Nordic Distance Measurement library: RTT sample rate

[J0sh1101]

Hey,

I used the nRF distance measurement library to measure long distances and managed to measure the distance to around 140 meters and it seemed to work quite well. The only thing I noticed is that the sampling rate is quite low.

I took the example of the nRF distance measurement and incremented a global counter every time the callback function data_ready() was called from the struct dm_cb (This function indicates that the dm library has some distance data.). A wrokerthread is executed every 900 ms to write this value to the console and reset the value. The counter value varies from 1 to 3. This means that the sampling time is between 300 and 900 ms, right?

Can this be improved?...

How about if I just use one initiator and one reflector per device instead of having one BLE device that supports both functions. Would that help?

If I reduce the advertising interval from (min-max)100 -150 ms to 30-60 ms, would this improve the sampling rate?

Could it be that the application slows down with the number of BLE devices, since it has to initiate more distance measurements? Can I create a whitelist to limit the interaction?

I don't understand why this is slow, since it basically just needs to do maybe a subtraction with the time it takes the refloctor to process, divide by two, and mutliplicate with a constant to get the distance. Correct? Or am I missing something.

Thanks for the help!!!

OS: Windows

SDK: 2.4.1

IDE: Visual Studio Code

Hardware: nRF52840 DK

[tesc]

Hi,

How about if I just use one initiator and one reflector per device instead of having one BLE device that supports both functions. Would that help?

It could help somewhat, yes, at least in theory, if you have a quicker way to synchronize when to do the distance measurement. But before you do, I recommend measuring how much time is spent in BLE advertising/scanning before initiating the distance measurement, as well as the time for the distance measurement itself (from initiation to you have a result.) That way you know how much time can theoretically be saved on the BLE side.

Please note however that for a successful distance measurement, you need one device in initiator mode and one device in reflector mode, at the same time. Putting the devices in those states prematurely may increase power consumption significantly compared to using BLE advertising/scanning for synchronizing when to do the measurement.

I don't understand why this is slow, since it basically just needs to do maybe a subtraction with the time it takes the refloctor to process, divide by two, and mutliplicate with a constant to get the distance. Correct? Or am I missing something.

Sending one message from one node to a different node and back, subtracting handling time and dividing by two, is a very simple way to do distance measurement. However it will often give false results due to effects such as e.g. multipath. One way to improve the result is to do several measurements and then do some data processing (ranging from simply discarding outliers to more advanced computations on the data set.)

Another way to improve the result, is to use other techniques as well, such as calculating distance based on received signal strength or looking at phase shifts over a range of frequencies.

Accurate distance measurement is a complex field, and so the Nordic Distance Measurement library combines several techniques for getting a good measurement reading. Different distance measurement techniques have different advantages and drawbacks, but by combining them it is possible to give good results in multiple environments and situations. Even when using just one technique, multiple readings are performed and the results are analyzed, in order to improve the quality and confidence of the measurement.

For a more in-depth understanding of distance measurement and the technology behind Nordic Distance Measurement library, I highly recommend the recording of our Measuring distance with the Nordic Distance Toolbox webinar.

Regards,
Terje

[J0sh1101]

tesc said:

Another way to improve the result, is to use other techniques as well, such as calculating distance based on received signal strength or looking at phase shifts over a range of frequencies.

Since we measure a distance of up to 100 meters, the only usable measurement technique is RTT.  The others are short distance measurement techniques. The signal strength is unreliable: only for short distance measurment and it is difficult to model the path loss factor.Or is it anything that may I do not know? The phase shifts over a range of frequencies is not recommended for long distances. 

tesc said:

For a more in-depth understanding of distance measurement and the technology behind Nordic Distance Measurement library, I highly recommend the recording of our Measuring distance with the Nordic Distance Toolbox webinar.

I will re-watch it again. Maybe I can get some new ideas. I like the idea to combine techniques to improve reliability. However, if one measuring technique proves ineffective, it's likely that the others may encounter similar challenges. For instance, adverse weather conditions or interference could potentially affect the performance of all these techniques.

I have another question, and I'm not sure if it's appropriate to ask here or if I should open a new ticket, but I'll go ahead and ask it anyway. In the example related to distance measurement from Nordic, I noticed that if a peer or device doesn't respond within a certain timeframe, it gets removed from the list.

Is it primarily to minimize communication overhead, or is there another purpose? Additionally, I'm wondering if there's a limit to how many devices can be connected before the application starts experiencing issues. Is there any information available on this? I've made some modifications by adding logs to the scan and advertisement callbacks, which introduced additional delays, and the application is not working anymore

Thank you for your time  and for the answers.

[tesc]

Hi,

I see there were still some unanswered questions here.

J0sh1101 said:

Or is it anything that may I do not know?

No, I think you are right there, that for 100 meters RTT would be the most reliable. At that range the signals would be weak, though, which may also factor in on why measurements takes so much time. (With higher packet loss, getting enough good samples also takes longer time.)

J0sh1101 said:

I noticed that if a peer or device doesn't respond within a certain timeframe, it gets removed from the list.

Is it primarily to minimize communication overhead, or is there another purpose?

That, as well as minimizing the overhead of keeping devices in the list that have gone offline or are otherwise out-of-range.

J0sh1101 said:

Additionally, I'm wondering if there's a limit to how many devices can be connected before the application starts experiencing issues. Is there any information available on this? I've made some modifications by adding logs to the scan and advertisement callbacks, which introduced additional delays, and the application is not working anymore

Timing is important for the distance measurement library to work, in the sense the distance measurement itself must be synchronized. By introducing delays you therefore run the risk of missing the synchronization and increasing the number of failed distance measurement attempts.

Deferred logging (CONFIG_LOG_MODE_DEFERRED) minimizes the overhead at the point of logging, deferring most of the logging operations to be handled later by the main thread.

Regards,
Terje

[J0sh1101]

Hello,

Thank you for the reply