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

[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?

[Florian Echtler]

To illustrate my question in a bit more detail, here's my sampled data. Test setup was as follows:

• two observers running softdevice S130 v2.0.1 on a single channel (using the parameter hack mentioned above)
• note: both observers use the RC clock source due to board limitations (no 32 kHz crystal)
• one nearby advertiser (~ 50 cm) with 450 ms advertising interval
• one logic analyzer with 100 kHz sampling rate, measuring a pin on both observers that gets toggled immediately when the correct advertisement was received

The plot shows the time differences between the pin toggles. It's quite apparent that there is a peak at ~ 700 µs and a second one at ~ 1400 µs.

Can anyone venture an explanation? Maybe Audun, who seems to know a lot about the timing intricacies of the softdevice?