Hi If
1) Your table of errors at noon is always good to 0.1 second and it has no cumulative error (you did it on a PC with a fancy math pack). 2) Your timer has a resolution of << 0.1 second. 3) Your basic time source is accurate. (it’s not the issue here). You will always be right at noon to within 0.1 second. The only issue is how far out you are over the 24 hours. What ever error you make during the day is wiped out at noon the next day. If you have 16us adjustments, that’s plenty good enough to hold 0.1 seconds on the display. As long as you drop / add pulses in a fairly uniform fashion you will never see the granularity of the counter. For example with 30 seconds delta over the day, you want to drop (or add) 30 pulses out of every 86400. If it’s 27.6831 pulses, then the math takes a hit. The drop / add process is still the same. You simply need to hang on to the remainder (as pointed out elsewhere) in the calculation. The number is never big enough to need to drop multiple pulses. It really does not matter if the noon seconds offset from UTC time data source is a table or a calculation. You still have a net offset at noon. What ever it is, you correct to it. The smoothing in-between noon points still can work as above. If you need to correct the CPU clock to the incoming time source, the drop / add process is pretty much the same for it as well. The math gets a bit more complicated, but the drop / add result nets out to the same thing. Bob On Jan 20, 2014, at 11:19 AM, Jim Lux <jim...@earthlink.net> wrote: > here's the latest version.. > I'm not sure the sign is right on the rate adjustment. > > It will allow a "time set" in two different ways: > Unix time as U<unixtime> > or > conventional time as Tyyyymmddhhmmss > > I haven't tested it with the mechanical clock yet, but the basic code to > control the clock is in tick() and tock(). It puts out the right pulses (you > can see them with a LED and resistor). I'll head out to the store to get a > clock a bit later to try the real thing. > > > One aspect that needs work is the actual timing. The Timer1 library uses a > 16 bit counter, so the resolution is poor. (16 usec/tick) There have been > multiple messages suggesting ways to do the accurate timing at a low level. > > What I would like to do is figure out a way to use "vanilla" Arduino > libraries to do this. > > Either one could calculate the error after setting, and let it accumulate, > and then adjust the rate to compensate.. > > Or, provide a finer resolution for the timer libraries. > > I suspect someone has already done this, so I'll do some googling. > <solarclock4.cpp>_______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
