Improving timing accuracy by only using single advertisement channel?

[Florian Echtler]

Hi everyone,

thanks for this discussion - this question addresses almost exactly a potential use case I've been looking into.

I'd like to try and implement something this using just BLE advertising first, without using the timeslot API; the only thing I could not figure out how to do is in MartinBL's reply:

MartinBL said:

• Configure it to advertise on a single advertising channel.
• Have all your other nodes scan continuously on the same channel.

How do I do that? I'm currently using SD130 on nRF51 platform, and I have already tried something along the following lines:

ble_gap_opt_ch_map_t foo;
foo.conn_handle = 0;
foo.ch_map[0] = 0;
foo.ch_map[1] = 0;
foo.ch_map[2] = 0;
foo.ch_map[3] = 0;
foo.ch_map[4] = 0x10;
sd_ble_opt_set(BLE_GAP_OPT_CH_MAP,(const ble_opt_t*)(&foo));

That should disable all channels except 37, but as far as I can tell, it doesn't have any effect.

I've already done a first experiment for measuring the latency (just toggle a pin as soon as an advertisement has been received, and compare across several boards with logic analyzer), but I'm still seeing something around 2-4 ms of difference, so I'm assuming the advertisement channel scan is still happening...

Best regards, Florian

[AmbystomaLabs]

Not sure what the question is here. Per the BLE spec you can never have fixed latency synchronous transmission and reception.

Thus changing the advert channels is pointless.

You should follow the recommendation given in the question you linked to and use a proprietary protocol to synchronize clocks and then BLE can be used to send out timestamps. 

Though even that is sloppy. You should spend some time on your use case and get a better idea of which data are important and from whom.

[Florian Echtler]

My question is: how do I lock observers to scanning only a single advertising channel? Can I use BLE_GAP_OPT_CH_MAP for this purpose, or not? If not, what else can I use?

I know that BTLE is not designed for this, and I know that deliberately leaving adv. channels unused will degrade performance in case of noisy channels.

Nevertheless, I want to try and see how close I can get to what I want to acheive without having to resort to the custom sync protocol. I'm already down to a difference of 2-4 ms - if I can get it reliably below 1 ms, I can avoid the extra complexity.

Regards, Florian

[Daniel Wang]

Florian Echtler said:

My question is: how do I lock observers to scanning only a single advertising channel? Can I use BLE_GAP_OPT_CH_MAP for this purpose, or not? If not, what else can I use?

For advertising on single channel, you need to set the channel_mask in ble_gap_adv_params_t , that is used when you start advertising.

Scanning on one single channel is not possible on S130. It was added in S132/140 v.6.

BLE_GAP_OPT_CH_MAP is the channel map for connections, not scanning/advertising.

For timer synchronization among nRF5 devices, see this blog post

[Florian Echtler]

OK, thanks, that makes sense.

Just out of curiosity, what would happen if I set interval and window both to the maximum (0x4000) in the parameters for sd_ble_gap_scan_start? If I understand correctly, then the scan would remain on one channel for 10.24 seconds, correct? Would it also always start with the same channel?

I'm aware of the more complex method described in the link, I'm just curious how close I can get without the custom protocol.

Regards, Florian

[Hung Bui]

Hi Florian, 

 

I think what Daniel suggested about time synchronization via ESB would be best fit for you. Please be aware that you can have large number of  devices to be sync not just limited to 8 device as with the limit of ESB since you only do one direction communication (one device broadcasts other listens)

Regarding the latency you observed with advertising, most likely it's the random delay added into the advertising interval. By spec, each advertising interval requires to have a random delay of <10ms this is to avoid interference of 2 device starting to send advertising packets at the same time with same interval to be collide all the time. 

If you set the scanning window = scan interval , it will stay in scanning mode all the time on same channel if you choose to scan on only one channel (only available from Softdevice v6.0). 

 

 

 

 

 

[Florian Echtler]

Hello Hung, thanks for your answer!

Hung Bui said:

Regarding the latency you observed with advertising, most likely it's the random delay added into the advertising interval. By spec, each advertising interval requires to have a random delay of <10ms this is to avoid interference of 2 device starting to send advertising packets at the same time with same interval to be collide all the time. 

However, the time difference I was referring to is the time difference between two separate observers, not between individual advertisements. I don't have a problem with timing uncertainty regarding when an advertisement is sent, I only want all receivers to react to the reception of the advertisement with as little individual delay as possible.

Once again: before I "go down the rabbit hole" of implementing a custom timesync protocol, I want to see if this isn't possible with plain BTLE after all. Think of it as a research question :-)

Best, Florian

[Hung Bui]

Hi Floran, 

 

Thanks for the explanation. Then it's quite strange that you have the timing difference between to observers. We would need to see how you configure your scanner ? Regarding scan window, scan interval, scan channel. 

Also do you see that all the time or only seldom they didn't toggle at the same time ? Which softdevice did you use to test ? 

If you only plan to sync between observer, using advertising packet could be a solution. However, because of the lack of full control over each adv packet from the advertiser, it's harder to make sure all scanner receives the same adv packet.

I mean if one scanner receives but one scanner misses the packet, and only receive the one in next advertising interval, you may have a serious drift between 2 scanner. 

[Florian Echtler]

Just wanted to follow up on this: my test implementation had (stupidly) a leftover delay in the main loop. After I removed that, I can now get two scanners to react to one advertisement with less than 20 µs of time difference (just as expected).

Thanks for your help!

[Florian Echtler]

P.S. ah, that was maybe a little too soon. Still getting delays between individual nodes that seem to be multiples of 700 µs. Does that correspond to some internal softdevice timer?