<div dir="ltr">adjusting time to UTC <a href="http://www.timeanddate.com/worldclock/timezone/utc">http://www.timeanddate.com/worldclock/timezone/utc</a> once a week when you connect to the server, is that a possibility?<br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-22 8:22 GMT+02:00 Mark Webb-Johnson <span dir="ltr"><<a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
+1, I like. Especially because MarkSecs sounds a bit rude...<br>
<br>
Of course, the final correction is that if we know every time we add 105 to the count, we are off by 0.1424ms, then after 10 times we are off by 1.424ms, so we could just adjust the amount we deduct appropriately. 999 vs 1,000 and instantly 3 times better. That works even better with MarkSecs (which might as well be 60ms vs 50ms, as we are good for up to 65535 for an unsigned int16). At that point, we're more accurate than the clock on the PIC18.<br>
<br>
Every 104.8576ms interrupt, we add 6291 to the counter, knowing that we are off by 0.0076ms (0.4560 marksecs).<br>
<br>
Now, when counter exceeds 60,000 (10 interrupts), we have added 62,910 to the counter (6,291 ten times) and each of those times we were too low by 0.4560 marksecs, so we are 4.560 marksecs too low, so we increment car_time by 1 second and decrement the counter by 59,995. We should then be out by 0.007333ms over that 1 second. I think that's about 1/2 second a day.<br>
<br>
Or, using 1 marksecs as 50ms: for every 104.8576ms interrupt, we add 5243 to the counter, knowing we are off by 0.02ms (0.12 marksecs). Now, when counter exceeds 50,000 (10 interrupts), we have added 52,430 to the counter (5,243 ten times) and each of those times we were too high by 0.12 marksecs, so we are 1.2 marksecs too high, so we increment car_time by 1 second and decrement the counter by 50,001. We should then by out by 0.002ms over that 1 second. I think that is about 0.17 seconds a day.<br>
<br>
Or, using 1 marksecs as 42ms (I just love the number 42, and in this case it gives us a very small loss of precision): for every 104.8576ms interrupt, we add 4404 to the counter, knowing we are off by 0.000456ms (0.0192 marksecs). Now, when counter exceeds 42,000 (10 interrupts), we have added 44,040 to the counter (4,404 ten times) and each of those times we were too low by 0.0192 marksecs, we we are 0.192 marksecs too low, so we don't need to adjust. We should then be out by 0.00456ms over that 1 second. I think that is about 0.39 seconds a day, but we have solved the answer to life the universe and everything.<br>
<br>
Or, my maths may be even more wrong.<br>
<span class="HOEnZb"><font color="#888888"><br>
Mark.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 22 Oct, 2014, at 1:38 pm, Gianluca Magalotti <<a href="mailto:gianluca@magalotti.net">gianluca@magalotti.net</a>> wrote:<br>
<br>
> Ok, so you every 104.8576ms will add 5243MarkSecs (just invented a new time unit) right?<br>
> And when the counter reaches or pass 50000 you add one second and subtract 50000 to the count.<br>
> This way you are over 0.0024ms per timer interrupt, roughly 0.022ms per second, that is less than 2s per day (that is, every 43690s we count one second more.)<br>
><br>
> Please check my math.... But you won!<br>
><br>
> Gianluca Magalotti dal mio iPad mini<br>
><br>
>> Il giorno 22/ott/2014, alle ore 06:00, <a href="mailto:ovmsdev-request@lists.teslaclub.hk">ovmsdev-request@lists.teslaclub.hk</a> ha scritto:<br>
>><br>
>> Sorry, in my P.S., I think I miscalculated the improvement.<br>
>><br>
>> 1] Current methodology:<br>
>><br>
>> Signed 16 bit integer<br>
>> Every 104.8576ms timer interrupt, add 105ms to the counter.<br>
>> If counter >1,000 treat it as 1 second and deduct 1,000 from counter.<br>
>><br>
>> Accuracy: loses 0.1424ms per timer interrupt.<br>
>><br>
>> 2] 50ms methodology:<br>
>><br>
>> Signed 16 bit integer<br>
>> Every 104.7576ms timer interrupt, add 5243 to the counter.<br>
>> That is equivalent to 5242.88 50ms chunks.<br>
>> Difference is 0.88 / 50 ms<br>
>> Accuracy: loses 0.01760ms per timer interrupt<br>
>><br>
>> Or, is my new maths wrong? Is the inaccuracy 0.01760ms or 0.12ms per timer tick?<br>
>><br>
>> Confused, I am.<br>
>><br>
>> Mark.<br>
> _______________________________________________<br>
> OvmsDev mailing list<br>
> <a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
> <a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
<br>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><a href="http://home.scarlet.be/jcsaintpo" target="_blank">http://home.scarlet.be/jcsaintpo</a><br><br></div>
</div>