[time-nuts] latest version of arduino solar clock

Bob Camp lists at rtty.us
Mon Jan 20 17:48:09 UTC 2014


Hi

There are *lots* of ways to do any sort of code. I can’t think of any practical problem that has a single unique “best” way to do it. All I’m trying to say is that there is a way to get the job done (to much better accuracy than you need) with what you have. If there’s one way, there must be other ways as well.

Bob

On Jan 20, 2014, at 12:20 PM, Jim Lux <jimlux at earthlink.net> wrote:

> On 1/20/14 8:48 AM, Bob Camp wrote:
>> 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.
>> 
> 
> But the current code doesn't try to accumulate errors and adjustments.. it just looks up the rate from the equation (floating point) and jams it into the tick generator.
> 
> It's not a "add/drop" ticks sort of scheme.  (which could be done).
> 
> Interestingly, it occurred to me that one could just add a sufficiently large deviation random number to the period each time to dither it.
> 
> The "rate" changes once per hour (per tvb's EOT routine), so there's 3600 ticks at a given rate. If I were to vary the rate (as set to the routine) by, say, +/- 50 microseconds, the truncation to 16 microsecond chunks will average out over the 3600 ticks in an hour. A quick simulation shows sd of 1/2 microsecond for the result.
> 
> You need to add an 8 microsecond offset, because the SetPeriod routine truncates, rather than rounds.
> 
> I'd like to keep it all in high level Arduino land, rather than delving into counting cycles and ticks at a low level: makes it easier to move to a new platform.
> 
> 
> 
>> 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.
>> 
> 
> Yes, that's something I need to add: a "overall rate" adjust to calibrate the crystal.
> 
> 
>> Bob
>> 
>> 
>> 
>> On Jan 20, 2014, at 11:19 AM, Jim Lux <jimlux at 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 at 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 at 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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.




More information about the Time-nuts_lists.febo.com mailing list