Problems with timers

[ilgrey]

I have to evaluate the results obtained for time synchronization in a piconet BTLE through the use of the RBS protocol. For this purpose I use a nRF52 DK as beacons to transmit not connectable advertising packets every second. Two nRF52 DK nodes, which implement different BTLE services and have the S130 softdevice activated, record the time of reception of the beacon and share this information. In this way they are able to construct a map of their relative offset. In this nodes I use TIMER1 to identify the instant of reception of the beacon. This the code for the timer:

void start_timer(void)

{

NRF_TIMER1->MODE = TIMER_MODE_MODE_Timer;

NRF_TIMER1->TASKS_CLEAR = 1;

NRF_TIMER1->PRESCALER = 2;

NRF_TIMER1->BITMODE = TIMER_BITMODE_BITMODE_32Bit;

NRF_TIMER1->CC[0] = 0;

NRF_TIMER1->TASKS_START = 1;

}

uint32_t capture_timer_value(void)

{

uint32_t captured_value;

NRF_TIMER1->TASKS_CAPTURE[0] = 1;

captured_value = NRF_TIMER1->CC[0];

// NRF_TIMER1->TASKS_CLEAR = 1;

return captured_value;

}

When the beacon is received, is called the capture_timer_value() function to capture the timer value. What happens is that the trend of the differences between the times of reception of the beacon relative to the two nodes has a correct average trend, but presents abnormal periodic oscillations. What the cause of this oscillations? Can anyone help me?

Tanks.

[butch]

Please explain more what the graph shows (there are no titles on the axis) and what you expected in the graph. My understanding is that you expect the two clocks to slowly drift apart. My understanding is that you expect there to be a constant lag between the time the beacon is received and the counter is captured. But it might not be constant if the BLE stack has other tasks which it is processing when the beacon is received. Is that what you want to know: what other higher priority tasks might delay the capture? I wonder whether the ARM write cache might have an effect: NRF_TIMER1->TASKS_CAPTURE[0] = 1 might not take effect until the next memory read (probably not the problem.) Also, the beacon advertisement probably has a random component since BT advertises on 3 channels in sequence: one unit receives the beacon on one channel earlier then the other unit on another channel.

[FormerMember]

What you are seeing is the correct behavior. According to the Bluetooth Core Specification, the advertising interval represents the average advertising interval. For each advertising event, a random time number will be added or subtracted from the set advertising interval. The purpose is to avoid interference with other advertising devices.

[ilgrey]

The figure shows the time difference between the reception time of the beacons from two nodes; this difference must vary linearly with small oscillations around the linearity. The anomaly is represented by the periodical large oscillations. On the graph the x axis represents the beacon number (beacon packets are numbered at trasmission); the y axis is the time difference in seconds. The fact is that what appen on the trasmitter side is irrilevant: i register tre receive time of the various beacons packets on the recevers and than make the difference.