Improving timing accuracy by only using single advertisement channel?

RE: Improving timing accuracy by only using single advertisement channel?

Audun — Tue, 21 Aug 2018 13:20:05 GMT

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.

RE: Improving timing accuracy by only using single advertisement channel?

Florian Echtler — Tue, 21 Aug 2018 11:04:04 GMT

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!

RE: Improving timing accuracy by only using single advertisement channel?

Audun — Tue, 21 Aug 2018 10:39:05 GMT

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)

RE: Improving timing accuracy by only using single advertisement channel?

Florian Echtler — Mon, 20 Aug 2018 10:54:00 GMT

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.

[quote userid="2167" url="~/f/nordic-q-a/35015/improving-timing-accuracy-by-only-using-single-advertisement-channel/144694"]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. [/quote]

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?

RE: Improving timing accuracy by only using single advertisement channel?

AmbystomaLabs — Fri, 17 Aug 2018 14:19:45 GMT

As Audun stated, you can't do anything in software with pin toggles and expect accurate timing. There is no way to infer or anticipate delays. The ISRs are just created, queued and processed as they come.

You would have to do this with radio events and PPI. Also, since you don't use the crystal 32768 your devices can be up to 500usec apart in just one second and that assumes you are actually running the cal routine. So either you will have to sync a lot or use LF_synth.

RE: Improving timing accuracy by only using single advertisement channel?

Audun — Fri, 17 Aug 2018 11:41:26 GMT

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

RE: Improving timing accuracy by only using single advertisement channel?

Florian Echtler — Fri, 17 Aug 2018 08:20:03 GMT

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?

RE: Improving timing accuracy by only using single advertisement channel?

Florian Echtler — Thu, 16 Aug 2018 13:01:27 GMT

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?

RE: Improving timing accuracy by only using single advertisement channel?

Florian Echtler — Thu, 16 Aug 2018 12:20:17 GMT

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!

RE: Improving timing accuracy by only using single advertisement channel?

Hung Bui — Mon, 04 Jun 2018 14:28:35 GMT

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.

RE: Improving timing accuracy by only using single advertisement channel?

Florian Echtler — Mon, 04 Jun 2018 12:58:31 GMT

Hello Hung, thanks for your answer!

[quote userid="2121" url="~/f/nordic-q-a/35015/improving-timing-accuracy-by-only-using-single-advertisement-channel/134557"]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. [/quote]

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

RE: Improving timing accuracy by only using single advertisement channel?

Hung Bui — Mon, 04 Jun 2018 12:26:46 GMT

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).

RE: Improving timing accuracy by only using single advertisement channel?

Florian Echtler — Sat, 02 Jun 2018 20:06:02 GMT

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

RE: Improving timing accuracy by only using single advertisement channel?

Daniel Wang — Sat, 02 Jun 2018 15:05:25 GMT

[quote userid="21613" url="~/f/nordic-q-a/35015/improving-timing-accuracy-by-only-using-single-advertisement-channel/134421"]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?[/quote]

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

RE: Improving timing accuracy by only using single advertisement channel?

Florian Echtler — Sat, 02 Jun 2018 13:56:16 GMT

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

RE: Improving timing accuracy by only using single advertisement channel?

AmbystomaLabs — Fri, 01 Jun 2018 20:57:56 GMT

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.