RTC puzzle

The RTC module fixes are now in CVS. …previously the first clock correction would typically be completely wrong (e.g. over-correcting, or going in the wrong direction)…

Thanks for that, the first correction is in the right direction now.

For corrections of more than 32767 centiseconds (i.e. about five and a half minutes), the code will set the new time value immediately instead of applying a gradual correction.

My first thought was why such an apparently random value, or perhaps not quite so random, &7FFF!

The RTC in this Titanium gains about two minutes per day, the correction can be quite long. Put another way the Titanium has to be on for at least two hours per day to just keep up with itself.

…so maybe the code should be revised so that if the requested correction can’t be applied within the requested time, then it’ll set the time immediately instead of doing the gradual correction? For NetTime this means any correction of more than 36 seconds will be applied immediately (half hour update period)

That would be better. I would be even more in favour of starting with the right time in the first place. That is a loop we have been round before, I have either forgotten or never understood, or both, why that should not be so.

My first thought was why such an apparently random value, or perhaps not quite so random, &7FFF

Ben there, done that, with a set of switches that exhibited a weird semi-reset behaviour after 497 (and a bit) days of uptime. If you want the precise interval then take a 32 bit counter and check its rollover time.

That would be better.

Is a more frequent correction interval when the error value is large an option? Perhaps a larger adjustment at that more frequent interval too. Basically avoiding large step changes unless the error value is measured in days.