Questions about time sync capability

[embeddedpenguin]

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.

1. Does the time sync over bluetooth affect bluetooth data traffic in any way? Like If I wanted to send data at 1kbps while keeping the clocks synced, would the data transfer affect the syncing of the clocks? Or vice versa? I tried this myself and failed. After some digging I will submit a bug report for this. Just want to make sure I'm not being dumb.
2. How exactly is the clock being synced? Is it being synced once upon initial connection? Or is it being synced every time an interrupt fires @ whatever frequency the timer is running at?
3. How long should it take to sync the clocks? If I press button 1, is there an expected time frame in which the clocks would be synced? (not sure or it depends is a perfectly fine answer here)
4. This is less to do with the capability of the time sync, and more of a developer question. How should I go about debugging this code to see what is happening? GDB is very hit or miss, giving me weird undefined behavior all the time. I tried add -Og to OPT and -DDEBUG to CFLAGS, but I get weird behavior. For example, some instructions are skipped altogether, and some instructions get stuck (because I hit a softdevice function). I think this has more to do with the nrf5 sdk w/softdevices than this specific project, but I figured I would ask here in case you had any advice.

Thanks!

[nordic-auko]

Hello, I think these are good questions, certainly not in the "rtfm" realm. I'll try to answer:

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

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

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

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

[embeddedpenguin]

Awesome. Thanks a bunch!