James, I was wondering for many times why is very difficult to obtain a
long time accurate clock even using 32768 or multiply Xtal.
The answer is on code but not only. External temperature affect dramatic
the xtal stability. It's imperative to use an external trimpot circuitry
and to measure & adjust the Xtal frequency at value you take in
computation.
For code I'm not an expert but I've made a 16x84 web clock collection from
you may inspire at http://www.geocities.com/vsurducan/pic.htm
Also Jinx ( Joe Colquitt ) is an expert in clock's...
One of my precious clock have Xtal thermostated at about 50...60 C and
works in harsh environement: external temperatures between -20C and +45C
Vasile
> I am programming an interrupt service for 16F84A which provides a time base in units of seconds. My project is to make . . . yet another clock, but this "time" using a 4.000 MHZ xtal, which is not the most natural choice, but offers some
> challenge, maybe more than I thought. Have not yet produced accurate time :-( and don't know why. Off by about 1 to 2 percent.
>
> Me thinking is thus:
>
> (1) XTAL is 4.000MHZ
>
> (2) Instruction cycle is therefore 4.000/4 = 1.000 MHZ
>
> (3) Need to divide 1.000 MHZ by 250, then by 250 again, then by 16 to get 1.000 second cycle rate. 1000000/(250*250*16) = 1 cycle/second
>
> (4) Must "preload" TMR0 with literal 6 so it will have a cyclic period of 250 (256-6). But wait, must compensate by loading TMR0 with 6+2 = 8 because the timer increment is latent for
> 2 instruction cycles after a write to TMR0 (see data sheet)
>
> (5) In the same isr, set up a register "clocked" that decrements upon every TMR0 overflow. And every time that register underflows to zero, it is to be preloaded with 249 to give it a period of 250.
>
> (6) The final divide by 16 is done by picking off the desired bit of another register "clocked_2" that is decremented each time "clocked" underflows. The "picked off" bit is written to port in the "main" loop to wink an LED (not shown
> below)
>
> (7) The timer prescaler was not used, it offers no help in this case. Therefore the prescaler was tossed (assigned) to the dog.
>
> Here is my humble and most unworthy interrupt routine:
> ;****************************************************************
> isr: ORG h'0004' ;interrupt service routine invoked each time TMR0 overflows 255
>
> movlw d'8' ;preload TMR0 with 8 (8-2 dead cycles=6?)
>
> movwf TMR0 ;write preload to timer (want cycle of 250)
>
> decfsz clocked, 1 ;decrement clocked_2 and preload clocked each time TMR0=zero
>
> goto cont ;skipped on clocked=0
>
> movlw d'249'
> movwf clocked ;preload clocked with 249 (250 cyclic)
>
> decf clocked_2, 1 ;decrement clocked_2
>
> cont: bcf intcon,TOIF ;clear Timer Overflow Interrupt Flag TOIF
>
> retfie
> ;***************************************************************
>
> Seems to me that this should work, and it does run, but not accurately. What might I be missing? Maybe someone can point me to some .asm code example that shows writing to the timer, including the necessary 2 instruction cycle
> compensation.
>
> THX!
> James
>
> --
> http://www.piclist.com hint: To leave the PICList
> spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu
>
>
> You will find that the clock will drift one way or the other depending
> on temperature, so using the mains as a frequency source is much more
> accurate.
You are certainly joking ! Or in your country mains frequency drift is
under 0.5% ...
> (4) Must "preload" TMR0 with literal 6 so it will have a cyclic period of
>250 (256-6). But wait, must compensate by loading TMR0 with 6+2 = 8 because
>the timer increment is latent for
> 2 instruction cycles after a write to TMR0 (see data sheet)
I have a feeling this should be 6 - 2 = 4 because it is a count up timer that
interrupts on overflow, and you need to take account of the number of
instructions in your interrupt routine before you reload it.
In USA long term mains drift is _very_ close to zero.
The power grid will deliberately adjust the mains frequency to compensate
for previous errors.
Mains driven clocks keep good time nearly indefinitely (barring power
failure, which is very rare except for local problems due to storms, etc.)
[And California's problems due to stupidity :-) ].
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
Just for comparation, you have 120V/60Hz isn't it ?
Have you an official info ( or a long time measurement ) how small
is the main frequency drift ? For me sound's incredible...
thank's
Vasile
> In USA long term mains drift is _very_ close to zero.
>
> The power grid will deliberately adjust the mains frequency to compensate
> for previous errors.
>
> Mains driven clocks keep good time nearly indefinitely (barring power
> failure, which is very rare except for local problems due to storms, etc.)
> [And California's problems due to stupidity :-) ].
>
> Bob Ammerman
> RAm Systems
> (contract development of high performance, high function, low-level
> software)
>
> -----Original Message-----
> From: Bob Ammerman [SMTP:.....RAMMERMANKILLspam@spam@PRODIGY.NET]
> Sent: Thursday, February 22, 2001 12:22 PM
> To: PICLISTKILLspamMITVMA.MIT.EDU
> Subject: Re: [PIC] Timer Tribulations
>
> As I said before:
>
> Do _NOT_ preload TMR0.
>
> Instead ADD to TMR0.
>
> For a period of 250 cycles the correct value is:
>
> 256-250+2 == 8
>
> The +2 is needed because the timer doesn't update for two cycles when it
> is
> written to (by the ADD).
>
> I have done this. It WORKS!
>
> Bob Ammerman
> RAm Systems
> (contract development of high performance, high function, low-level
> software)
>
Bob is perfectly correct. By adding a constant to the timer, you
effectively remove the only variable in the problem: the interrupt latency.
Mains frequency drift is not CUMULATIVE over any given
24 hour period. It is monitored by the power company
and compensated for. Otherwise AC electric clocks
would be absolutely worthless.
>project is to make . . . yet another clock, but this "time" using a 4.000
MHZ xtal, which is not
>the most natural choice, but offers some
>(1) XTAL is 4.000MHZ
>(2) Instruction cycle is therefore 4.000/4 = 1.000 MHZ
Here's another thought (it's not my original idea, but I can't remember
where I heard it first)...
At 1MHz, 256cycles and a prescaler of 64, there will be approximately
61.03515625 overflows per second.
Let's call that 61 and clock a second every 61 overflows.
So, every minute, we are out by 2.109375 overflows. At the time we clock
over 1 minute, subtract 2 overflows or count up to 63 overflows, your choice
So, every hour, we are out by 6.5625 overflows. At the time we clock over 1
hour, subtract 6 overflows as with the minutes.
So, every day, we are out by 13.5 overflows. At the time we clock over a
day, subtract 13 overflows as with the minutes and hours.
So, every week, we are out by 3.5 overflows. At the time we clock over a
week, subtract 3
So, every year, we are out by exactly 26 overflows which means the clock is
perfectly accurate of the crystal is perfectly on 4MHz!
This technique can be worked backwards if you have a measured time interval
and know how far the clock is off, you can substitute the 'real' clock
value and tune the offsets.
Vasile Surducan wrote:
>
> On Wed, 21 Feb 2001, Tony Nixon wrote:
>
> > You will find that the clock will drift one way or the other depending
> > on temperature, so using the mains as a frequency source is much more
> > accurate.
>
> You are certainly joking ! Or in your country mains frequency drift is
> under 0.5% ...
>
> Vasile
>
Perhaps a bit of AC math about power consumption in a system as large as
a state grid may reveal why power companies try to keep the frequency as
stable as possible.
I'm definitely no expert here, but I'll bet it is definitely in the
power company's best interest.
Upteen million clocks around the world wouldn't be using the principle
if it was unreliable.
The US is hooked up into a single power grid so that power can be shared
from one region to another over long distances. In order to do this easily,
it is necessary for all the generators not only to be producing the same
frequency, but the same phase as well.
AC motors and generators (which are pretty nearly the same thing) are a lot
like stepping motors we are familiar with. For a given phase of the power,
their rotors want to be in a corresponding physical position.
If you tie two generators together that are not in phase, the one that's
ahead will supply current to the one that's behind, which will act as a
motor trying to catch up (which will also load down the one that's ahead,
slowing it down). To do this, they will exchange current -- a lot of
current, because they will want to do this as nearly instantaneously as they
can.
So the load is getting heavy, and someone goes to switch on another
generator to handle the load, but it's out of phase. Humongous relays clang
closed, and huge currents rush about as rotating machines as big as houses
jump and buck and make the ground shake, and the lights dim.
Actually what happens is circuit breakers take both generators off line
before something breaks, and now the grid really is overloaded...
Power companies pay a whole lot of attention to frequency and phase. They
coordinate this, and keep the whole grid locked to very precise frequency
standards. Sometimes when the load is heavy, they do get behind a few
cycles, but later on when the load lightens, they speed up. If you observe
an electric wall clock carefully and compare it to something like WWV, you
may see it get a few seconds behind on a hot summer afternoon, but it will
be caught up by the next morning.
So the grid, at least in the US has great long-term stability, but only
pretty good short-term.
My favorite way to handle this 'non-commensurate' intervals problem is to
steal a concept from the Bresenham line drawing algorithm.
Using the current case: 4.00 MHz crystal
1Mhz instruction rate
256 cycles and prescaler of 64
each overflow of the timer represents
256*64 == 16384 microseconds
You start with a counter set to 1,000,000 (1 second in microseconds)
On each timer interrupt you subtract 16384 from the counter.
If the counter goes negative you update the time by one second and then add
1,000,000 back in to the counter.
This technique will work for any interval. It can be made perfect for
intervals that have a rational relationship to the instruction cycle time,
and can be abitrary close to perfect even for irrational ratios (anybody got
any SQRT(2) Mhz crystals handy?)
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
In Ukraine these clocks just don't work correctly. Currently we have
the mains frequency at about 49.3 Hz, and if you assume the frequency
is 50 Hz... :)
> Vasile Surducan wrote:
>>
>> On Wed, 21 Feb 2001, Tony Nixon wrote:
>>
>> > You will find that the clock will drift one way or the other depending
>> > on temperature, so using the mains as a frequency source is much more
>> > accurate.
>>
>> You are certainly joking ! Or in your country mains frequency drift is
>> under 0.5% ...
>>
>> Vasile
>>
> Perhaps a bit of AC math about power consumption in a system as large as
> a state grid may reveal why power companies try to keep the frequency as
> stable as possible.
> I'm definitely no expert here, but I'll bet it is definitely in the
> power company's best interest.
> Upteen million clocks around the world wouldn't be using the principle
> if it was unreliable.
Nikolai Golovchenko wrote:
>
> In Ukraine these clocks just don't work correctly. Currently we have
> the mains frequency at about 49.3 Hz, and if you assume the frequency
> is 50 Hz... :)
>
> Nikolai
The thing to remember is it's not the actual frequency accuracy that counts
so much, it's the synching of phase that does. If they run the grid at
49.3Hz that's fine, as long as every generator is running at that frequency
with the same relative phase. TTYL
I think an easier way to cope with the error is simply to count time
in time units instead of overflows. For example,
fosc=4MHz
prescaler=64
timer is not reloaded (256 cycle period)
Each overflow takes
4*256*prescaler
T = 1/(fosc/4/prescaler/256) = ----------------- [s]
fosc
In our case,
T=0.016384 [s]
So, on each timer overflow, we add this time to the time accumulator.
When the accumulator becomes equal or higher than 1, we increment the
seconds counter and subtract one from the accumulator.
The accuracy depends on how well the T constant is approximated. In
binary, the T value 0.016384 looks like infinite series:
0.000001000011000110111101111010000010110101111011...
Say we want to consider only 24 bits after the decimal point. The
error then is 0.00003%, which is probably good enough :)
constant=round(T*2^24)=0431BE (hex)
Now the code would look like:
movlw 0xBE
addwf time0, f
movlw 0x31
skpnc
movlw 0x32
addwf time1, f
movlw 0x04
skpnc
movlw 0x05
addwf time2, f
skpnc
goto increment_seconds
There is no need to initialize the time0:2 accumulator, because we
don't really care at which moment the first second ticks.
As a bonus, this approach solves the problem of which time of the day
to do correction :)
> >project is to make . . . yet another clock, but this "time" using a 4.000
> MHZ xtal, which is not
> >the most natural choice, but offers some
> >(1) XTAL is 4.000MHZ
> >(2) Instruction cycle is therefore 4.000/4 = 1.000 MHZ
> Here's another thought (it's not my original idea, but I can't remember
> where I heard it first)...
> At 1MHz, 256cycles and a prescaler of 64, there will be approximately
> 61.03515625 overflows per second.
> Let's call that 61 and clock a second every 61 overflows.
> So, every minute, we are out by 2.109375 overflows. At the time we clock
> over 1 minute, subtract 2 overflows or count up to 63 overflows, your choice
> So, every hour, we are out by 6.5625 overflows. At the time we clock over 1
> hour, subtract 6 overflows as with the minutes.
> So, every day, we are out by 13.5 overflows. At the time we clock over a
> day, subtract 13 overflows as with the minutes and hours.
> So, every week, we are out by 3.5 overflows. At the time we clock over a
> week, subtract 3
> So, every year, we are out by exactly 26 overflows which means the clock is
> perfectly accurate of the crystal is perfectly on 4MHz!
> This technique can be worked backwards if you have a measured time interval
> and know how far the clock is off, you can substitute the 'real' clock
> value and tune the offsets.
> Nikolai Golovchenko wrote:
> >
> > In Ukraine these clocks just don't work correctly. Currently we have
> > the mains frequency at about 49.3 Hz, and if you assume the frequency
> > is 50 Hz... :)
> >
> > Nikolai
>
>
> It'll give you more time to relax ;-)
>
I don't know why, but you ( americans ) look more relax than we are...
Even when you have painted the moon with coca-cola sign, you found it
already painted in red... at 49,3 Hz
Hey! All this talk about clocks and 50Hz/60Hz mains
timing and getting crystal clocks accurate just
gave me a clever idea!
Using mains sync is probably the best for accuracy,
but has problems due to needing to provide a mains
supply and then insulate high voltages or use
a transformer etc. Just not practical for a
battery powered PIC device on the wall.
So how about this: Every time I use a high gain
input on some circuit and put the cro on it there
is always some 50Hz mains freq clearly visible
on the signal. Yes even on battery driven circuits.
Seems the average house has quite enough mains driven
devices and mains wires running through all the
walls that there is a very definite 50Hz/60Hz
RF signal everywhere in suburbia.
So... How about a simple two transistor high-gain
amp (or op amp) tuned for about 50Hz. This could
be fed into the PIC pin. Sure there would be some
ocassional false triggers but the PIC could be
smart enough to log input triggers in software
and "decide" which are the real ones based on the
general timer period which is always known.
If done correctly you could have a battery powered
PIC device anywhere in your home, mains sync'ed
and running with perfect time accuracy. And never
have to actually connect it TO the mains.
So this is the point where some smartie normally
says they already thought of it and have been
making them for years... ;o)
-Roman
Tony Nixon wrote:
>
> > > You will find that the clock will drift one way or the other depending
> > > on temperature, so using the mains as a frequency source is much more
> > > accurate.
> >
> > You are certainly joking ! Or in your country mains frequency drift is
> > under 0.5% ...
Nikolai Golovchenko wrote:
>
> In Ukraine these clocks just don't work correctly. Currently we have
> the mains frequency at about 49.3 Hz, and if you assume the frequency
> is 50 Hz... :)
>
> Nikolai
Ha ha! So they are ripping you off 0.7Hz!!
You are getting less than what you pay for,
I wonder if that applies, seriously??? :o)
-Roman
>
> I think an easier way to cope with the error is simply to count time
> in time units instead of overflows. For example,
>
> fosc=4MHz
> prescaler=64
> timer is not reloaded (256 cycle period)
>
> Each overflow takes
> 4*256*prescaler
> T = 1/(fosc/4/prescaler/256) = ----------------- [s]
> fosc
>
> In our case,
> T=0.016384 [s]
>
> So, on each timer overflow, we add this time to the time accumulator.
> When the accumulator becomes equal or higher than 1, we increment the
> seconds counter and subtract one from the accumulator.
>
> The accuracy depends on how well the T constant is approximated. In
> binary, the T value 0.016384 looks like infinite series:
> 0.000001000011000110111101111010000010110101111011...
>
> Say we want to consider only 24 bits after the decimal point. The
> error then is 0.00003%, which is probably good enough :)
>
> constant=round(T*2^24)=0431BE (hex)
>
> Now the code would look like:
> movlw 0xBE
> addwf time0, f
> movlw 0x31
> skpnc
> movlw 0x32
> addwf time1, f
> movlw 0x04
> skpnc
> movlw 0x05
> addwf time2, f
>
> skpnc
> goto increment_seconds
>
> There is no need to initialize the time0:2 accumulator, because we
> don't really care at which moment the first second ticks.
>
> As a bonus, this approach solves the problem of which time of the day
> to do correction :)
>
> Nikolai
Doesn't Bob's Bresenheim method have zero error
and only needs one 24bit add every second?? :o)
-Roman
>
> On Fri, 23 Feb 2001, Tony Nixon wrote:
>
> > Nikolai Golovchenko wrote:
> > >
> > > In Ukraine these clocks just don't work correctly. Currently we have
> > > the mains frequency at about 49.3 Hz, and if you assume the frequency
> > > is 50 Hz... :)
> > >
> > > Nikolai
> >
> >
> > It'll give you more time to relax ;-)
> >
> I don't know why, but you ( americans ) look more relax than we are...
> Even when you have painted the moon with coca-cola sign, you found it
> already painted in red... at 49,3 Hz
>
> Zdrasvuite Nicolai,
> Cheers Tony,
>
> Vasile
Ha ha! Friendly competition!! :o)
Hey, I just realised, the Coca Cola sign already
IS red!! Is that telling us something??? ;o)
-Roman
Maybe, I don't know about that method. In fact, you could do the
calculation at about the 1 Hz rate if you wish. The idea is to count
the actual time between overflows. Well, it might be any rate. At
lower than 1 Hz the seconds are updated too rarely. Above 1 Hz is the
best. But I doubt about absolute zero error for every case. The
overflow period should be represented as a finite binary fixed-point
number to achieve that (like 0.75 s, or 0.125 s). But as long as error
in software is reasonably low (lower than crystal) you are okay with
any crystal.
>> Nikolai Golovchenko wrote:
>> >
>> > In Ukraine these clocks just don't work correctly. Currently we have
>> > the mains frequency at about 49.3 Hz, and if you assume the frequency
>> > is 50 Hz... :)
>> >
>> > Nikolai
>>
>>
>> It'll give you more time to relax ;-)
>>
> I don't know why, but you ( americans ) look more relax than we are...
> Even when you have painted the moon with coca-cola sign, you found it
> already painted in red... at 49,3 Hz
Usually houses don't have gas, heat or water counters. So everyone
pays an "average" rate relative to apartment size. I heard the tenants
of an apartment house installed the counters, and the actual payment
should have been something like 20% less. But no one lets them pay
less!!
Seriously, the problem with low frequency, as far as I know, deals
with overloaded power system. There are shortages of fuel, etc... And
also someone decided to shut down the Chernobyl nuclear station. :)
> Nikolai Golovchenko wrote:
>>
>> In Ukraine these clocks just don't work correctly. Currently we have
>> the mains frequency at about 49.3 Hz, and if you assume the frequency
>> is 50 Hz... :)
>>
>> Nikolai
> Ha ha! So they are ripping you off 0.7Hz!!
> You are getting less than what you pay for,
> I wonder if that applies, seriously??? :o)
> -Roman
> Nikolai Golovchenko wrote:
> >
> > I think an easier way to cope with the error is simply to count time
> > in time units instead of overflows. For example,
> >
> > fosc=4MHz
> > prescaler=64
> > timer is not reloaded (256 cycle period)
> >
> > Each overflow takes
> > 4*256*prescaler
> > T = 1/(fosc/4/prescaler/256) = ----------------- [s]
> > fosc
> >
> > In our case,
> > T=0.016384 [s]
> >
> > So, on each timer overflow, we add this time to the time accumulator.
> > When the accumulator becomes equal or higher than 1, we increment the
> > seconds counter and subtract one from the accumulator.
> >
> > The accuracy depends on how well the T constant is approximated. In
> > binary, the T value 0.016384 looks like infinite series:
> > 0.000001000011000110111101111010000010110101111011...
> >
> > Say we want to consider only 24 bits after the decimal point. The
> > error then is 0.00003%, which is probably good enough :)
> >
> > constant=round(T*2^24)=0431BE (hex)
> >
> > Now the code would look like:
> > movlw 0xBE
> > addwf time0, f
> > movlw 0x31
> > skpnc
> > movlw 0x32
> > addwf time1, f
> > movlw 0x04
> > skpnc
> > movlw 0x05
> > addwf time2, f
> >
> > skpnc
> > goto increment_seconds
> >
> > There is no need to initialize the time0:2 accumulator, because we
> > don't really care at which moment the first second ticks.
> >
> > As a bonus, this approach solves the problem of which time of the day
> > to do correction :)
> >
> > Nikolai
>
>
> Doesn't Bob's Bresenheim method have zero error
> and only needs one 24bit add every second?? :o)
> -Roman
Actually, without looking closely at the above, it is very close to what I
recommended, except that the accumulator is a fixed point number in seconds,
and we add ticks to it until is gets to one.
My technique requires a 24bit add or subtract on every timer interrupt, plus
an extra one once a second.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
part 1 658 bytes content-type:text/plain; (decoded 7bit)
> All this talk about clocks and 50Hz/60Hz mains
> timing and getting crystal clocks accurate just
>
> Using mains sync is probably the best for accuracy,
I use this circuit as an accurate and very low power long-
term back-up if mains goes down or is removed during
transport. You can pick up a kitchen clock for $2, take the
small PCB out of it and unsolder the coil connection. (The
coil, btw, can be driven by reciprocating PIC o/ps through
a 390R resistor so the clock movement isn't a write-off).
The PCB puts out an alternating 0.5Hz on each of the two
pads where the coil was. Pick either as the 0V
> > All this talk about clocks and 50Hz/60Hz mains
> > timing and getting crystal clocks accurate just
> >
> > Using mains sync is probably the best for accuracy,
>
> I use this circuit as an accurate and very low power long-
> term back-up if mains goes down or is removed during
> transport. You can pick up a kitchen clock for $2, take the
> small PCB out of it and unsolder the coil connection. (The
> coil, btw, can be driven by reciprocating PIC o/ps through
> a 390R resistor so the clock movement isn't a write-off).
> The PCB puts out an alternating 0.5Hz on each of the two
> pads where the coil was. Pick either as the 0V
All this discussion has me rethinking my sunrise/sunset clock/controller.
So far I'd been happy with the 32khz crystal but I haven't run tests more than
24 hours yet and the target location isn't going to be a well temp controlled
as my test bench.
Did we finally agree that a couple of big series resistors and a 5.1 zener
was the safest line voltage reducer? I think I have some 1 Mohms in one of
my junk boxes.
So what do you think of the idea of counting line frequency for the primary
timekeeper with the 32khz as the backup? I already have the 320 Khz and
adding 2 junkbox resistors and and zener is no big deal.
>
> > > All this talk about clocks and 50Hz/60Hz mains
> > > timing and getting crystal clocks accurate just
> > >
> > > Using mains sync is probably the best for accuracy,
> >
> > I use this circuit as an accurate and very low power long-
> > term back-up if mains goes down or is removed during
> > transport. You can pick up a kitchen clock for $2, take the
> > small PCB out of it and unsolder the coil connection. (The
> > coil, btw, can be driven by reciprocating PIC o/ps through
> > a 390R resistor so the clock movement isn't a write-off).
> > The PCB puts out an alternating 0.5Hz on each of the two
> > pads where the coil was. Pick either as the 0V
>
> All this discussion has me rethinking my sunrise/sunset clock/controller.
> So far I'd been happy with the 32khz crystal but I haven't run tests more than
> 24 hours yet and the target location isn't going to be a well temp controlled
> as my test bench.
>
> Did we finally agree that a couple of big series resistors and a 5.1 zener
> was the safest line voltage reducer? I think I have some 1 Mohms in one of
> my junk boxes.
>
> So what do you think of the idea of counting line frequency for the primary
> timekeeper with the 32khz as the backup? I already have the 320 Khz and
> adding 2 junkbox resistors and and zener is no big deal.
If you have the option and already have a mains transformer,
that is the safest system. The large inductance of the
transformer is the best spike killer. :o)
-Roman
>If you have the option and already have a mains transformer,
>that is the safest system. The large inductance of the
>transformer is the best spike killer. :o)
>-Roman
Huh ? Do you want to do the small rationing with the coupling capcitance
between primary and secondary again ? The one with the input resistor to a
PIC pin connected to HV ? I know how this sounds, but, if your project is
well-earthed, then the spike will probably glitch it hard. If it is not
earthed but properly built then it may not notice the glitch at all ...
but there is no warranty. Anyway this time small value capacitors across
the diodes in the bridge rectifiers will help. Like 0.1uF across two of
the diodes in the bridge. In some countries this is mandatory, but for
other reasons (to avoid generating harmonics from hard switching diodes).
Vasile Surducan wrote:
> I don't know why, but you ( americans ) look more relax than we are...
> Even when you have painted the moon with coca-cola sign, you found it
> already painted in red... at 49,3 Hz
>
> Zdrasvuite Nicolai,
> Cheers Tony,
>
> Vasile
Roman Black wrote:
>
> Hey! All this talk about clocks and 50Hz/60Hz mains
> timing and getting crystal clocks accurate just
> gave me a clever idea!
>
> Using mains sync is probably the best for accuracy,
I thought about this ages ago, but I wonder how many 'ticks' get
corrupted when electric motors, welders, etc. etc. are started and
stopped.
Tony Nixon wrote:
> Roman Black wrote:
> >
> > Hey! All this talk about clocks and 50Hz/60Hz mains
> > timing and getting crystal clocks accurate just
> > gave me a clever idea!
> >
> > Using mains sync is probably the best for accuracy,
>
> I thought about this ages ago, but I wonder how many 'ticks' get
> corrupted when electric motors, welders, etc. etc. are started and
> stopped.
Thats probably why those old clocks had little flywheels in them <G>.
They only tracked the average frequency, not the instantaneous one.
As if anyone would notice the cumulative 1000/60 error when their
alarm clock goes off.
Robert Rolf wrote:
>
> Tony Nixon wrote:
> > Roman Black wrote:
> > >
> > > Hey! All this talk about clocks and 50Hz/60Hz mains
> > > timing and getting crystal clocks accurate just
> > > gave me a clever idea!
> > >
> > > Using mains sync is probably the best for accuracy,
> >
> > I thought about this ages ago, but I wonder how many 'ticks' get
> > corrupted when electric motors, welders, etc. etc. are started and
> > stopped.
>
> Thats probably why those old clocks had little flywheels in them <G>.
> They only tracked the average frequency, not the instantaneous one.
> As if anyone would notice the cumulative 1000/60 error when their
> alarm clock goes off.
I guess you could create a similar flywheel in software.
Keep track of the 50Hz signal and if a valid signal change occurs
outside a hysteresis point, ignore it.
Can also be used to provide a timebase for brief power outages.
> Robert Rolf wrote:
> >
> > Thats probably why those old clocks had little flywheels in them <G>.
> > They only tracked the average frequency, not the instantaneous one.
> > As if anyone would notice the cumulative 1000/60 error when their
> > alarm clock goes off.
>
> I guess you could create a similar flywheel in software.
Yeah, but don't hit any breakpoints while you're simulating or your code will
crash!
> > I guess you could create a similar flywheel in software.
>
> Yeah, but don't hit any breakpoints while you're simulating or your code will
> crash!
Peter L. Peres wrote:
>
> >If you have the option and already have a mains transformer,
> >that is the safest system. The large inductance of the
> >transformer is the best spike killer. :o)
> >-Roman
>
> Huh ? Do you want to do the small rationing with the coupling capcitance
> between primary and secondary again ? The one with the input resistor to a
> PIC pin connected to HV ? I know how this sounds, but, if your project is
> well-earthed, then the spike will probably glitch it hard. If it is not
> earthed but properly built then it may not notice the glitch at all ...
> but there is no warranty. Anyway this time small value capacitors across
> the diodes in the bridge rectifiers will help. Like 0.1uF across two of
> the diodes in the bridge. In some countries this is mandatory, but for
> other reasons (to avoid generating harmonics from hard switching diodes).
>
> Peter
Double huh! I have no idea what you just said Peter!
:o)
-Roman
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
Tony Nixon wrote:
>
> Roman Black wrote:
> >
> > Hey! All this talk about clocks and 50Hz/60Hz mains
> > timing and getting crystal clocks accurate just
> > gave me a clever idea!
> >
> > Using mains sync is probably the best for accuracy,
>
> I thought about this ages ago, but I wonder how many 'ticks' get
> corrupted when electric motors, welders, etc. etc. are started and
> stopped.
That's why you use software correction to make
up for missed ticks, and only allow a small window
for tick timing. It should self-correct given that
it will receive 100 ticks/second.
-Roman
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads