timing inconsistency in the first few rounds of fine timeout callback

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

My goal is to have timing consistency from the point I call bleprofile_StartTimer(); to the first time of fine timeout callback.

At the point I start timer

life=4;    //to observe only the first few rounds of the callback

bleprofile_regTimerCb(print_time_and_kill, NULL);

startTimerTimestamp = bleapputils_currentNativeBtClk();

bleprofile_StartTimer();

// bleapputils_Sleep(50);    //sleep for 5 ms

At the callback function

void print_time_and_kill()

{

  ble_trace1(":%u",bleapputils_BtClksSince(startTimerTimestamp));

  if(--life==0)

  {

      bleprofile_KillTimer();

  }

}

the code do nothing after bleprofile_StartTimer();

fine_timer_interval = 12.5 ms

First case (without bleapputils_Sleep in line 5)

The time gap between the point I start timer and the first callback will vary so much in the range of 1 - 40 units (0.3125 - 12.5 ms)

but the time gap between two consecutive callbacks is very consistent at 40 units (12.5 ms)

I've notice that in the output Console, these 3 lines will be printed before the first callback is called. (important clue)

16:49:51   Fine Timer(12 ms, 80/sec)

16:49:51   Fine TImer tick 1

16:49:51   Normal Timer(0 s, 0 tick)

16:49:51 - :31

16:49:51 - :71

16:49:51 - :111

16:49:51 - :151

Second case (with bleapputils_Sleep in line 5)

In this case, those three lines are printed after the first callback like this.

17:29:29 - :18

17:29:29   Fine Timer(12 ms, 80/sec)

17:29:29   Fine TImer tick 1

17:29:29   Normal Timer(0 s, 0 tick)

17:29:29 - :42

17:29:29 - :82

17:29:29 - :122

In this case, the time gap between the point I start timer and the first callback is very consistent at 18 units.(5.625 ms)

But the gap between the first and the second callback becomes the inconsistent part instead.

Any gaps after the second callback are consistent at 40 units (12.5 ms)

=================================================================

My hypothesis is that the code that generate those 3 lines about Fine and Normal Timer are the source of inconsistency.

Where is it from?

and How can I skip them to make all time gaps more consistent?

or Anyone know a workaround for this issue?

Thanks,

0 Likes
6 Replies
Anonymous
Not applicable

Here is my understanding;

bleapputils_Sleep() is busy wait as described in bleapputils.h.

So fine timer wanted to be called at 2 which is 40 units ahead from 2nd callback(42).

But bleapputils_Sleep(50) didn't allow to dispatch for 5ms (16units).

Then first callback was delayed to 18 (=2+16).

0 Likes
Anonymous
Not applicable

Thanks! I've tested with different sleep time and your understanding is correct.
Then, I will focus to the gap between the point I start timer and the first callback (in the first case).

How can I make it consistent?

0 Likes
Anonymous
Not applicable

I've found that the callback will be fired only at certain specific points of the timeline (kind of when Clock%40==0) regardless of the time when I start timer.

As a result, when I start timer, I might have to wait just 1 time unit or it can be as long as 40 time units to reach the point the system can fire a timeout callback.

With this design, there is no way to make it consistent.

What I am doing is to synchronize multiple Bluetooth devices by broadcasting non-connectable advertisement (only 1 packet) to those devices. When they receive (I assume they will receive at the same time), they can use that point of time to start timer simultaneously. Therefore, they could reach each fine timeout callback at the same time.

However, that method doesn't work anymore.

but it might works if I can completely reset the clock. Is it possible?

0 Likes
Anonymous
Not applicable

Hi prayook,

We took a quick look at the code you posted above and there was a couple things that stood out.

1. Using traces is not a good idea, since traces take an unknown time to print and could end up taking a lot of time. It would be better to toggle GPIOs

2.  There is no guarantee that the timers will expire at the right time.  They will be around your timers but will not be perfect

Hope this helps,

Kevin

0 Likes
Anonymous
Not applicable

prayook did you get it to work?

0 Likes
Anonymous
Not applicable

No.

0 Likes