Sorry, in my P.S., I think I miscalculated the improvement. 1] Current methodology: Signed 16 bit integer Every 104.8576ms timer interrupt, add 105ms to the counter. If counter >1,000 treat it as 1 second and deduct 1,000 from counter. Accuracy: loses 0.1424ms per timer interrupt. 2] 50ms methodology: Signed 16 bit integer Every 104.7576ms timer interrupt, add 5243 to the counter. That is equivalent to 5242.88 50ms chunks. Difference is 0.88 / 50 ms Accuracy: loses 0.01760ms per timer interrupt Or, is my new maths wrong? Is the inaccuracy 0.01760ms or 0.12ms per timer tick? Confused, I am. Mark. On 21 Oct, 2014, at 3:16 pm, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

My thinking is that losing 1 ms every second or so means 1,000 seconds (16 minutes) to lose 1 second. As we poll the GSM modem for clock once every 60 seconds that should be fine and we should maintain accuracy. The GSM modem includes a real-time clock, so even if it loses GSM connectivity it should still keep good time.

P.S. There is a simple slight improvement I thought about last night. I use a 16bit unsigned integer to count milliseconds, adding 105 to it every 104.8576ms timer interrupt, and taking off 1,000ms every time it gets >1,000. Leading to an inaccuracy of 0.1424ms every timer tick. I could simply count 50ms instead, adding 5243 every timer tick of equivalent 5242.88 50ms chunks, and then taking off 50,000 every time if gets >50,000. That would lead to an inaccuracy of 0.12ms every timer tick. We could also mess around with the timer functions to try to get something more divisible into 1ms. But, with the GSM polling, I just don't think it will be necessary.

Regards, Mark.

On 21 Oct, 2014, at 2:55 pm, Gianluca <notifications@github.com> wrote:

...

After quick math every 7 interrupts you "loose" one ms. Maybe you could count interrupts and adjust ms count. To be more precise every 44 adjustments you should skip the increment. Let's say is a gregorian solution :)

— Reply to this email directly or view it on GitHub.