My setup is pretty simple indeed. This is 9.830400MHZ OCXO which
clocking MCU. Then it is Zero-Cross detector which connected to capture
timer.
The MCU counting the intervals between of each zero-cross event and
number of events occurred.
if (htim->Instance == TIM5 && htim->Channel ==
HAL_TIM_ACTIVE_CHANNEL_1) {
uwIC2Value2 = (HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1));
if (uwIC2Value2 >= prevtimer) {
uwDiffCapture = (uwIC2Value2 - prevtimer);
} else {
uwDiffCapture =((0xFFFFFFFF - prevtimer) + uwIC2Value2);
}
prevtimer = uwIC2Value2;
// MAIN Time calculation
if(++uwCapT > 59) { // Every 60 cycles (60hz)
if(++maintime.Seconds > 59) {
maintime.Seconds = 0;
if(++maintime.Minutes > 59) {
maintime.Minutes = 0;
if(++maintime.Hours > 23)
maintime.Hours = 0;
}
}
uwCapT = 0;
}
Once an hour the program prints its internal clock (MCU time), RTC time
and MAIN time
The graph shows the "delta" between of RTC and MAIN.
On 2017-12-15 12:14, Jeremy Nichols wrote:
I'm surprised Vlad is seeing as much as six seconds differential but
maybe I don't understand the experiment. I've done measurements of the
line frequency here in California and never seen much variation.
Jeremy
On Fri, Dec 15, 2017 at 9:02 AM Vlad time@patoka.org wrote:
I have one of my project boxes, which monitor the main freq. Here is
graph which reflect the time difference between of RTC (based on
number
of pulses from OCXO) and the "MAIN TIME" which is based on number of
zero-cross events.
The observation period is 486 hours.
On 2017-12-14 23:13, Jim Harman wrote:
On Thu, Dec 14, 2017 at 10:53 PM, Bob kb8tq kb8tq@n1k.org wrote:
Of course this assumes an electronic approach. Given that
it’s
moving
pretty slow and you
only are looking at fractions of a millisecond, one could do an
electro
mechanical design …...
Bob
There is interesting background on power grid frequency/time
adjustment
procedures here
--
WBW,
V.P._______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Sent from my iPad 4.
--
WBW,
V.P.
Hi
It depends a lot on just where you are and how the “gird” is managed. Many years
ago, we figured out that the local power company corrected things between 4 and 5 PM.
It became a habit to fire up WWV and watch them slip seconds one way or the other. A
ten second delta was not at all unusual. ( as in 10 seconds over the hour …). Our
guess (later confirmed) was that they ran local generation part of the day (independent
of the grid) and then went over to interconnect.
Bob
On Dec 15, 2017, at 12:14 PM, Jeremy Nichols jn6wfo@gmail.com wrote:
I'm surprised Vlad is seeing as much as six seconds differential but maybe
I don't understand the experiment. I've done measurements of the line
frequency here in California and never seen much variation.
Jeremy
On Fri, Dec 15, 2017 at 9:02 AM Vlad time@patoka.org wrote:
I have one of my project boxes, which monitor the main freq. Here is
graph which reflect the time difference between of RTC (based on number
of pulses from OCXO) and the "MAIN TIME" which is based on number of
zero-cross events.
The observation period is 486 hours.
On 2017-12-14 23:13, Jim Harman wrote:
On Thu, Dec 14, 2017 at 10:53 PM, Bob kb8tq kb8tq@n1k.org wrote:
Of course this assumes an electronic approach. Given that it’s
moving
pretty slow and you
only are looking at fractions of a millisecond, one could do an
electro
mechanical design …...
Bob
There is interesting background on power grid frequency/time
adjustment
procedures here
--
WBW,
V.P._______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Sent from my iPad 4.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Jeremy wrote:
I'm surprised Vlad is seeing as much as six seconds differential but maybe
I don't understand the experiment. I've done measurements of the line
frequency here in California and never seen much variation.
When was the earliest time (year) you started looking seriously at the
offset/frequency of your grid? (California is part of the [North
American] Western Interconnection.)
I have only closely observed the line frequency and offset when I have
been living within the Eastern Interconnection. For years and years
between the 1960s and the 1980s, it was not unusual to observe offsets
of +/- 30 seconds, and +/- 60 seconds was not unheard of. I believe the
policy has always been to provide 5.184e6 cycles per 24-hour day, so the
I then didn't pay any attention to the mains frequency until the late
aughties, and I found that things have changed. Now, I rarely see
offsets greater than +/- 4 to 6 seconds (very rarely, +/- 15 seconds) --
but it does not follow a gaussian distribution, to my (totally
anecdotal) observation. It appears to me (again, completely
anecdotally) that it is more often within the lowest 25% or the highest
25% [combined] than it is the middle 50%, indicating a process that is
being controlled with a marginally stable loop. (Of course, it is
being controlled -- with a massively distributed feedback system. So no
surprise there.)
Best regards,
Charles
Yo All!
Jeremy wrote:
I'm surprised Vlad is seeing as much as six seconds differential
but maybe I don't understand the experiment. I've done measurements
of the line frequency here in California and never seen much
variation.
I live in Central Oregon. Next to the Pacific Intertie and the Paccific
DC Intertie. Near the Round Butte Dam, Pelton Dam, and other power
generating dams.
The Interties connect the massive hydropower generation of the Columbia
River system with southern California.
The hypropower system includes the best technology of the 1930's, 1940's
and 1950's.
I've had converstations with some of the dam operators about how
they keep frequency. Pretty simple really. Huge tonnages of spinning
steel and copper being pushed by falling water. The water is regulated
by flapper valves. Pretty stable short term.
Now imagine when a 300MVA intertie blows over, or is burned by a fire,
and instantly disconnects. Or a steel mill shuts down for the day, or...
The electrical backpressure to the generators drops, so the generators
speed up, increasing the line frequency and voltage.
When this happens, the dam operators literally pick up the phone, and
talk to the other dams to decide what to do. Usually that involves
one or more dams closing down a few flapper vavles.
That is how the short term frequency of your local power line is
controlled.
The control room also has a AC synchronous clock, off the power line,
and an accurate digital clock. Once a day they manually get the
AC clock to agree with the digital clocl.
None of this is rocket science, don't use it for anything you need
any accuracy for.
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
I sent a note to Vlad off-list about the bug in the MCU code, but it's worth a reminder to the list as well since many of you are programmers and this arcane issue comes up every once in a while here and on the web.
The way to compute time differences of free-running binary time counters is subtraction. One line of code. There is no need to special case overflow / rollover / wraparound. It is the very nature of unsigned or 2's compliment signed binary arithmetic that subtraction is sufficient. So the bug-free code is just this:
uwIC2Value2 = (HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1));
uwDiffCapture = (uwIC2Value2 - prevtimer);
prevtimer = uwIC2Value2;
If you'd like a simple example why this is correct and a demonstration of what the bug was, see:
http://leapsecond.com/tools/deltatim.c
/tvb
----- Original Message -----
From: "Vlad" time@patoka.org
To: "Jeremy Nichols" jn6wfo@gmail.com
Cc: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Friday, December 15, 2017 9:41 AM
Subject: Re: [time-nuts] accurate 60 hz reference chips/ckts
My setup is pretty simple indeed. This is 9.830400MHZ OCXO which
clocking MCU. Then it is Zero-Cross detector which connected to capture
timer.
The MCU counting the intervals between of each zero-cross event and
number of events occurred.
if (htim->Instance == TIM5 && htim->Channel ==
HAL_TIM_ACTIVE_CHANNEL_1) {
uwIC2Value2 = (HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1));
if (uwIC2Value2 >= prevtimer) {
uwDiffCapture = (uwIC2Value2 - prevtimer);
} else {
uwDiffCapture =((0xFFFFFFFF - prevtimer) + uwIC2Value2);
}
prevtimer = uwIC2Value2;
// MAIN Time calculation
if(++uwCapT > 59) { // Every 60 cycles (60hz)
if(++maintime.Seconds > 59) {
maintime.Seconds = 0;
if(++maintime.Minutes > 59) {
maintime.Minutes = 0;
if(++maintime.Hours > 23)
maintime.Hours = 0;
}
}
uwCapT = 0;
}
Once an hour the program prints its internal clock (MCU time), RTC time
and MAIN time
The graph shows the "delta" between of RTC and MAIN.