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