Wireless timer synchronization among nRF5 devices

RE: Wireless timer synchronization among nRF5 devices

user93336 — Mon, 01 Mar 2021 13:24:51 GMT

Thank you very much for this great blog entry.

For our application we need a synchronous counter on central and peripheral, which increments every 1ms.
The counter on central and peripheral should always contain the same value.

This blog seems like a great starting point for this.
Can you give us please some information, how to implement this properly?

Thank you very much in advance.

RE: Wireless timer synchronization among nRF5 devices

user96522 — Sun, 31 Jan 2021 16:14:38 GMT

Hello! my nrf52811 chip does not support timers 3 and 4 and EGU3. in the code you are using this. how can i replace timer 3 with register 4. and how can i replace EGU3?

RE: Wireless timer synchronization among nRF5 devices

user96522 — Wed, 27 Jan 2021 19:16:04 GMT

Hello! my nrf52811 chip does not support timers 3 and 4 and EGU3. in the code you are using this. how can i replace timer 3 with register 4. and how can i replace EGU3?

RE: Wireless timer synchronization among nRF5 devices

user96522 — Sat, 23 Jan 2021 13:26:45 GMT

Hello! my nrf52811 chip does not support timers 3 and 4 and EGU3. in the code you are using this. how can i replace timer 3 with register 4. and how can i replace EGU3?

RE: Wireless timer synchronization among nRF5 devices

user25009 — Sun, 15 Mar 2020 06:35:29 GMT

Hi , Please Advice , i want to synchronize the internal RTC . so both device actually be synchronize in the HH:MM:SS:mSEC

RE: Wireless timer synchronization among nRF5 devices

user85711 — Tue, 03 Dec 2019 16:47:25 GMT

Super useful library. Does not work currently under SES Release 4.03b though. For everybody stumbling over this. There is a functioning workaround: github.com/.../2

RE: Wireless timer synchronization among nRF5 devices

user6231 — Thu, 04 Oct 2018 14:52:43 GMT

Hi. Thanks for the post. My only question is: if I am for example sending sync packet like every 10s and during the moment of packet transmission receiver is busy sending BLE packet, will I miss the synchronization packet?

RE: Wireless timer synchronization among nRF5 devices

user72298 — Tue, 17 Jul 2018 13:20:17 GMT

does this affect data transmission in ble_central and ble_peripheral ? thank's

RE: Wireless timer synchronization among nRF5 devices

user71509 — Wed, 09 May 2018 09:11:22 GMT

This is a great post and the synchronization accuracy is quite high. Thanks a lot!

RE: Wireless timer synchronization among nRF5 devices

user71509 — Wed, 09 May 2018 09:10:35 GMT

This is a great post and the synchronization accuracy is quite high. Thanks a lot!

RE: Wireless timer synchronization among nRF5 devices

user2167 — Mon, 20 Nov 2017 09:28:01 GMT

Hi Nick, I added an SDK 14.2 port of this code to the GitHub project and included project files for Segger Embedded Studio: github.com/.../nRF5_SDK_14.2.0_17b948a

RE: Wireless timer synchronization among nRF5 devices

user66635 — Sun, 19 Nov 2017 06:26:32 GMT

Would you guys be able to update this using SDK 14 or upload a Segger Embedded Studio project to the GitHub?

RE: Wireless timer synchronization among nRF5 devices

user2167 — Fri, 03 Nov 2017 12:27:06 GMT

Ah yes, Nicolas, you are right about the ADDRESS event. I'll update my comment to reflect this, and make the formatting more clear regarding the 15 microseconds.

RE: Wireless timer synchronization among nRF5 devices

user20698 — Fri, 03 Nov 2017 12:24:36 GMT

The TX_CHAIN_DELAY is from 15us before NRF_RADIO->TASKS_START in tx to NRF_RADIO->EVENTS_ADDRESS (instead of RADIO.END) in rx.

RE: Wireless timer synchronization among nRF5 devices

user2167 — Fri, 03 Nov 2017 11:44:57 GMT

TX_CHAIN_DELAY is indeed somewhat of a magic value. It was intended to capture all (constant) delays associated with sending and receiving the packet. Specifically, the time it takes from the RADIO.START task is called on the transmitter, until the RADIO.ADDRESS event has happened on the receiving side, minus the time it takes for the radio waves to travel between the radios (this will be a relatively small number anyway). Additionally, there is a 15 microsecond delay incorporated into TX_CHAIN_DELAY by the code design (explained in next the next paragraph).

The timing master is using a 16 MHz TIMER and PPI to capture the time value (from another TIMER) and triggering the RADIO.START task. The same can be achieved by the CPU directly, but potentially introducing jitter from flash wait states and cache. The capture+start TIMER currently have a 15 microsecond delay between the timer value capture and radio start. These 15 microseconds are included in the TX_CHAIN_DELAY value.

Note that the unit value for TX_CHAIN_DELAY is 1/16 microsecond. TX_CHAIN_DELAY = 700 = 43.75 microseconds

The value of TX_CHAIN_DELAY was determined using a logic analyzer, measuring the offset between two nRF52-DKs. Note that there may were well be chip variations that can influence this parameter.

The 32 MHz crystal mounted on the nRF52-DK, which was used for these measurements, is rated as 10 ppm.