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

[Audun]

Hi Florian,

regarding the peaks you see at 700 and 1400 us, it would be interesting to get some insight into the radio hardware timing. For example, at what time the RADIO.END event is triggered (on both the advertiser and scanner boards).

This can be achieved by using PPI to trigger an GPIOTE.OUT task when the RADIO.END event fires.The GPIO assigned to the corresponding GPIOTE channel (configured to toggle the pin) can be monitored using your logic analyzer.

On the advertiser side, the RADIO.END event will tell us at what time a packet has finished transmitting.

On the scanner side, the same event will tell us when a packet has been received. Note that this event is still triggered even if there is a CRC error, or the packet content is invalid. 

Specifically, I wonder if the advertiser is transmitting one or multiple packets per advertising event. Normally three packets are transmitted back-to-back (one for each advertising channel), but I don't know the exact interval between each packet in an event on the S130 softdevice. The BT spec only states that there should be maximum 10 ms between each packet in an advertising event. 

Furthermore, using PPI and the RADIO.END event would offer better accuracy than a software timing mechanism. You can use the RADIO.END event to trigger a TIMER.CAPTURE task to accurately capture the reception time, and subsequently decide whether or not to use the captured timer value once the software validates the advertisement payload. 

Best regards,

Audun

[Florian Echtler]

Audun and AmbystomaLabs, thank you for your comments.

Another side note: I don't really have control over the advertiser - in the scenario I'm exploring, I'm trying to use any arbitrary advertiser (in particular, any recent smartphone) to serve as a trigger for the observers.

Audun said:

Specifically, I wonder if the advertiser is transmitting one or multiple packets per advertising event. Normally three packets are transmitted back-to-back (one for each advertising channel), but I don't know the exact interval between each packet in an event on the S130 softdevice. The BT spec only states that there should be maximum 10 ms between each packet in an advertising event. 

After some more digging, I think this is the core issue. I was originally thinking that I had tricked the softdevice into scanning on one channel only (by setting window, timeout and interval all to equal values of 10 seconds and restarting the scan after the timeout).

However, I'm quite certain now that the softdevice is still cycling through channels 37/38/39 in subsequent scans, and the time difference is simply the delay between the individual advertisements on the three channels. If I reset both observers at roughly the same time (even if there is 1-2 second of delay in between), then nearly all signals arrive within 20 µs of each other, meaning (IMHO) that they both are scanning on the same channel for most of the time. OTOH, if I wait for 10 seconds after resetting the first device and then reset the second one, the delay is almost exclusively 700 µs, meaning that they are almost always scanning on adjacent channels.

EDIT: confirmed, I've just printed 2400+NRF_RADIO->FREQUENCY on the serial console, and yes, it's cycling through 2402, 2426 and 2480, just as I suspected.

So I'm sort of back at my original question: is there any way to force SD130 to a single channel for scanning? If not, can I do that with SD132?