[time-nuts] Local Solar Time Clock

[Charles Steinmetz]

/tvb wrote:

>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.

The question I haven't seen answered is what error band is acceptable 
to the OP.  Mark has posted that it is not terribly difficult to get 
within small fractional minutes if you start with GPS time and 
position data, as he has done for a future release of LH.  But 
getting to the millisecond level or better is likely much more difficult.

The OP did say in a follow-up:

>I was hoping someone here might have come up with a cheap quartz 
>clock driven by a microprocessor, and the necessary code. That would 
>seem to be the most practical solution.

One normally expects a quartz clock to stay within a few seconds or 
maybe a minute of true time, so unless stated otherwise the 
expectation may be similar for a clock reprogrammed to display solar time.

As Tom points out, the clock would need to know its longitude as well 
as the conventional date and time -- so it would need GPS or some 
other nav aid to be fully automatic (otherwise it would need to be 
programmed manually for its actual longitude).

Best regards,

Charles