Synchronisation with advertisement

[pascal defesche]

Hello,

Im trying to create a synchronisation method for sensors using BLE. At the moment i can synchronise them within 10ms accuracy, in theory it should be within 2ms and i can not find this 7ms extra delay. This is my current synchronisation method:

At the sensor(using S110) i'm using the 16 bit timer1 with a resolution of 4us. I'm using a compare match to increment a variable(uint16 msec) within the time it overflows in this case 125ms. Just before the radio gets active(radio notification) i'm reading the current timer1 register and put this in another variable(uint16 usec) and set these time values in the manufacturer specific advertise data. So i'm now sure each time before the radio gets active a new value will be advertised. The advertising interval is set to 1s.

Now at the S120 device im scanning 100% so almost each second it will receive the timing of the sensor. I've measured this with the oscilloscope by setting a pin high when sending at sensor and receiving at S120 device. I've seen a variable delay of Δt 2ms this is noticed as the S120 scans on channel 37,38,39 (1ms inbetween these channels). Immediately after i've received the timing value from the sensor I read the timer1 register of the S120 device and calculate the difference between the S120 and sensor(S110). Now at the next compare event of the S120 device i'm setting a new compare register at timer1: normal compare register + difference (i've calculated the min / max of difference and this is within the timers resolution).

Now in theory i would expect to see a constant delay + Δt 2ms from scanning on 3 different channels. In fact i see the Δt differ within 10ms. Is there anything im missing? Hope someone can help me with this. I've attached some pictures showing the sensor and S120 device timer compare interrupt and zooms.

Regards, Pascal

[pascal defesche]

In the above method at each compare IRQ i cleared the timer and restart counting from 0 towards 31250. I thought maybe the clear task is not being executed exactly at count value 31250. If a bluetooth event comes at IRQ the timer will not be cleared and for example counts toward 3250 and gets cleared.

So now instead of clearing the timer at each compare IRQ im just setting new compare value with: CC[0] += 31250. I use CC[1] to capture the timervalue and put it in currentvalue. I calculate the time needed towards a new interrupt as follow:

NRF_TIMER1->TASKS_CAPTURE[1] = 1; //capture timer value
currentvalue = (NRF_TIMER1->CC[1]); //value in us
if(currentvalue>NRF_TIMER1->CC[0])
{
    currentvalue = 65535-currentvalue + NRF_TIMER1->CC[0];
}
else
{
currentvalue = NRF_TIMER1->CC[0] - currentvalue;
}

At the S120 device i calculate his time value towards next IRQ. At the next IRQ of the S120 device i update the compare register with: NRF_TIMER1->CC[0] += TIMER1_CC_DELAY - difference;

In theory i would expect the IRQs to be executed at exactly the same time. Still i'm getting the same results as my first test: Δt = 10ms jitter instead of 2ms jitter. Does someone know what causes this unexpected delay? All help will be appreciated!

[pascal defesche]

Made a little progress on this case: i keep reading the timer in my main loop and set this time as advertising data instead of using the radio notification(like in my posts before). So it keeps updating the advertising data until it cannot update anymore because the radio gets active. The synchronisation protocol works much better in this way: most of the time i can see a synchronisation of Δt = 2ms. Sometimes i see a little jitter towards 10ms, but still cannot explain this.

My question to Nordic: Is the softdevice causing this unexpected delay? Why does the radio notification not give me a constant delay?

[Knut Eldhuset]

Hi,

From the Bluetooth Spec 4.1, Volume 6, Part B, section 4.4.2.2 "Advertising Interval," you can see that the time between consecutive advertising events (T_advEvent) is:

T_advEvent = advInterval + advDelay

advDelay is a pseudo-random value ranging from 0ms to 10ms. I think you will not be able to get rid of the 10ms jitter with your method of synchronization.

BR

[pascal defesche]

Wont the radio notification give me an exact callback to mcu when radio gets active in 1,74ms? So this advDelay included.

[pascal defesche]

Softdevice was not causing this delay. My radio notification was to short, so my current advertisement was sent next adv interval. Setting radio notification towards max solved my problem. Im now able to synchronise two devices within an accuracy of 2ms. Nordic told me in future stack release they will implement a way you can advertise on only 1 channel, so 2ms error can be eliminated in future. Hope this helps others