Problems with timers

RE: Problems with timers

ilgrey — Tue, 14 Feb 2017 16:21:53 GMT

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.

RE: Problems with timers

FormerMember — Tue, 14 Feb 2017 10:22:56 GMT

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.

RE: Problems with timers

butch — Mon, 13 Feb 2017 13:50:34 GMT

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.