Luis Gustavo de A. Carvalho wrote:
>
> Hello,
>
> I am using a PIC to print tickets in a small printer. I have to print the
> date and time too. Does anybody knows a good Real Time Clock IC for using
> with PIC's ?
> Thank you for any information
>
> Luis Gustavo

I'am think the Dallas DS1302 should be ok.
I am trying to communicate with the IC right now, no luck so far...
Anyone have some schematic and/or code ???

Patrick J wrote:
>
> Luis Gustavo de A. Carvalho wrote:
> >
> > Hello,
> >
> > I am using a PIC to print tickets in a small printer. I have to print the
> > date and time too. Does anybody knows a good Real Time Clock IC for using
> > with PIC's ?
> > Thank you for any information
> >
> > Luis Gustavo
>
> I'am think the Dallas DS1302 should be ok.
> I am trying to communicate with the IC right now, no luck so far...
> Anyone have some schematic and/or code ???
>
> /PJ

>I am using a PIC to print tickets in a small printer. I have to print the
>date and time too. Does anybody knows a good Real Time Clock IC for using
>with PIC's ?

I plan on using a Dallas Semicondutor DS1302 timekeeping chip on a project
I'm building. It's an 8 pin chip with a three wire serial I/O. It gives
year, month, day, hour, minutes and seconds. Time can be 24 hour or AM/PM.
It also has 31 bytes of RAM for scratchpad storage. It operates on 2.5-5
volts and has a separate power input pin for a watch battery to keep things
running when the power is turned off.

Luis Gustavo de A. Carvalho wrote:
>
> Hello,
>
> I am using a PIC to print tickets in a small printer. I have to print the
> date and time too. Does anybody knows a good Real Time Clock IC for using
> with PIC's ?
> Thank you for any information
>
> Luis Gustavo

> I am using a PIC to print tickets in a small printer. I have to print the
> date and time too. Does anybody knows a good Real Time Clock IC for using
> with PIC's ?
> Thank you for any information

Depending upon CPU speed and power requirements, you may be able to get
by without an external RTC chip. There are three approaches you may
wish to consider:

[1] Use any PIC with a normal-speed oscillator and keep it powered; since
the PIC will use about 1-4mA, you will probably want to have it wall
supplied.

[2] Use any PIC with a 32768Hz clock. This will drop power consumption
by a couple orders of magnitude vs a 4MHz crystal (note: if you have
the brown-out detect enabled, it will SUBSTANTIALLY increase your
current consumption in slow-speed or sleep modes. The 300uA it adds
is no big deal if the PIC is drawing 2mA already, but when the rest
of the PIC is drawing 70uA, an extra 300uA is annoying)

[3] Use a 16C74A, 16C73, 16C64, 16C62, or another PIC with a 32KHz osc-
illator that's seperate from the CPU clock. This can then be prog-
rammed to awaken the PIC every 2 seconds; if you leave the clock reg-
isters alone (except the interrupt flag), you will have an accurate
timepiece that draws very little battery current. Note the caveat
above re the brown-out detector. Note as well that if the watchdog
is enabled at its slowest speed, it may hit (triggering a wakeup) in
less than two seconds; it MAY be possible for it to hit precisely as
the timer interrupt is awakening the CPU and cause a watchdog reset.
For this reason, it MIGHT be desirable to have the watchdog set to
bark at the about-one-second prescalar and then have the watchdog
routine check whether the system should wake up for the timer (if
not, go back to sleep until the dog barks again). This will add
about 1 second of "jitter" to the real-time clock while the CPU is
not running, but no long term error. In addition, once the CPU is
fully running the jitter will go away.

Patrick J wrote:
>
> Luis Gustavo de A. Carvalho wrote:
> >
> > Hello,
> >
> > I am using a PIC to print tickets in a small printer. I have to
> print the
> > date and time too. Does anybody knows a good Real Time Clock IC for
> using
> > with PIC's ?
> > Thank you for any information
> >
> > Luis Gustavo
>
> I'am think the Dallas DS1302 should be ok.
> I am trying to communicate with the IC right now, no luck so far...
> Anyone have some schematic and/or code ???
>
> /PJ

>I am using a PIC to print tickets in a small printer. I have to print the
>date and time too. Does anybody knows a good Real Time Clock IC for using
>with PIC's ?
>Thank you for any information
>
>Luis Gustavo

I'm using the Dallas DS1202. It's DIP 8, just add a cristal and battery,
it has some RAM in it also.

> Depending upon CPU speed and power requirements, you may be able to get
> by without an external RTC chip. There are three approaches you may
> wish to consider:
>
> [1] Use any PIC with a normal-speed oscillator and keep it powered; since
> the PIC will use about 1-4mA, you will probably want to have it wall
> supplied.

What kind of accuracy can one expect from a PIC with a X MHz crystal?
If you assume that the crystal is off by 25ppm, you would be off by
0.000025 seconds per second. This would mean gaining (or losing)
0.000025*3600*24=2.16 seconds in a 24 hour period. This does not
seem very accurate.

>
> [2] Use any PIC with a 32768Hz clock. This will drop power consumption

Is the 32768KHz crystals used for RTC's more accurate than the 'normal'
crystals? Or do you get the same kind of accuracy from them?

You can get 10ppm in a 32768 xtal. The RTC specs I have seen indicate that
they are no more accurate than a PIC doing the same thing. Dallas, for
example, claims +/- 30 sec/month (which is 10ppm).
----------
Bruce Cannon
Style Management Systems

> What kind of accuracy can one expect from a PIC with a X MHz crystal?
> If you assume that the crystal is off by 25ppm, you would be off by
> 0.000025 seconds per second. This would mean gaining (or losing)
> 0.000025*3600*24=2.16 seconds in a 24 hour period. This does not
> seem very accurate.
>
> >
> > [2] Use any PIC with a 32768Hz clock. This will drop power consumption
>
> Is the 32768KHz crystals used for RTC's more accurate than the 'normal'
> crystals? Or do you get the same kind of accuracy from them?
>
> Just wondering...
>
> Niki

>
> > Depending upon CPU speed and power requirements, you may be able to get
> > by without an external RTC chip. There are three approaches you may
> > wish to consider:
> >
> > [1] Use any PIC with a normal-speed oscillator and keep it powered; since
> > the PIC will use about 1-4mA, you will probably want to have it wall
> > supplied.
>
> What kind of accuracy can one expect from a PIC with a X MHz crystal?
> If you assume that the crystal is off by 25ppm, you would be off by
> 0.000025 seconds per second. This would mean gaining (or losing)
> 0.000025*3600*24=2.16 seconds in a 24 hour period. This does not
> seem very accurate.
>
> >
> > [2] Use any PIC with a 32768Hz clock. This will drop power consumption
>
> Is the 32768KHz crystals used for RTC's more accurate than the 'normal'
> crystals? Or do you get the same kind of accuracy from them?
>
> Just wondering...
>
> Niki

You use correction factors:

Keep a count...

Every X counts = 1s
Every 60s = 1min - adjust count...
etc...

Did it with an 84 with 4mHz clock. Had to do corrections every
two seconds and on the hour and on the day. Accuracy is a couple
of seconds a year.

> What kind of accuracy can one expect from a PIC with a X MHz crystal?
> If you assume that the crystal is off by 25ppm, you would be off by
> 0.000025 seconds per second. This would mean gaining (or losing)
> 0.000025*3600*24=2.16 seconds in a 24 hour period. This does not
> seem very accurate.
>
> >
> > [2] Use any PIC with a 32768Hz clock. This will drop power consumption
>
> Is the 32768KHz crystals used for RTC's more accurate than the 'normal'
> crystals? Or do you get the same kind of accuracy from them?

There really isn't anything magic about the oscillators on RTC chips. There
are various factors that will make crystal oscillators of any type run faster
or slower than intended. Some will be fairly constant for given devices and
component values; some will vary from one device to another but be relatively
constant under temperature changes; some will vary with temperature (but may
be consistent from one device to another).

Depending upon your accuracy requirements, you may opt to:

[1] Ignore the problem--let the crystal run as it will

[2] Tweak the capacitors so that the "average" unit runs well

[3] Tweak the capacitors on individual units so they all run well (many RTC
chips let you program a "trim" value which varies the load capacitance
slightly)

[4] Adjust in software (either an "average" amount for all units, or on a
measured-per-unit basis) for the clock being fast or slow.

[5] Adjust in software, using a temperature sensor and measurements made on
each unit. This last approach requires a fair bit of work (since you
have to measure each unit's precise speed at different temperatures) but
it is *extremely* precise.

The first method is the easiest; the last is more precise. Use whatever seems
appropriate for your application.

Bruce Cannon <EraseMEbcannonspam_OUTTakeThisOuTWIRED2.NET> wrote:
>You can get 10ppm in a 32768 xtal. The RTC specs I have seen indicate that
>they are no more accurate than a PIC doing the same thing. Dallas, for
>example, claims +/- 30 sec/month (which is 10ppm).

The problem here is temperature. Most watch crystals (32768) have
a parabolic temperature curve which peaks around 25 C. The frequency
deviates from its 25 C value by an amount approximately
-0.04 * (T - 25)^2 ppm. A 10 degree change (either direction) will
change the frequency by -4 ppm. For a room temperature application,
perhaps this is not a big deal but in many cases, temperature swings of
30 or more degrees are to be expected and will wreck the accuracy.

Note that temperature changes will cause a watch crystal to slow
down, as opposed to an AT cut which has an 'S' shaped curve.

> perhaps this is not a big deal but in many cases, temperature swings of
> 30 or more degrees are to be expected and will wreck the accuracy.

How about a correction factor which adjusts itself based on the
temperature? At 25 C, no correction and then increasing correction as
the temperature deviates from 25 DEG C. I think that would be easier
and cheaper than trying to build a controlled environment for the crystal
which is your other alternative.

Martin McCormick wrote:
>
> Bob Fehrenbach writes:
> > a parabolic temperature curve which peaks around 25 C.
>
> > perhaps this is not a big deal but in many cases, temperature swings of
> > 30 or more degrees are to be expected and will wreck the accuracy.
>
> How about a correction factor which adjusts itself based on the
> temperature? At 25 C, no correction and then increasing correction as
> the temperature deviates from 25 DEG C. I think that would be easier
> and cheaper than trying to build a controlled environment for the crystal
> which is your other alternative.
>
Is cost an important factor? We use a Statek 32kHz oscillator: 10uA at
5V and 0.001% frequency tolerance (13 seconds a year) over an operating
temperature of -55 deg C to +125 deg C. About US$19 for singles.

Matt Bonner <@spam@mbonnerKILLspamSUNADA.COM> wrote:
>Is cost an important factor? We use a Statek 32kHz oscillator: 10uA at
>5V and 0.001% frequency tolerance (13 seconds a year) over an operating
>temperature of -55 deg C to +125 deg C. About US$19 for singles.

My arithmetic says that .001% = 10 ppm or about 5 minutes/year.
Yet, I grew up in the slide rule days and always had problems with
those decimal points.

Martin McCormick <RemoveMEmartinTakeThisOuTDC.CIS.OKSTATE.EDU> wrote:
> How about a correction factor which adjusts itself based on the
>temperature? At 25 C, no correction and then increasing correction as
>the temperature deviates from 25 DEG C.

If the change in temperature only affected the crystal, the results
might be somewhat predictable and hence could be conpensated.
Unfortunately, there are other factors such as the oscillator circuit,
the crystal caps etc. We sprayed 'freeze mist' on a PIC running
with a watch crystal and the frequency went UP!. If the crystal
were the only factor the frequency should have gone down.

Bob Fehrenbach wrote:
>
> Martin McCormick <TakeThisOuTmartinEraseMEspam_OUTDC.CIS.OKSTATE.EDU> wrote:
> > How about a correction factor which adjusts itself based on the
> >temperature? At 25 C, no correction and then increasing correction as
> >the temperature deviates from 25 DEG C.
>
> If the change in temperature only affected the crystal, the results
> might be somewhat predictable and hence could be conpensated.
> Unfortunately, there are other factors such as the oscillator circuit,
> the crystal caps etc. We sprayed 'freeze mist' on a PIC running
> with a watch crystal and the frequency went UP!. If the crystal
> were the only factor the frequency should have gone down.
>
If I remember correctly, the freq vs temp vs curve has a maximum around
250C.
If you go cooler, or warmer, the frequency drops. That is, if memory
serves
correctly...

If you want to keep that frequency stable, you have to keep the
temperature
stable too. The rate of drift increases with increased temperature, but
it is
not so easy to keep a component cool without a peltier junction device.
The
easier answer is to heat it up to, say, 600C with a transistor biased
with a
temperature sensor.

The rate of drift only picks up big time at around 800C, so it should be
ok.

>
>Depending upon your accuracy requirements, you may opt to:
>
>[1] Ignore the problem--let the crystal run as it will
>
>[2] Tweak the capacitors so that the "average" unit runs well
>
>[3] Tweak the capacitors on individual units so they all run well (many RTC
> chips let you program a "trim" value which varies the load capacitance
> slightly)
>
>[4] Adjust in software (either an "average" amount for all units, or on a
> measured-per-unit basis) for the clock being fast or slow.
>
>[5] Adjust in software, using a temperature sensor and measurements made on
> each unit. This last approach requires a fair bit of work (since you
> have to measure each unit's precise speed at different temperatures) but
> it is *extremely* precise.
>
>The first method is the easiest; the last is more precise. Use whatever seems
>appropriate for your application.

[6] Use an ovened [fixed temperature] crystal and calibrate against an
atomic clock. This offers real precision but requires lots of power :-(

On Wed, 30 Jul 1997 09:03:02 BST Keith Dowsett <RemoveMEkdowsettEraseMEEraseMERPMS.AC.UK>
writes:
>>
>>Depending upon your accuracy requirements, you may opt to:
>>
>>[1] Ignore the problem--let the crystal run as it will

The problem of building a frequency standard that is both rock-cheap in
cost and also accurate for long-term timekeeping is complex. First,
consider an external standard. In the US, the power line frequency (over
a long term) is very precisely controlled and excellent for timekeeping.
Also the government standards bureau makes accurate time available by
phone or radio.

>>
>>[2] Tweak the capacitors so that the "average" unit runs well
>>
>>[3] Tweak the capacitors on individual units so they all run well
>(many RTC
>> chips let you program a "trim" value which varies the load
>capacitance
>> slightly)

I think the "trim" value works by adding or dropping counts. This is
also possible in PIC software of course. The problem is measuring the
untrimmed frequency in order to know how far to trim. Connecting any
measuring equipment to the oscillator will throw it way off frequency.
One way would be provide a buffered frequency counter output, then use a
precise counter for several seconds to determine each unit's frequency,
and program the compensation accordingly. Another approach would be to
supply a precise frequency input, then have software compare the two and
program the compensation value.

I saw a method once that uses an ultrasonic transducer to listen to the
vibrations of a 32.768 KHz crystal. Never tried it though.

>>
>>[4] Adjust in software (either an "average" amount for all units, or
>on a
>> measured-per-unit basis) for the clock being fast or slow.

There are three factors which make a crystal frequency not exactly what
is specified.

The crystal itself may be made not exactly right. Crystals ordered
one-off for a specific frequency are ground down slowly and constantly
rechecked until the frequency is within 2 to 5 ppm (within this range,
the external circuit can be adjusted to make the frequency exactly
right). This is a time-consuming process and the price is around $10.00
per unit. Mass-produced microprocessor type crystals of the under $1.00
variety are likely only ground once so the units coming off the line have
frequencies statistically distributed around the specified value. Any
that are way out are rejected and any that are very close may be sold at
a higher price as precision units.

Crystals also drift (usually lower) in frequency over a period of months
to years. This is caused mostly by contaminants migrating into the
quartz, so is a direct result of how clean the manufacturer keeps the
crystal and the inside of the can. I have had particularly bad results
in this regard with radio crystals from a certain manufacturer in
Florida. This effect makes one-time compensation ineffective. I suspect
mass-produced crystals may not be too bad in long term "ageing" since
they are not handled as much as custom ones.

The third factor is the external circuit. The gain of the amplifier and
the capacitance of the capacitors are subject to manufacturing and
temperature variations. The PIC running at 32 KHz is particularly bad
for this since it requires large external capacitors with corresponding
large uncertainty in their value.

>>
>>[5] Adjust in software, using a temperature sensor and measurements
>made on
>> each unit. This last approach requires a fair bit of work (since
>you
>> have to measure each unit's precise speed at different
>temperatures) but
>> it is *extremely* precise.

The precision depends on how well you can characterize the unit in the
factory. Measurements to 10ppm are possible but require medium-grade
calibrated test equipment and several seconds to a minute of observation
on each unit. To the 1ppm range and beyond requires even more. The
circuit has to be built so everything that is not measured and
compensated will not vary. Now the temperature sensor, etc. has to be
calibrated as well as the crystal. And long-term drift of the crystal or
other components can't be accounted for with just one measurement.
Measuring when everything is brand new is about the worst you can do.

>>
>>The first method is the easiest; the last is more precise. Use
>whatever seems
>>appropriate for your application.
>
> [6] Use an ovened [fixed temperature] crystal and calibrate against
>an
>atomic clock. This offers real precision but requires lots of power
>:-(
>
Crystals for oven operation are designed so the turnover (flat part) of
the temperature-frequency curve is at the oven temperature. This means
that small variatons of temperature have little effect on frequency.
However, outside the specified temperature the frequency changes sharply.
In high-precision devices, the entire oscillator circuit is also
enclosed in the oven. Others just heat the crystal.

Oscillator blocks based either on controlled temperature or carefully
designed and extensively tested compensation are available from various
manufacturers. They are not extremely expensive, but a lot more than one
would want to pay for the real-time clock in a timecard stamper, which I
think is how this whole discussion got started.

If the device is to be powered constantly from the commercial AC line,
counting cycles of the line will give excellent long-term accuracy. In
the US, utility companies realize that many timekeeping devices depend on
them and control the long-term frequency to atomic standards. The
instantaneous frequency may change a little due to transisent loads and
plants being taken on and off line, but over the course of a day it will
balance out.

The major drawback is that the user has to reset the time after a power
failure. Switching to a crystal or even RC oscillator as a backup
prevents a lot of this. However, usually the device is set up without a
lot of provisions to power down so a fairly large battery is required for
the backup phase. The backup shouldn't last forever though because the
time will be inaccurate due to running on the lower precision oscillator.
It shoud force the user to reset after a day or so of no AC.

> The problem of building a frequency standard that is both rock-cheap in
> cost and also accurate for long-term timekeeping is complex. First,
> consider an external standard. In the US, the power line frequency (over
> a long term) is very precisely controlled and excellent for timekeeping.
> Also the government standards bureau makes accurate time available by
> phone or radio.

For a device which will be powered continuously off the AC line (aside from
momentary brief lapses) the AC line is excellent; while it's not a rock-solid
60Hz and can slow down during times of peak demand, the electric company will
keep track of how many cycles behind it's gotten and run it faster during off
peak times to compensate.

If a device will not be run continuously off the AC line, however, it may be
a bad idea to use the AC line as a reference even when the device is plugged
in; if the device is plugged and unplugged at certain times each day, there
could be substantial systemic errors introduced.

For example, suppose someone has their POS terminal plugged in every day from
9am to 5pm and that Acme Electric supplies 59.97Hz from 11am to 5pm each day
(loading from air conditioners, etc.) and 60.01Hz from 5pm to 11am. A clock
which is plugged in 24 hours a day will get 5,184,000 cycles per day--exactly
as it should. Each day, however, the POS terminal will only get 1,727,424
cycles during its eight hours (it should get 1,728,000--a shortfall of 576
cycles). This is an error of about 300ppm; much worse than even a mediocre
crystal. Even if the clock ran at precisely the right speed the rest of the
time, the error would be about 10sec/day. If the clock calibrated itself to
"match" the AC line, the error would be about 30sec/day.

> I think the "trim" value works by adding or dropping counts. This is
> also possible in PIC software of course. The problem is measuring the
> untrimmed frequency in order to know how far to trim. Connecting any
> measuring equipment to the oscillator will throw it way off frequency.
> One way would be provide a buffered frequency counter output, then use a
> precise counter for several seconds to determine each unit's frequency,
> and program the compensation accordingly. Another approach would be to
> supply a precise frequency input, then have software compare the two and
> program the compensation value.

The one RTC I saw with a trim was documented as affecting the load capaci-
tance. I'm assuming the documentation was right. As for measuring the
oscillator frequency, that must be done by using some other output (e.g. a
divide-by-32768 square wave); alternatively, the software could be programmed
to time an hour started at the same time as a precise clock. After 1 hour,
the difference between the completion times signalled by the two devices would
be the amount of time that needed to be added/dropped each hour.

> >>
> >>[4] Adjust in software (either an "average" amount for all units, or
> >on a
> >> measured-per-unit basis) for the clock being fast or slow.
>
> There are three factors which make a crystal frequency not exactly what
> is specified.
>
> The crystal itself may be made not exactly right.
>
> Crystals also drift (usually lower) in frequency over a period of months
> to years.
>
> The third factor is the external circuit.

Right. These factors can all cause errors in the oscillator speed; if you're
trying to get 0.01ppm accuracy cheap off-the-shelf parts probably won't cut it
even if you try to trim things in software. On the other hand, using software
with per-unit trimming may cut errors by an order of magnitude much more
cheaply than would be possible by other means (it depends on what needs to be
done with the units anyway re burn-in and such. If units already receive a
168-hour burn in with temperature swings as part of their reliability testing
and have on-board EEPROMs, feeding the devices a precise time signal and hav-
ing them calibrate to that may not add much to the production cost. If the
units would normally be shipped from the assembly line right out the door,
the extra testing/calibration would be expensive.

> >>[5] Adjust in software, using a temperature sensor and measurements
> >made on
> >> each unit. This last approach requires a fair bit of work (since
> >you
> >> have to measure each unit's precise speed at different
> >temperatures) but
> >> it is *extremely* precise.
>
> The precision depends on how well you can characterize the unit in the
> factory. Measurements to 10ppm are possible but require medium-grade
> calibrated test equipment and several seconds to a minute of observation
> on each unit. To the 1ppm range and beyond requires even more. The
> circuit has to be built so everything that is not measured and
> compensated will not vary. Now the temperature sensor, etc. has to be
> calibrated as well as the crystal. And long-term drift of the crystal or
> other components can't be accounted for with just one measurement.
> Measuring when everything is brand new is about the worst you can do.

Certainly things need to go through a burn-in process before you try to
establish final calibration. On the other hand, the time required per-unit
may not be so critical as you suggest: if the units are placed in a burn-in
fixture which supplies them with a precise, e.g., 2Hz reference wave, then
the units can all self-calibrate simultaneously. In addition, it may not
be necessary to calibrate the temperature sensor to any particular standard
provided that the unit knows that, e.g., when the temperature sensor reads
16 units the oscillator runs at 32,767.94Hz; when it reads 32 units, the
oscillator runs at 32,767.99Hz; at 48 units, it runs at 32,768.02Hz; at 64
units, it runs at 32,768.01Hz; etc. Provided that everything is suitably
burned-in, it may not even be necessary to use a "real" temperature sensor
(though things will be more precise if one is used).

Of course, this is all going on the assumption that everything which may
affect the oscillator speed will change temperature together, or at least do
so in about the same was as it did during calibration. If the CPU is doing
essentially the same job and switching about the same currents in the field
as in the lab, and if ambient temperature shifts aren't too rapid, this may
not be a problem. If the equipment will often be taken from extremely hot
places to extremely cold ones, or if power dissipation patterns in the field
don't match those in the lab, accuracy will suffer.

Simply put, the amount of complexity required for an accurate timebase varies
greatly depending upon the accuracy required and the amount of environmental
variation it must accept. But for many applications, a crystal combined with
software temperature compensation can provide excellent results.

>
> >>
> >>The first method is the easiest; the last is more precise. Use
> >whatever seems
> >>appropriate for your application.
> >
> > [6] Use an ovened [fixed temperature] crystal and calibrate against
> >an
> >atomic clock. This offers real precision but requires lots of power
> >:-(
> >
> Crystals for oven operation are designed so the turnover (flat part) of
> the temperature-frequency curve is at the oven temperature. This means
> that small variatons of temperature have little effect on frequency.
> However, outside the specified temperature the frequency changes sharply.
> In high-precision devices, the entire oscillator circuit is also
> enclosed in the oven. Others just heat the crystal.
>
> Oscillator blocks based either on controlled temperature or carefully
> designed and extensively tested compensation are available from various
> manufacturers. They are not extremely expensive, but a lot more than one
> would want to pay for the real-time clock in a timecard stamper, which I
> think is how this whole discussion got started.
>
> If the device is to be powered constantly from the commercial AC line,
> counting cycles of the line will give excellent long-term accuracy. In
> the US, utility companies realize that many timekeeping devices depend on
> them and control the long-term frequency to atomic standards. The
> instantaneous frequency may change a little due to transisent loads and
> plants being taken on and off line, but over the course of a day it will
> balance out.
>
> The major drawback is that the user has to reset the time after a power
> failure. Switching to a crystal or even RC oscillator as a backup
> prevents a lot of this. However, usually the device is set up without a
> lot of provisions to power down so a fairly large battery is required for
> the backup phase. The backup shouldn't last forever though because the
> time will be inaccurate due to running on the lower precision oscillator.
> It shoud force the user to reset after a day or so of no AC.
>

> > The problem of building a frequency standard that is both rock-cheap in
> > cost and also accurate for long-term timekeeping is complex.

> For a device which will be powered continuously off the AC line
> (aside from momentary brief lapses) the AC line is excellent;

For my purposes, in AC only powered designs, I'm thinking about
using the AC line as a frequency standard because it would be more
precise than an external RC oscillator using 5% and 10% components.
Hey- it's a cooking appliance. No AC, no cookie.

I don't need crystal controlled precision, but I need better than
+/-10%. even 1% or 2% would be great.

My question has to do with overseas 50 HZ. Does anyone know if
they are as stable as the frequency in the US?

I need to design a system that will work on either 50 Hz or 60 Hz.
In that situation, you can't just count line pulses, you'd need to
compensate for the different frequencies as well. I'm thinking about
a routine that measures the line frequency then decides whether it's
closer to 50 or 60 hz, then applies a software calibration number to
the timer. Haven't thought it through at all.

On Thu, 31 Jul 1997 09:05:35 +0000 Lawrence Lile <RemoveMElilelspam_OUTKILLspamtoastmaster.com>
writes:
>John,
>
>
>For my purposes, in AC only powered designs, I'm thinking about
>using the AC line as a frequency standard because it would be more
>precise than an external RC oscillator using 5% and 10% components.
>Hey- it's a cooking appliance. No AC, no cookie.
>
>I don't need crystal controlled precision, but I need better than
>+/-10%. even 1% or 2% would be great.
>
> My question has to do with overseas 50 HZ. Does anyone know if
>they are as stable as the frequency in the US?
>
About the worst would be a place with no electrical "grid", just
independent generators for each house, block, or neighborhood. The
frequency would be determined by a mechanical governor on the generator's
engine, which could be within 1% with good maintenance but is more likely
in the 3-5% range. Any place that has a network of plants connected in a
grid is going to pay a lot more attention to frequency. A cooking
appliance designed to operate from low-grade utility power should have
feedback of the voltage and / or heat developed in addition to just
cooking time.

>I need to design a system that will work on either 50 Hz or 60 Hz.
>In that situation, you can't just count line pulses, you'd need to
>compensate for the different frequencies as well. I'm thinking about
>a routine that measures the line frequency then decides whether it's
>closer to 50 or 60 hz, then applies a software calibration number to
>the timer. Haven't thought it through at all.

This could be done. The RC oscillator has to always be precise enough to
tell the difference between 50 and 60 Hz of course. This is about +- 5%.
Otherwise there would be random cookie disasters if the frequency were
chosen wrong.

For this kind of application I'd consider a ceramic resonator, not as
expensive as a crystal but with the 1% or so precision needed and immune
from local variations.

I did a routine to determine if the input was 50 or 60 hz, just sorta
hard to really test when all we have is 60hz here. But, ended up it
didn't matter, as it used it for a reference only as number of pulses
between events, rather than being used as a actual clock.

> ----------
> From: Mike Keitz[SMTP:RemoveMEmkeitzTakeThisOuTspamJUNO.COM]
> Sent: Thursday, July 31, 1997 9:23 AM
> To: EraseMEPICLISTspamspamBeGoneMITVMA.MIT.EDU
> Subject: Re: Real Time Clock
>
> On Thu, 31 Jul 1997 09:05:35 +0000 Lawrence Lile
> <RemoveMElilelKILLspamtoastmaster.com>
> writes:
> >John,
> >
> >
> >For my purposes, in AC only powered designs, I'm thinking about
> >using the AC line as a frequency standard because it would be more
> >precise than an external RC oscillator using 5% and 10% components.
> >Hey- it's a cooking appliance. No AC, no cookie.
> >
> >I don't need crystal controlled precision, but I need better than
> >+/-10%. even 1% or 2% would be great.
> >
> > My question has to do with overseas 50 HZ. Does anyone know if
> >they are as stable as the frequency in the US?
> >
> About the worst would be a place with no electrical "grid", just
> independent generators for each house, block, or neighborhood. The
> frequency would be determined by a mechanical governor on the
> generator's
> engine, which could be within 1% with good maintenance but is more
> likely
> in the 3-5% range. Any place that has a network of plants connected
> in a
> grid is going to pay a lot more attention to frequency. A cooking
> appliance designed to operate from low-grade utility power should have
> feedback of the voltage and / or heat developed in addition to just
> cooking time.
>
>
> >I need to design a system that will work on either 50 Hz or 60 Hz.
> >In that situation, you can't just count line pulses, you'd need to
> >compensate for the different frequencies as well. I'm thinking about
> >a routine that measures the line frequency then decides whether it's
> >closer to 50 or 60 hz, then applies a software calibration number to
> >the timer. Haven't thought it through at all.
>
> This could be done. The RC oscillator has to always be precise enough
> to
> tell the difference between 50 and 60 Hz of course. This is about +-
> 5%.
> Otherwise there would be random cookie disasters if the frequency
> were
> chosen wrong.
>
> For this kind of application I'd consider a ceramic resonator, not as
> expensive as a crystal but with the 1% or so precision needed and
> immune
> from local variations.
>

> Not yet, but I'm thinking about it. I'm considering using a 32KHz
> pic so it can keep time well enough during power outages with the
> RTCC. The mains will then provide the primary timebase. I just don't
> know if 8k instructions per second will be enough.

My plan is to tie the AC mains through a couple of 1 meg reistors
in series (so if one of them fries in the UL required shorted
component test it doesn't fry my chip!) to the TMR0 input. On bootup
I'll set the TMR0 up for external triggering, start counting when it
reaches 1 to synchornize with the line, then time it. Instead of
setting a flag, I'll just stuff a timing value into a variable that I
need later (easier, IMHO).

One problem might be if there's a nasty line hit during my
calibration routine, the frequency could be way off. In my case as
long as this doesn't cause danger, just annoyance, this would be OK.

One other problem is with power relays (which I use). If you trigger
a relay at the same spot on the AC sine wave every time it's similar
to switching DC. One contact of the relay tends to plate out on the
other, resulting in pitting and reduced life. I've been warned to
introduce a time delay so the relay switches at different polarities.
Is this a fairy tale from an overzealous relay salesmqan or has
anyone seen suych a problem?

Lawrence Lile writes:
>One other problem is with power relays (which I use). If you trigger
>a relay at the same spot on the AC sine wave every time it's similar
>to switching DC. One contact of the relay tends to plate out on the
>other, resulting in pitting and reduced life. I've been warned to
>introduce a time delay so the relay switches at different polarities.
> Is this a fairy tale from an overzealous relay salesmqan or has
>anyone seen suych a problem?

What the salesman said is true as far as it goes. If you could
be sure that the relay opened and closed at the zero-point in the sine wave,
then there would be no pitting and no sparks. It is hard to do that on
an electro-mechanical device like that. You didn't say what kind of currents
were being switched, but the bigger the relay, the more inertia there is in
the iron that is being moved and the more uncertainty there is in the exact
microsecond that the contacts will either make or break.

If I were building such a device, I would try the lazy man's
way, first. I would look for one of the solid-state relays which was designed
with a zero-crossing detector in the closure circuit. These usually have a
TRIAC as the switch, (relay contacts), so they will by nature open on the
next zero-crossing after you remove the DC control voltage from the LED
or what would have been the coil. It would most likely be necessary to
install spike suppressors on the TRIAC side and a device called a snubber
to prevent high-voltage spikes on the mains from tripping the TRIAC, but
this circuit would be electrically clean and quiet as well as acoustically
quiet, also.

> What the salesman said is true as far as it goes. If you could
> be sure that the relay opened and closed at the zero-point in the sine wave,
> then there would be no pitting and no sparks. It is hard to do that on
> an electro-mechanical device like that. You didn't say what kind of currents
> were being switched, but the bigger the relay, the more inertia there is in
> the iron that is being moved and the more uncertainty there is in the exact
> microsecond that the contacts will either make or break.

Note that the "zero point" in this context is not the zero-voltage point,
but the zero-current point. If you open at the zero-voltage point a relay
that's driving a large capacitor, it will have to interrupt substantial
reverse current. If it's driving an inductor, you will have to deal with
substantial foward current that will produce large voltage spikes if
undiverted.

> I was writing to someone the other day and observed that I never
> use
> the "backup" batteries in my bedside (and similar) clocks, as on the
> one hand, they seem to all use rather antiquated NMOS logic which
> flattens the battery in a few hours. I hate replacing the battery
> just because the power failed or the plug was left out awhile. The
> other reason however is that their "backup" timers are so poor -
> they appear to be intended to survive only the occasional outage of
> a few seconds.

I am sick of those battery hogs, too. I'd be happy with a clock that
would survive a few hours of outages without sucking down a $2.00
nine volt, even if it didn't keep very good time.

>
> Perhaps that is fair enough for their purpose. Nevertheless the
> combination of an accurate 32KHz crystal and a mains counter which
> could be used to trim the time IFF it managed to count without
> interruption for say, 24 hours, could be an idea. Even better, use
> a PLL algorithm to reject few-cycle interruptions and THEN use it to
> trim the primary crystal-derived time when it has survived 24 hours
> without loss of lock.

> > One other problem is with power relays (which I use). If you trigger
> > a relay at the same spot on the AC sine wave every time it's similar
> > to switching DC. One contact of the relay tends to plate out on the
> > other, resulting in pitting and reduced life. I've been warned to
> > introduce a time delay so the relay switches at different polarities.
> > Is this a fairy tale from an overzealous relay salesman or has
> > anyone seen suych a problem?
>
> Experience: no! No experience of significance that is. Possibly
> germaine however to my house lighting controller project. Theory
> sounds reasonable however. Proposed solutions: 1} Switch at zero
> crossing.

Relays (I love 'em, I hate 'em) switch slowly. Trigger one at a zero
crossing and it doesn't make contact until several aeons
later, maybe 10 millisieconds. (Check that fact I'm not sure) At
any rate they are not SCR's. So far I have used non-synchonous
timing routines and have seen no life problems with relays. We set
up an accelerated life test on a product that required 72,000
operations. After 500,000 operations at 130% of rated wattage the
technician exclaimed "This relay will live longer than me!" Maybe I
should repeat this test with a synchronous AC line triggered timing
routine and test my theory.
-- Lawrence Lile

>> I've been warned to
> >introduce a time delay so the relay switches at different polarities.
> > Is this a fairy tale from an overzealous relay salesmqan or has
> >anyone seen suych a problem?
>
> What the salesman said is true as far as it goes. If you
> could
> be sure that the relay opened and closed at the zero-point in the
> sine wave, then there would be no pitting and no sparks. It is hard
> to do that on an electro-mechanical device like that. You didn't
> say what kind of currents were being switched, but the bigger the
> relay, the more inertia there is in the iron that is being moved and
> the more uncertainty there is in the exact microsecond that the
> contacts will either make or break.
>
> If I were building such a device, I would try the lazy man's
> way, first. I would look for one of the solid-state relays

My major design constraint is cheap. I can buy a 10 amp rated SPST
relay for $0.50 in quantity. Can't touch that with a 10 or 12 amp
rated Triac, as far as I know. I'm controlling heaters for cooking
appliances at 120 or 240 volts, 800 to 1200 watts.

I'm thinking about staging a life test of an AC line triggered relay,
to test this theory.

>Paul wrote:
>
>
>> I was writing to someone the other day and observed that I never
>> use
>> the "backup" batteries in my bedside (and similar) clocks, as on the
>> one hand, they seem to all use rather antiquated NMOS logic which
>> flattens the battery in a few hours. I hate replacing the battery
>> just because the power failed or the plug was left out awhile. The
>> other reason however is that their "backup" timers are so poor -
>> they appear to be intended to survive only the occasional outage of
>> a few seconds.
>
>I am sick of those battery hogs, too. I'd be happy with a clock that
>would survive a few hours of outages without sucking down a $2.00
>nine volt, even if it didn't keep very good time.
>

The noname one I've got is ok as long as the alarm doesn't go off whilst the
power is off - they powered that from the battery too! (and that is not
kind to batteries - two leds, and a pll tuning system and a stereo amp see
to that...) Perhaps they think we'd get fired if it didn't wake us up...
OTOH a few hours of no mains pushes it to about 20 minutes fast...

>>
>> Perhaps that is fair enough for their purpose. Nevertheless the
>> combination of an accurate 32KHz crystal and a mains counter which

I wonder what they are using. RC with 10% components? The pcbs have that
phenolic look to them that says - cheap!

>Relays (I love 'em, I hate 'em) switch slowly. Trigger one at a zero
>crossing and it doesn't make contact until several aeons
>later, maybe 10 millisieconds. (Check that fact I'm not sure) At
>any rate they are not SCR's. So far I have used non-synchonous
>timing routines and have seen no life problems with relays. We set
>up an accelerated life test on a product that required 72,000
>operations. After 500,000 operations at 130% of rated wattage the
>technician exclaimed "This relay will live longer than me!" Maybe I

>Paul wrote:
>
>
>> I was writing to someone the other day and observed that I never
>> use
>> the "backup" batteries in my bedside (and similar) clocks, as on the
>> one hand, they seem to all use rather antiquated NMOS logic which
>> flattens the battery in a few hours. I hate replacing the battery
>> just because the power failed or the plug was left out awhile. The
>> other reason however is that their "backup" timers are so poor -
>> they appear to be intended to survive only the occasional outage of
>> a few seconds.
>
>I am sick of those battery hogs, too. I'd be happy with a clock that
>would survive a few hours of outages without sucking down a $2.00
>nine volt, even if it didn't keep very good time.
>

The noname one I've got is ok as long as the alarm doesn't go off whilst the
power is off - they powered that from the battery too! (and that is not
kind to batteries - two leds, and a pll tuning system and a stereo amp see
to that...) Perhaps they think we'd get fired if it didn't wake us up...
OTOH a few hours of no mains pushes it to about 20 minutes fast...

>>
>> Perhaps that is fair enough for their purpose. Nevertheless the
>> combination of an accurate 32KHz crystal and a mains counter which

I wonder what they are using. RC with 10% components? The pcbs have that
phenolic look to them that says - cheap!

>Relays (I love 'em, I hate 'em) switch slowly. Trigger one at a zero
>crossing and it doesn't make contact until several aeons
>later, maybe 10 millisieconds. (Check that fact I'm not sure) At
>any rate they are not SCR's. So far I have used non-synchonous
>timing routines and have seen no life problems with relays. We set
>up an accelerated life test on a product that required 72,000
>operations. After 500,000 operations at 130% of rated wattage the
>technician exclaimed "This relay will live longer than me!" Maybe I

> contacts will either make or break.
>>
>> If I were building such a device, I would try the lazy man's
>> way, first. I would look for one of the solid-state relays
>
>My major design constraint is cheap. I can buy a 10 amp rated SPST
>relay for $0.50 in quantity. Can't touch that with a 10 or 12 amp
>rated Triac, as far as I know. I'm controlling heaters for cooking
>appliances at 120 or 240 volts, 800 to 1200 watts.
>
>I'm thinking about staging a life test of an AC line triggered relay,
>to test this theory.

Good idea - if it cuts in and out in a thermostatic way, you could reach its
end of life very quickly. 50 cents isn't cheap if you have to factor in
product recalls and field service... <g> As an aside, do you have any
particular requirements for radiated noise?

> contacts will either make or break.
>>
>> If I were building such a device, I would try the lazy man's
>> way, first. I would look for one of the solid-state relays
>
>My major design constraint is cheap. I can buy a 10 amp rated SPST
>relay for $0.50 in quantity. Can't touch that with a 10 or 12 amp
>rated Triac, as far as I know. I'm controlling heaters for cooking
>appliances at 120 or 240 volts, 800 to 1200 watts.
>
>I'm thinking about staging a life test of an AC line triggered relay,
>to test this theory.

Good idea - if it cuts in and out in a thermostatic way, you could reach its
end of life very quickly. 50 cents isn't cheap if you have to factor in
product recalls and field service... <g> As an aside, do you have any
particular requirements for radiated noise?

> >My major design constraint is cheap. I can buy a 10 amp rated SPST
> >relay for $0.50 in quantity.

> Good idea - if it cuts in and out in a thermostatic way, you could
> reach its end of life very quickly. 50 cents isn't cheap if you
> have to factor in product recalls and field service... <g> As an
> aside, do you have any particular requirements for radiated noise?

I am just getting more familiar with FCC radiated noise standards,
and am in the dark about IEC radiated noise standards. What kinda
gotchas have gotten you?