[time-nuts] Local Solar Time Clock

[Chris Albertson]

What is the difference in rate between solar and UTC and how much does the
solar rate change from week to week?

I know the theory and to get it nearly perfect you'd need a computer.  But
if your tolerance is only that it be good enough for a visual reference.
(remember he said __NO SOFTWARE__)  So we are talking about mechanical
hands on a clock face.

So there is some acceptable error.  Do we only need to keep solar time to
within a minute per day?

Even computer display does NOT need to be "time nut level" accurate because
the monitor has a finite refresh frequency.  The screen cannot be drawn any
faster than monitor frame rate which is going to be maybe 60Hz to 120Hz.
So you can be "off" by on order of 0.01 seconds (A huge error by "nuts"
standards) and no one would notice because of the quantization error of the
frame rate.





On Sun, Jan 19, 2014 at 4:25 AM, Tom Van Baak <tvb at leapsecond.com> wrote:

> > I wonder if you really need a special clock?  Can't you adjust a normal
> > spring driven clock to run fast (or is it slow?) by about 1/3 of a
> percent
> > (one day per year)?  This should be within the range of adjustment.
>
> Chris,
>
> When you mention 1/3 percent, you're thinking sidereal time, which is a
> completely different concept, and much easier to implement than equation of
> time. Sidereal time is simply a calendar-day independent, fixed (2730 ppm)
> frequency offset. I already have PIC chips that do this; see PD28 under
> www.leapsecond.com/pic/picdiv.htm or read the comments in the source code
> at: http://www.leapsecond.com/pic/src/pd28.asm
>
> Solar time, on the other hand, is continuously variable in rate (and
> phase) throughout the whole year. A microprocessor implementation of solar
> time also needs to know calendar date, time, and longitude. A 4800 baud GPS
> NMEA stream input would be a convenient way to obtain this information.
> Without using floating point or trig functions, a tiny PIC implementation
> would probably use a 365 entry lookup table to adjust the output tick rate
> on a per-day basis. A more capable Arduino or RPi might allow one to
> accurate calculate EOT directly from planetary motion equations, avoiding
> hard-coded tables altogether.
>
> /tvb
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 

Chris Albertson
Redondo Beach, California