Closed embeddedpenguin closed 2 years ago
Hello, I think these are good questions, certainly not in the "rtfm" realm. I'll try to answer:
Access to the radio is done via a timeslot API, meaning the timesync application code will request timeslots from the SoftDevice (bluetooth stack). Once granted, it can use the radio for the duration of the timeslot. Bluetooth generally takes priority for timeslots, but radio time is a finite resource and it is possible that a very busy Bluetooth application gets somewhat impacted here. You can read more about the timeslot API, including priorities, here: https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/multiprotocol_operation/multiprotocol_support.html?cp=4_7_3_0_8 Note that the timesync receiver isn't particularly clever at the moment. It simply tries to use the radio 100% of the time to receive packets. An optimization would be to request radio time only when packets are expected to arrive.
The transmitter and receiver(s) each have a 16 MHz TIMER running. These timers run off of a 16 MHz clock tree. These clock trees are not synced and will drift over time. To compensate for this drift, the TIMER instance on the receiver is adjusted by a number of ticks in either direction based on the value of the transmitter timer. The transmitter sends a radio packet with the value of the timer in it. The receiver then compares this value to its own timer instance, and adjusts accordingly.
The timer value adjustments on the receiver are always done at the high end of the timer range. By default the timer is set to clear at value 16000 (TIME_SYNC_TIMER_MAX_VAL ) , which is 1 ms when the timer tick rate is 16 MHz. This means adjustments can be made every 1 ms. In effect, the timers should be in sync up to 1 ms after the receiver receives an adjustment radio packet.
It can be tricky to debug both Bluetooth and timesync behavior due to the realtime behavior of both. As soon as you halt the CPU, the timing is generally lost and you cannot resume operation without resetting and starting over. You could look into "monitor mode debugging" to somewhat get around this, but generally it might be easier to debug using NRF_LOG statements
Awesome. Thanks a bunch!
I'm new to nrf products and nrf5 sdk, so these questions might come off as " just rtfm" material, but I'm asking them because I ran into various issues when trying to answer these myself.
Thanks!