Longer range distance measurement synchronisation.

[Jason]

NRF52833 with NCS 2.4.0

I've added basic Distance Measurement support by adapting the nrf_dm example, but I'd like to get rid of the scanning and I also want to extend the range to a reliable 100ft (33m).

I found the RTT (round trip time) option which looks useful. My distance measurement doesn't need to be precise. But I would like to find a more long distance communication method to to set up the DM synchronisation.

My product currently uses periodic adverts with CODED phy to send 12 periodic adverts per second which gives me an amazing range of over 300m. (see pic below)

Since periodic adverts are sent with a fixed interval, they seem like an ideal way to maintain DM synchronisation between senders and receivers. However I can't find a way to get a callback on the sender when the periodic advert is sent. 

I get a callback when the periodic advert is received, so maybe I can use this to call dm_request_add on the receiver, but I also need to call dm_request_add on the sender at the same time.

I tried using the bt_le_ext_adv_cb.sent callback. But it's never called (It actually fires when the advertising set ends, rather unhelpfully, and rather poorly named!)

Is there a way to get a callback when a periodic advert is sent? 

Or is there another way to setup the DM synchronisation with a similar range to CODED periodic adverts?

My receiver is pre-installed to know the address of it's sender. And it's only the receiver that needs to know the distance. 

There are callbacks that look promising for PAWR (periodic advertising with responses) which I've not tried yet. 

Is there an easy way to do this that I've just not considered?

Thanks for your help (and for making this fantastic library!)

Kind regards,

-Jason

[Amanda Hsieh]

Hi, 

I am working on your case and will update it later. 

Regards,
Amanda H.

[Jason]

Hi Amanda, Thank you.

I realised that I had misunderstood the webinar, specifically that the phase calculations themselves require 2-way communications. 

I had failed to comprehend this when I first watched it. I thought they were just referring to the synchronisation step, but instead it's actually happening during the DM timeslot also. In order to do the phase calculations.

So I can't expect this to work at vast ranges, even if I can do one-way synchronisation.

My goal is to have a reliable 30m (100ft) *outdoor* range. And it would be great if I could get the synchronisation using the 12 periodic adverts that I'm already sending and receiving every second. 

I can see several possibilities.

• Change the example to use CODED phy and then look for ways to reduce the time spent scanning.
• Find a way to get synchronisation from my existing periodic adverts.
• Try the callbacks from PAWR (periodic adverts with responses)

I can see that there are callbacks listed in bt_le_ext_adv_cb which might be what I need.

	/**
	 * @brief The Controller indicates it is ready to transmit one or more subevent.
	 *
	 * This callback notifies the application that the controller has requested
	 * data for upcoming subevents.
	 *
	 * @param adv     The advertising set object.
	 * @param request Information about the upcoming subevents.
	 */
	void (*pawr_data_request)(struct bt_le_ext_adv *adv,
				  const struct bt_le_per_adv_data_request *request);
	/**
	 * @brief The Controller indicates that one or more synced devices have
	 * responded to a periodic advertising subevent indication.
	 *
	 * @param adv  The advertising set object.
	 * @param info Information about the responses received.
	 * @param buf  The received data. NULL if the controller reported
	 *             that it did not receive any response.
	 */
	void (*pawr_response)(struct bt_le_ext_adv *adv, struct bt_le_per_adv_response_info *info,
			      struct net_buf_simple *buf);

Obviously I'm not sure what to try. 

Any suggestions or advice are greatly appreciated. 

Kind regards,

-Jason

[Jason]

I did a test with the nrf_dm example with +8TX power and I can see that the range returned by ifft is good enough, and that the high-precision returns nan when the range is large. I think the estimates are about right

 

I've not tested RTT mode yet. And I've not got CODED phy advertising to work (yet)

It seemed to have poor reliability at this relatively short range however. I'm not sure if RTT will be more suited to longer ranges I'm not sure if the non-CODED scannable adverts are the problem, or it its because of the DM calculations.

I will try to get CODED phy scannable adverts working and try to test RTT also today.

[PaKa]

The phase based ranging works reliably out to 8-10 meters, for longer ranges you should use RTT only. At longer ranges you are more likely to get incorrect resolutions for the range with the phase based ranging due to multi-path and similar.

The RTT ranging requires that you can communicate over non-coded PHY so using coded PHY for the advertising will not increase your ranging capabilities.

[Jason]

I see, thank you.

Then I cannot expect the 100ft range I had hoped for. 

I just tested RTT with the example again. Making a histogram of the number of samples for each metre. 

I walked away from the device and back again. Not very scientific. But it looks like the range was already struggling beyond 10m and was fairly bad by 20m. I will repeat the test.

Is there any easy way to synchronise except scannable advertising? It uses a lot of power to scan.

Perhaps PAwR is worth a try? 

Thanks for your help.