Modifying wireless timer sync using RTC

RE: Modifying wireless timer sync using RTC

simon.jonghun.song — Sun, 23 Jun 2024 05:39:17 GMT

FYI

Zephyr BLE code for radio.

https://github.com/intel/zephyr/blob/main/subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio.c

RE: Modifying wireless timer sync using RTC

hmolesworth — Tue, 14 May 2024 19:38:32 GMT

Blog moved: wireless-timer-synchronization-among-nrf5-devices

RE: Modifying wireless timer sync using RTC

Tim — Fri, 17 Apr 2020 00:13:34 GMT

Thanks Susheel for the Zephyr link. What a great book opportunity to explain all the nRF5 peripherals for those new to the platform. If only I had the time ...

Thanks again,

Tim

RE: Modifying wireless timer sync using RTC

Susheel Nuguru — Thu, 16 Apr 2020 12:38:42 GMT

I am afraid there is no step by step guide on this.

But I found that the zephyr source code can be used to understand how to configure the registers.

Please take a look at RADIO configuration in Zephyr BLE code. Even though this is desgined for BLE specific part, the register configuration shows how radio configuration can be adapted for other protocols as well. Please pay attention to radio_filter_configure

RE: Modifying wireless timer sync using RTC

Tim — Wed, 15 Apr 2020 16:14:32 GMT

Thank you Susheel. I did try changing:

uint8_t rf_address[5] = {0xDE, 0xAD, 0xBE, 0xEF, 0x19};
// Radio address config
NRF_RADIO->PREFIX0 = rf_address[0];
NRF_RADIO->BASE0 = (rf_address[1] << 24 | rf_address[2] << 16 | rf_address[3] << 8 | rf_address[4]);

to:

uint8_t rf_address[5] = {0xDE, 0xAD, 0xBE, 0xEF, 0x10};
// Radio address config
NRF_RADIO->PREFIX0 = rf_address[0];
NRF_RADIO->BASE0 = (rf_address[1] << 24 | rf_address[2] << 16 | rf_address[3] << 8 | rf_address[4]);

for a second system (note change in last byte of rf_address) and found, as expected, that packets transmitted from a peripheral using the first address array are not received by peripherals listening with second address array.

What you say suggests to me that white listing and DAB/DAP can be helpful to reduce noise and interference between two systems of devices. I'm actually new to NRF_RADIO and am not experienced with this topic. If you know of any helpful learning resources for radio addressing, white listing, DAB/DAP, I would be grateful.

Many thanks,

Tim

RE: Modifying wireless timer sync using RTC

Susheel Nuguru — Wed, 15 Apr 2020 06:33:39 GMT

Hi Tim,

[quote user="Tim123"]The code needs to also allow for multiple "systems" used in close proximity and need to be sure one system of devices does not interfere with another system of devices when listening for or sending sync packets.[/quote]

I would say that using a unique serial number per "System" as part of the device address and if you can use the DAB/DAP feature to whitelist the incoming packets. would reduce noise from neighbouring systems considerably at the hardware RX level itself.

I haven't experimented with this, but I am quite confident that this can be easily achievable considering that you have a quite deep understanding of the hardware already.

RE: Modifying wireless timer sync using RTC

Tim — Fri, 10 Apr 2020 17:02:46 GMT

Thanks Susheel. Given no other considerations for frequency, I'll just use 50.

Would also appreciate some guidance regarding radio address configuration. Our product is a mobile timing system where one "system" comprises 2, 3 or 4 peripheral devices. These will use this method of syncing clocks. I have it working well using RTC instead of two TIMERs giving the required accuracy.

The code needs to also allow for multiple "systems" used in close proximity and need to be sure one system of devices does not interfere with another system of devices when listening for or sending sync packets. I presume that the devices of each system can simply use a different radio address. Each peripheral device has a unique serial number (uint16) and I presume I can construct a unique radio address based on the serial number of one of the peripherals in a system of devices. Reasonable?

Would appreciate any guidance about this. How best to construct a unique address and configure the appropriate address registers (NRF_RADIO->PREFIX0 and NRF_RADIO->BASE0).

Many thanks,

Tim

RE: Modifying wireless timer sync using RTC

Susheel Nuguru — Mon, 06 Apr 2020 12:25:09 GMT

I would suggest you to change the freqency in the mid sweep bandwidth. That is in betweel 40-60 instead of 125. Even though the hardware seems to still support the value for testing purpose, 125 is not officially supported. So for your production code use the value below 100.

RE: Modifying wireless timer sync using RTC

Tim — Thu, 02 Apr 2020 18:56:16 GMT

Thank you Susheel. Another thought ... for capturing local RTC counter when receiving sync packets, I could use PPI and an available timer to time from NRF_RADIO->EVENTS_ADDRESS to RADIO_IRQHandler() invocation (event NRF_RADIO->EVENTS_ADDRESS, task NRF_TIMER4->TASKS_START). I'm looking for millisecond accuracy, so I imagine this time will be negligible.

Could I ask you or Audun to respond to my other question about NRF_RADIO->FREQUENCY? The blog post code has ts_params.rf_chn = 125; /* For testing purposes */. This makes me wonder what must be considered when designing code for production. And in general, any other considerations when integrating this great blog post into a production product. I'm relatively new to direct manipulation of NRF_RADIO via time slots.

Many thanks,

Tim

RE: Modifying wireless timer sync using RTC

Susheel Nuguru — Thu, 02 Apr 2020 15:46:18 GMT

I shared your code changes to the actual author of the code in the link you provided in Wireless timer synchronization among nRF5 devices blog.

As you figured out PPI cannot be used to capture RTC counter, and since RTC resolution is relatively low as compared to TIMER, so it should still be ok to have a bit of software latency.

Capturing the time offset from the master on each of the nodes makes a lot of sense. You could make operations on the m_rtc_counter_offset atomic variable inside the RAM to make the timestamp calculation a bit faster. Other than that, the code looks good to Audun (the author of the blog) and it also looks good to me.