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]

As far as I can see, it is possible to choose a subset of the advertising channels when scanning using the S132 SoftDevice on nRF52832. See the channel_mask parameter in sd_ble_gap_scan_start().

Using the S130, even if you won't be able to avoid certain channels altogether, you can probably choose to ignore packets received on unwanted channels. For example, you might be able to read the RADIO.FREQUENCY register immediately after you've received an advertisement packet and get an accurate channel selection. Note that this register will be updated regularly, so there might be a race condition there.. I'm not entirely sure whether or not the S130 softdevice stays on the same channel for the duration of the scan window. If it does, you can keep track of when the scan window opened to determine if the RADIO.FREQUENCY value is correct for the received packet, or if it has just been updated to scan on a new channel. 

Otherwise, using the radio notification API to manually set up BLE scanning on a single channel might be the most robust approach. SDK 11 had an example of this: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v11.0.0/ble_sdk_app_multi_activity.html?cp=4_0_9_4_2_2_25 (removed in subsequent releases)

[Florian Echtler]

Thank you! This is the answer I was looking for.

For the record, I also found a Horrible Hack (TM) that has the same effect: in the softdevice binary, there is exactly one occurence of the byte sequence 0x25 0x26 0x27 (i.e. the three advertising channels). I patched the binary to 0x25 0x25 0x25, thereby hard-locking the softdevice to channel 37, and the result is below:

So I can now reliably trigger two observers within 20 µs. Over a sampling period of 500 s, with a total of 1748 advertisements sent, both observers received 1744 simultaneous advertisements. That result is more than good enough for me :-)

Once again, thank you very much for your thorough analysis!

[Audun]

That's a neat trick, I didn't even think of that!

Thanks for posting your results, this is pretty interesting. I guess the next challenge  might be to apply appropriate filter logic to the received advertisements in order to cover the case where the same advertisement packet is not picked up by all your scanners.