Clock Losing Time....

Tek does that in their fancy scopes--they heatshrink a sense wire to the line input wire. It also gives them advance notice of power loss.

Cheers

Phil Hobbs

when I visited a power plant eons ago they told they have a clock running on the mains and compare it to an atomic clock, and tweak the frequency to get them in sync over some period.

must be done somewhere central since Europe is all synchronous

-Lasse

I guess you can't expect a lot for $120,000 either.

Run a counter from the oscillator, and a second counter from the AC line. Compare them and adjust the oscillator.

Oh, wait....

if

I have a GE electric range with completely separate GE microwave mounted ab ove it. They each have clocks, totally independent. I use two hands to star t them simultaneously, probably within 100msecs. They NEVER diverge, both d isplay the same time for months on end until the next mains blip resets the m.

Wrong clocks bother me, too.

You may have to press "clear"/"reset" or "clock" at an undocumented point. (The manual is just 500 pages of "don't stick your head in the microwave to get yourself a tan", anyway. :) )

On my ~15 year old GE microwave, when I unplug it and plug it back in, I get:

Lamp test (all segments lit) for ~5 sec. "RESET" displayed. Pressing "clear" at this point blanks the display; the time-of-day clock never appears.

On my unknown age (at least 6 years, probably about 10) GE stove, if power is interrupted, I get: Flashing 12:00 display. I can use the hour+, hour-, min+, min- keys to adjust the time of day. I press "clock". Display stops flashing; hour+/- and min+/- buttons no longer affect the time of day; time-of-day clock runs as normal. I press "clock" again. Display goes blank. I press "clock" again. Flashing display of current time. I can use the hour+, hour-, min+, min- keys to adjust the time of day. ... and so on.

Matt Roberds

Cooking time,anyone? Timed turn-on anyone?

It is not "reference grade", but the frequency is altered at night to compensate for shifts during daylight hours; so the old-fashioned synchronous wall clocks remain (reasonably) accurate. At least that was the story told when i was a kid.

Sure, but a timer isn't a clock.

Given that most things microwave in minutes, and cool off in minutes, would you load food in the morning and program a microwave to start on its own at, say, 6PM, so something is cooked when you get home from work?

I preferred the ones with just the twist timer. Our Raytheon has so many weird buttons and hidden internal states that it's really annoying. One button is EASY COOK. You'd think that it would always start cooking when you push EASY COOK, but it's far more complex than that.

Longterm, the 60 Hz is absolutely accurate. Short term, here in California, it's typically 16.666x millisecond period, as good as you could reasonably expect from something so noisy.

I actually like that approach a lot--it helps keep the PS board completely separate from the main board, which is a win.

Cheers

Phil Hobbs

No, that's not what it means. Every PLL should have a low pass filter at the output of the phase detector. If you have phase disturbances in the reference frequency you simply design the low pass filter to not allow them to pass to the control voltage for the VCO.

Just as the frequency varies. So how would a FLL be superior?

Yes, you want to track the *average*, which you can do just as well with the PLL as you can with the FLL. As others have explained, a FLL is not at all guaranteed to have the same frequency long term if there is any offset in the circuit.

How exactly do you account for missing cycles in a FLL? It would be automatic with a PLL.

You mean the atomic clock is central, right? I doubt the frequency control of the generators is centralized. It is common to use GPS for that sort of thing these days. You have a local control with an internal clock that is synchronized to the received GPS signal. But then the power distribution network predates GPS by many decades and they likely have not bothered to toss out a method that works perfectly well. So I suppose they distribute the central reference signal to every generating station by wire or radio signal.

I know Germany transmits a similar time signal to WWVB here in the US. Is that what they use or does the power system have their own clock?

I have an RCC with an analog dial. When DST goes into effect the clock will run fast to get an hour ahead. When it has to go back an hour in the fall it runs fast for a lot longer, lol. I was up one night when it changed and was amazed at what it was doing. Fortunately it reads the DST state from the time code signal.

I understand that is one of the reasons why they relatively recently changed the modulation to add PM "Enhanced Format". The AM code has no error checking, so one bad bit and a clock can set DST wrong at any given time. The new code includes error checking to make it work right much more often.

Isn't that what duct tape is for?

(and

ed

in

cy

rities

ng

I'll assume in the end they use the mains frequency itself, all of main land Europe is one big connected synchronous grid. So some local powerstati on can't just change the frequency, it would be fighting everyone else

-Lasse

So the power line frequency in my area is a little

I thought all stateside power stations were locked in phase, so they are all the same frequency. It seems like an impossible job, but it seems like they must be. Comments? Mikek

-Lasse

You measure the frequency (or period) of the controlled signal against the frequency of the reference. Then, drive your servo to keep this "frequency difference" within your control tolerance (in a digital system, you never have infinite precision on how much you can modify your timebase).

What do you care if *your* local clock display changes some epsilon

A PLL solution would always have your controlled signal trying to track the actual *phase* of the reference. So, any instantaneous changes in frequency in the reference disturb the controlled signal permanently (because the phase has been altered in the reference).

E.g., imagine getting zero crossings from a (50Hz -- easier math than 60) detector with individual periods of:

A *locked* FLL will have some phase relationship with this reference at the beginning of this sequence. It will persist until the one "bad" cycle is encountered. Thereafter, the phase relationship will change and hold this *new* relationship (the "bad" cycle can have whatever amount of effect on the controlled FREQUENCY that you wish -- based on your filter design -- including *none*).

A PLL would see a discontinuity in phase relationship at that "bad cycle". And, as the reference is now skewed wrt the controlled signal, the PLL will ALTER THE (instantaneous) FREQUENCY of the controlled signal to bring the phase of the reference and controlled signal back into lock.

As to "exactly how": my most recent implementation feeds "LFC events" ostensibly sourced from an ISR (ick!) or hardware timer capture (less real-time impact on the system) to a low priority process that infers the LFC frequency from these "measurements" (assume the local timebase is stable in the short term). From this, the "time per jiffy" is computed and updated. That, in turn, drives the "wall clock" time.

To accommodate lost cycles, line noise, etc. (actual banes are determined by the LFC hardware implementation and *it's* vulnerabilities), I interpose another module that examines the event stream from the ISR (etc.) and tweeks it to apply some commonsense to the signals. E.g., two events separated by

Likewise, the module can inject LFC events IN THEIR ABSENCE retroactively. I.e., it need not inject an event *now* because it believes there SHOULD have been an LFC event "now". Rather, it can afford to wait for *future* events and then "backfill" the missing events -- in essence, rewriting history to keep the control loop running smoothly. I.e., I can have a lengthy dropout -- many LFC cycles "go missing" -- and, AFTER the LFC comes back, I can synthesize the LFC events that WOULD HAVE been generated and feed them into the event queue -- instead of trying to decide "gee, an LFC event *should* have occurred NOW.... and NOW... and NOW, again..."

At the same time, you run a similar loop against the RTC (which you keep to maintain time over power outages). You typically have LESS precision interacting with the RTC (it's notion of time isn't as precise as the timebase against which you have been capturing LFC events). So, you need to take measures to remove the "slop" in the data from the RTC (because it is being updated at a relatively slow rate wrt your high precision timebase and you ideally want to see when it's notion of "the current time" actually comes into effect -- when it's internal counters are updated).

Using the long term LFC as a reference, you compute a correction factor for the RTC's oscillator. You then make this a persistent value. And, periodically, update a persistent snapshot of "last known time that system was running".

All of these data are then used to compensate for the accumulated RTC errors that occurred while the device was powered *off*. If the device has been in the same general environment for that time, the same sort of "error" persists in the internal time tracking for the RTC. So, you get results that mimic those of the run-time correction algorithm (WITHOUT the "run time")

The algorithm that I use to accurately distribute time across the network is a refinement of all of this -- multiple levels of servos trying to keep lots of different devices "in agreement" to a very fine level of precision (which need not have any relationship to the "time" that