COMPGROUPS.NET | Search | Post Question | Groups | Stream | About | Register

### Converting from Y-m-d h:m:s

• Follow

```Hi,

is there any consideration when converting GPS/UTC DateTime YYYY MM DD
HH mm ss to a timespec value to set the system clock, I though I could
find a function to do this easily. Do the leap seconds in UTC have to be
considered when setting the system wall time

Thanks
```
 0

```In article <4BEDCED4.2030900@signaturealpha.com>,
Marc Leclerc  <marc-leclerc@signaturealpha.com> wrote:

>is there any consideration when converting GPS/UTC DateTime YYYY MM DD
>HH mm ss to a timespec value to set the system clock, I though I could
>find a function to do this easily. Do the leap seconds in UTC have to be
>considered when setting the system wall time

If you have a POSIX system, the leap seconds must be *ignored*.  POSIX
requires that "broken down time" in UTC be convertible to time_t
values using a simplistic formula that aliases positive leap seconds
to the following second (i.e., it cannot distinguish between 23:59:60
and 00:00:00) and double-counts negative leap seconds (conveniently,

IEEE Std.1003.1-2001 (the only version I have conveniently to hand)
supplies the following definition of "Seconds Since the Epoch":

tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
(tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400

Using only standard library routines, you could also do:

time_t t;
static struct tm tmzero;
struct tm tm = tmzero;

/* fill in struct tm */

putenv("TZ=");
tzset();
t = mktime(&tm);

This would work even on systems that do not use the broken POSIX
definition (although such are few and far between).  If your system
has it, the timegm() function will do the same thing as the last three
lines but without the side effects on the environment.

-GAWollman
--
Garrett A. Wollman    | What intellectual phenomenon can be older, or more oft
wollman@bimajority.org| repeated, than the story of a large research program
Opinions not shared by| that impaled itself upon a false central assumption
my employers.         | accepted by all practitioners? - S.J. Gould, 1993
```
 0

```On 2010-05-14, Marc Leclerc <marc-leclerc@signaturealpha.com> wrote:
> Hi,
>
> is there any consideration when converting GPS/UTC DateTime YYYY MM DD
> HH mm ss to a timespec value to set the system clock, I though I could
> find a function to do this easily. Do the leap seconds in UTC have to be
> considered when setting the system wall time

AFAIK leapseconds are our of sight as far as UTC is concerned. Ie the
UTC seconds since 1970 are 13 fewer than the actual number of seconds
that someone living from 1970 to now has experienced.
86400*((Y-1970)*365+#leapyears+dayofyear-1)+3600*h+60*m+s
is the number of UTC ( and ntp) seconds since 1970.

Note that ntp has a subroutine to do the conversion from seconds to/from
dates as does gettimeofday.

>
> Thanks
```
 0

```Thanks for your answer, the system I am working on is an ARM Linux based
embedded board. the device is intented for electric utilities and we
must meet good time precision, this device requires 1ms precision but
our next one will require micro second precision therefore I am going
for the bigger goal right away. There will not be any NTP server on the
network, they are rather looking in a mid-future at the precise time
protocol. My first intention was to use NTP with our on board GPS but it
turns out it aint supported and as time grows short going right to the
source may be my only way out. The standard (IEC-61850) demands time as
UTC and the GPS does support giving UTC time, only thing it gives it as
separate entries (Year, Month...). Since the time given by the GPS
already accounts for leap seconds would the formula you sent still give
me proper time if I am to be compared to other system

Thanks again

On 2010-05-14 23:18, Garrett Wollman wrote:
> In article<4BEDCED4.2030900@signaturealpha.com>,
> Marc Leclerc<marc-leclerc@signaturealpha.com>  wrote:
>
>
>> is there any consideration when converting GPS/UTC DateTime YYYY MM DD
>> HH mm ss to a timespec value to set the system clock, I though I could
>> find a function to do this easily. Do the leap seconds in UTC have to be
>> considered when setting the system wall time
>>
> If you have a POSIX system, the leap seconds must be *ignored*.  POSIX
> requires that "broken down time" in UTC be convertible to time_t
> values using a simplistic formula that aliases positive leap seconds
> to the following second (i.e., it cannot distinguish between 23:59:60
> and 00:00:00) and double-counts negative leap seconds (conveniently,
>
> IEEE Std.1003.1-2001 (the only version I have conveniently to hand)
> supplies the following definition of "Seconds Since the Epoch":
>
> 	tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
> 	    (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
> 	    ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
>
> Using only standard library routines, you could also do:
>
> 	time_t t;
> 	static struct tm tmzero;
> 	struct tm tm = tmzero;
>
> 	/* fill in struct tm */
>
> 	putenv("TZ=");
> 	tzset();
> 	t = mktime(&tm);
>
> This would work even on systems that do not use the broken POSIX
> definition (although such are few and far between).  If your system
> has it, the timegm() function will do the same thing as the last three
> lines but without the side effects on the environment.
>
> -GAWollman
>
```
 0

```Garrett Wollman <wollman@bimajority.org> wrote:
> IEEE Std.1003.1-2001 (the only version I have conveniently to hand)
> supplies the following definition of "Seconds Since the Epoch":
>
> 	tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
> 	    (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
> 	    ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400

The problem with that is that he does not have tm_yday available,
so it has to be computed from m and d.
This has to be done carefully.

In the gpsd project, we required this function as well and I went
searching on the internet and found a function that looked simple and
clever (like the above).

But, on Jan 1st 2008 it failed.  The result was off-by-one-day in
leapyears on days before Mar 1st.

Lesson learned again: functions that process dates need to be tested
very throughly, as there is always a high risk of bugs.

You could use the function that is in gpsd today (mkgmtime in gpsutils.c),
but I won't guarantee that there are no more bugs.
```
 0

```In article <4BEE2377.3040805@signaturealpha.com>,
Marc Leclerc <marc-leclerc@signaturealpha.com> writes:

>Thanks for your answer, the system I am working on is an ARM Linux based
>embedded board. the device is intented for electric utilities and we
>must meet good time precision, this device requires 1ms precision but
>our next one will require micro second precision therefore I am going
>for the bigger goal right away. There will not be any NTP server on the
>network, they are rather looking in a mid-future at the precise time
>protocol. My first intention was to use NTP with our on board GPS but it
>turns out it aint supported and as time grows short going right to the
>source may be my only way out. The standard (IEC-61850) demands time as
>UTC and the GPS does support giving UTC time, only thing it gives it as
>separate entries (Year, Month...). Since the time given by the GPS
>already accounts for leap seconds would the formula you sent still give
>me proper time if I am to be compared to other system

There are two issues: UTC and Posix.

UTC hickups occasionally when leap seconds are inserted.  If you
have a good watch, you will have to reset it to stay on the right time.

Posix time pretends that leap seconds don't exist.  If you
subtract two posix times that straddle one or more leap seconds
you will get the wrong answer.

Some GPS units give you a choice of GPS time or UTC.  If you use
UTC, the GPS box is doing the leap second correction.  If you convert
UTC time (YY-MM-DD) to Posix, you will get the right answer.  If you
convert GPS time (YY-MM-DD) to Posix, you will be off by the number
of leap seconds since GPS time started.

That offset is sent by the GPS satellites.  Some GPS units make it
available on their serial port messages.

--
These are my opinions, not necessarily my employer's.  I hate spam.

```
 0

```Marc Leclerc wrote:
> Thanks for your answer, the system I am working on is an ARM Linux based
> embedded board. the device is intented for electric utilities and we
> must meet good time precision, this device requires 1ms precision but
> our next one will require micro second precision therefore I am going
> for the bigger goal right away.

'Question on the side:

Are you really aiming for "True(TM)" time or
sitting syncronous on the AC cycles (50Hz/60Hz) ?

uwe
```
 0

```Hi,

I am looking to stay on true time, the real issue here in those
installation is not realy having the perfect time but that all the
device in the field have the same time. There are new ways to acheive
this  such as IEEE 1588 but since no one is ready for this using GPS
device is our closest friend. But it's funny you asked, soon we will
tackel simple synchronous switching of breaker and then we'll have to
keep up with the AC cycles

On 2010-05-15 05:04, Uwe Klein wrote:
> Marc Leclerc wrote:
>> Thanks for your answer, the system I am working on is an ARM Linux
>> based embedded board. the device is intented for electric utilities
>> and we must meet good time precision, this device requires 1ms
>> precision but our next one will require micro second precision
>> therefore I am going for the bigger goal right away.
>
> 'Question on the side:
>
> Are you really aiming for "True(TM)" time or
> sitting syncronous on the AC cycles (50Hz/60Hz) ?
>
> uwe
>
> _______________________________________________
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>
>
>
```
 0

```unruh wrote:
> On 2010-05-14, Marc Leclerc<marc-leclerc@signaturealpha.com>  wrote:
>> Hi,
>>
>> is there any consideration when converting GPS/UTC DateTime YYYY MM DD
>> HH mm ss to a timespec value to set the system clock, I though I could
>> find a function to do this easily. Do the leap seconds in UTC have to be
>> considered when setting the system wall time
>
> AFAIK leapseconds are our of sight as far as UTC is concerned. Ie the
> UTC seconds since 1970 are 13 fewer than the actual number of seconds
> that someone living from 1970 to now has experienced.
> 86400*((Y-1970)*365+#leapyears+dayofyear-1)+3600*h+60*m+s
> is the number of UTC ( and ntp) seconds since 1970.
>
> Note that ntp has a subroutine to do the conversion from seconds to/from
> dates as does gettimeofday.

Yes: Use the Source!

I believe I was involved with at least one of the rewrites of the ntp
internal to/from date/time functions.

In short:

Going from YMDHMS to unix (or ntp) seconds is really quite trivial,
while the opposite direction is much harder!

My most efficient algorithm for the reverse function needs somewhere
between 30 and 50 clock cycles (compare with 40 cycles for a single DIV
opcode...), while the forward function is about twice as fast:

(This is the YMD to day# part only, the rest is trivial, right?)

/* ymd.c Terje Mathisen 2000-01-20. Code for calendar operations
* Modified 2001-11-28, using ideas from peter@horizon.com
* Updated 2005-04 with alternative ideas from IBM (Not used!)
*
* Assumes a two's complement binary machine, using arithmetic
* right shift for signed ints, but is otherwise
* portable to any machine with an ANSI C compiler.
*
* if USE_UNSIGNED_MASK is defined, then the current code will run on
any machine
* using at least 29 (with division) or 26 bits (MUL only) for an
unsigned int.
*
* The table-less IBM approach requires at least 31 bits
*/
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#ifdef USE_UNSIGNED_SHIFT

#else

#endif

/* These operations are valid for any date after 1584,
* according to the Gregorian (modern) calendar
*/

#define STARTYEAR 0	/* Must be divisible by 400! */
/* Day zero is STARTYEAR-03-01

/* Table to simplify conversions between mm-dd and day_in_year */
static short daysToMonth[13] =
{-1,30,60,91,121,152,183,213,244,274,305,336,366};

unsigned ymd2days(unsigned y, unsigned m, unsigned d)
{
unsigned days, y100;

/* Start by setting March = month zero: */
/* Mask will now be in the (mask_t) -2 to 9 range, a shift by 4 is
enough to make it -1 or 0: */

m += (mask & 12);               /* and increment the month: The
year starts in March! */
y -= STARTYEAR;
y100 = y / 100;                 /* Centuries for leap year calc */
days = y * 365 + (y >> 2) - y100 + (y100 >> 2);
days += (unsigned) daysToMonth[m] + d;
return days;
}

void days2ymd(unsigned days, unsigned *yy, unsigned *mm, unsigned *dd)
{
unsigned y400, y100, y, m, d, gd;

/* Start by subtracting any full 400-year cycles: */
y400 = days / 146097;
days -= y400 * 146097;

#if 0
/* Very good approximation to the number of years, will be wrong
* (too high) 257 times
* in a 400-year cycle, i.e. in 0.18% of all calls.
*/

/* A good compiler will replace this with a scaled reciprocal MUL! */
y = (days + 1) * 400 / 146096;
#else
/* Useful and faster approximation to the number of years, will be wrong
* (one too high) 910 times
* in a 400-year cycle, i.e. in 0.62% of all calls.
*
* Requires unsigned values with up to 29 significant bits!
*/
y = (days * 2871 + 1983) >> 20;
/* peter (at) horizon.com suggested this
* formula which is slightly more accurate but
* needs a full 32-bit unsigned temporary:
/*    y = (days * 22967 + 59235) >> 23; */
#endif

/* Calculate # of centuries:
* Since y will be in the 0 to 400 range, the following
* approximation can be used instead of a division by 100:
* y100 = y / 100;  ~ (y * 41) >> 12;
*/
y100 = (y * 41) >> 12;

/* # of days in those full years */
gd = y * 365		/* Normal years */
+ (y >> 2)		/* + leap years every 4 years */
- y100			/* - missing century leap years */
+ (y100 >> 2);  /* + every 400 years */

/* test for the small chance of a wrong year: */
if (gd > days) {
y--;	/* y will be in the [0-399] range! */
y100 = (y * 41) >> 12;
/* The 400-year correction can be skipped! */
gd = y * 365 + (y >> 2) - y100 /* + (y100 >> 2) */;
}

/* Calculate the offset into the current year: */
days -= gd;
/* Correct for starting date and 400-year cycles: */
y += STARTYEAR + y400 * 400;

#if 1
/* Make a FAST guess at the current month, can be too low: */
m = days >> 5;

/* mask will be in the -18 to 18 range, use shift by 5: */
/* If the guess was wrong then the mask will be -1, otherwise 0: */

/* Increment month if needed */

/* The remainder is the day of the month */
d = days - (unsigned) daysToMonth[m];

/* Correct for the March 1 starting point: */
m += 3;
m -= (unsigned) (mask & 12);

#else
/* Based on code from an IBM report: Slightly slower, but
* uses no table lookups!
* Needs 31-bit unsigned ints:
*/
m = ((days + 31) * 1071);
d = (((m & 0x7fff) * 62669) >> 26) + 1;
m >>= 15;

m += 2;
m -= (unsigned) (mask & 12);
#endif

*yy = y; *mm = m; *dd = d;
}

int baddate(unsigned y, unsigned m, unsigned d)
{
static unsigned char daysInMonth[12] =
{31,29,31,30,31,30,31,31,30,31,30,31};
if (m < 1 || m > 12) return 1;
if (d < 1 || d > daysInMonth[m-1]) return 1;
if (m == 2 && d == 29) {
if (y & 3) return 1;
if (y % 400 != 0 && y % 100 == 0) return 1;
}
return 0;
}

int main(int argc, char* argv[])
{
unsigned days, y, m, d, dd, startday;
clock_t clocks;
int mhz = 0;

static double ms_per_clock = 1000.0 / (double) CLOCKS_PER_SEC;

if (argc > 1) {
mhz = atoi(argv[1]);
if (mhz <= 0) {
printf("Usage: %s [mhz]\n", argv[0]);
return 1;
}
}

startday = ymd2days(1200, 3, 1);
days2ymd(startday, &y, &m, &d);
printf("Starting %u-%02u-%02u\n", y, m, d);
clocks = clock();
for (days = startday; days < startday + 146097 * 2000; days++) {
days2ymd(days, &y, &m, &d);
#if 1
dd = ymd2days(y, m, d);
if (dd != days || baddate(y, m, d)) {
printf("Error: %u -> %u-%02u-%02u -> %u!\n", days, y, m, d,
dd);
days2ymd(days, &y, &m, &d);
dd = ymd2days(y, m, d);
}
#endif
}
clocks = clock() - clocks;
printf("Ending %u-%02u-%02u\nUsed %1.0fms (%1.1fns/iteration)\n",
y, m, d,
clocks * ms_per_clock,
clocks * ms_per_clock * 1e6 / (days - startday));
if (mhz > 0) {
printf("%1.1f clock cycles/iteration\n",
clocks * ms_per_clock * (1e-3 * 1e6) * mhz /
(days - startday));
}

return 0;
}

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
```
 0

```Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> Going from YMDHMS to unix (or ntp) seconds is really quite trivial,
> while the opposite direction is much harder!
>
> My most efficient algorithm for the reverse function needs somewhere
> between 30 and 50 clock cycles (compare with 40 cycles for a single DIV
> opcode...), while the forward function is about twice as fast:

Have you seen how glibc approaches this conversion?
```
 0

```Marc Leclerc wrote:
> Hi,
>
> I am looking to stay on true time, the real issue here in those
> installation is not realy having the perfect time but that all the
> device in the field have the same time. There are new ways to acheive
> this such as IEEE 1588 but since no one is ready for this using GPS
> device is our closest friend. But it's funny you asked, soon we will
> tackel simple synchronous switching of breaker and then we'll have to
> keep up with the AC cycles

This is actually somewhat easier:

You only need 8 or 10 ms accuracy to do this, in order to determine the
start of each 50 or 60 Hz cycle, then you phaselock your switch to the
AC cycles.

Terje
>
> On 2010-05-15 05:04, Uwe Klein wrote:
>> Marc Leclerc wrote:
>>> Thanks for your answer, the system I am working on is an ARM Linux
>>> based embedded board. the device is intented for electric utilities
>>> and we must meet good time precision, this device requires 1ms
>>> precision but our next one will require micro second precision
>>> therefore I am going for the bigger goal right away.
>>
>> 'Question on the side:
>>
>> Are you really aiming for "True(TM)" time or
>> sitting syncronous on the AC cycles (50Hz/60Hz) ?
>>
>> uwe
>>
>> _______________________________________________
>> questions mailing list
>> questions@lists.ntp.org
>> http://lists.ntp.org/listinfo/questions
>>
>>
>>

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
```
 0

```Rob wrote:
> Terje Mathisen<"terje.mathisen at tmsw.no">  wrote:
>> Going from YMDHMS to unix (or ntp) seconds is really quite trivial,
>> while the opposite direction is much harder!
>>
>> My most efficient algorithm for the reverse function needs somewhere
>> between 30 and 50 clock cycles (compare with 40 cycles for a single DIV
>> opcode...), while the forward function is about twice as fast:
>
> Have you seen how glibc approaches this conversion?

No, but as I noted in the source code, my algorithm turned out to be
quite similar to what IBM developed for mainframes. I wouldn't be
surprised to learn that other programmers have ended up with similar code.

The key idea is to realize that when you have a function and its much
slower inverse, then you can implement the slow function by making a
fast guess of what the answer should be, test the guess using the fast
forward function, and then correct if needed.
....
From offtime.c (glibc 2.1.3):
#define DIV(a, b) ((a) / (b) - ((a) % (b) < 0))
#define LEAPS_THRU_END_OF(y) (DIV (y, 4) - DIV (y, 100) + DIV (y, 400))

while (days < 0 || days >= (__isleap (y) ? 366 : 365))
{
/* Guess a corrected year, assuming 365 days per year.  */
long int yg = y + days / 365 - (days % 365 < 0);

/* Adjust DAYS and Y to match the guessed year.  */
days -= ((yg - y) * 365
+ LEAPS_THRU_END_OF (yg - 1)
- LEAPS_THRU_END_OF (y - 1));
y = yg;
}

The code here is actually both significantly slower and larger (in code
space) than mine. :-)

It knows that time zone offsets are less than 24 (actually 13 or 14?)
hours, which means that most adjustments will stay within the same day
or worst case add/subtract a day.

However, since the latter happens on average 25%+ of the calls (at least
for those of you in the US), it would be faster to simply convert the
struct tm array to seconds, add/subtract the offset, then convert back.

This also gets rid of pretty much all of the offset calculation code. :-)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
```
 0

```Terje Mathisen wrote:
> Marc Leclerc wrote:
>
>> Hi,
>>
>> I am looking to stay on true time, the real issue here in those
>> installation is not realy having the perfect time but that all the
>> device in the field have the same time. There are new ways to acheive
>> this such as IEEE 1588 but since no one is ready for this using GPS
>> device is our closest friend. But it's funny you asked, soon we will
>> tackel simple synchronous switching of breaker and then we'll have to
>> keep up with the AC cycles
>
>
> This is actually somewhat easier:
>
> You only need 8 or 10 ms accuracy to do this, in order to determine the
> start of each 50 or 60 Hz cycle, then you phaselock your switch to the
> AC cycles.

There is a (massive?) hitch.
The grid 24h average is held to the nominal frequency.

so you need to sync all boxes to the _same_ zerocrossing in a
"variable frequency" domain with the help of a "true time" source.
not easy.

uwe
```
 0

```On 2010-05-16, Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
> Terje Mathisen wrote:
>> Marc Leclerc wrote:
>>
>>> Hi,
>>>
>>> I am looking to stay on true time, the real issue here in those
>>> installation is not realy having the perfect time but that all the
>>> device in the field have the same time. There are new ways to acheive
>>> this such as IEEE 1588 but since no one is ready for this using GPS
>>> device is our closest friend. But it's funny you asked, soon we will
>>> tackel simple synchronous switching of breaker and then we'll have to
>>> keep up with the AC cycles
>>
>>
>> This is actually somewhat easier:
>>
>> You only need 8 or 10 ms accuracy to do this, in order to determine the
>> start of each 50 or 60 Hz cycle, then you phaselock your switch to the
>> AC cycles.
>
> There is a (massive?) hitch.
> The grid 24h average is held to the nominal frequency.
>
> Shortterm frequency is load dependent.
>
> so you need to sync all boxes to the _same_ zerocrossing in a
> "variable frequency" domain with the help of a "true time" source.
> not easy.

Well, it cannot be very dependent, since loads are all shared these
days. That means that all providers have to have exactly the same phase
or your get cross feeds(generator A dumps its current into generator B
without having gone through any houses along the route. See the massive
east coast power blackout where one generator system lost phase
cascading to automatic shutoffs of the whole east coast)
And the easiest way is to hold absolute phase against an external time
standard.
>
> uwe
```
 0

```unruh wrote:
> On 2010-05-16, Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
>
>>Terje Mathisen wrote:
>>
>>>Marc Leclerc wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I am looking to stay on true time, the real issue here in those
>>>>installation is not realy having the perfect time but that all the
>>>>device in the field have the same time. There are new ways to acheive
>>>>this such as IEEE 1588 but since no one is ready for this using GPS
>>>>device is our closest friend. But it's funny you asked, soon we will
>>>>tackel simple synchronous switching of breaker and then we'll have to
>>>>keep up with the AC cycles
>>>
>>>
>>>This is actually somewhat easier:
>>>
>>>You only need 8 or 10 ms accuracy to do this, in order to determine the
>>>start of each 50 or 60 Hz cycle, then you phaselock your switch to the
>>>AC cycles.
>>
>>There is a (massive?) hitch.
>>The grid 24h average is held to the nominal frequency.
>>
>>
>>so you need to sync all boxes to the _same_ zerocrossing in a
>>"variable frequency" domain with the help of a "true time" source.
>>not easy.
>
>
> Well, it cannot be very dependent, since loads are all shared these
> days. That means that all providers have to have exactly the same phase
> or your get cross feeds(generator A dumps its current into generator B
> without having gone through any houses along the route. See the massive
> east coast power blackout where one generator system lost phase
> cascading to automatic shutoffs of the whole east coast)

In a (widearea or not) homogenous AC grid the frequency goes down if
net energy is taken out and goes up when energy is pushed in.
( energy stored in the grid is proportional to f and U )
From a powerstation viewpoint you directly control input "torque" (energy in/out, phase)
and only in result the frequency.

> And the easiest way is to hold absolute phase against an external time
> standard.

You don't, you target to match average frequency to the reference frequency.
( Thats why AC referenced clocks have good longtime but bad shorttime timekeeping.)

Controlling a widearea AC grid is quite a bit more involved
than meets the eye on first blush.

uwe

```
 0

```On 2010-05-16, Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
> unruh wrote:
>> On 2010-05-16, Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
>>
>>>Terje Mathisen wrote:
>>>
>>>>Marc Leclerc wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>I am looking to stay on true time, the real issue here in those
>>>>>installation is not realy having the perfect time but that all the
>>>>>device in the field have the same time. There are new ways to acheive
>>>>>this such as IEEE 1588 but since no one is ready for this using GPS
>>>>>device is our closest friend. But it's funny you asked, soon we will
>>>>>tackel simple synchronous switching of breaker and then we'll have to
>>>>>keep up with the AC cycles
>>>>
>>>>
>>>>This is actually somewhat easier:
>>>>
>>>>You only need 8 or 10 ms accuracy to do this, in order to determine the
>>>>start of each 50 or 60 Hz cycle, then you phaselock your switch to the
>>>>AC cycles.
>>>
>>>There is a (massive?) hitch.
>>>The grid 24h average is held to the nominal frequency.
>>>
>>>
>>>so you need to sync all boxes to the _same_ zerocrossing in a
>>>"variable frequency" domain with the help of a "true time" source.
>>>not easy.
>>
>>
>> Well, it cannot be very dependent, since loads are all shared these
>> days. That means that all providers have to have exactly the same phase
>> or your get cross feeds(generator A dumps its current into generator B
>> without having gone through any houses along the route. See the massive
>> east coast power blackout where one generator system lost phase
>> cascading to automatic shutoffs of the whole east coast)
>
> In a (widearea or not) homogenous AC grid the frequency goes down if
> net energy is taken out and goes up when energy is pushed in.
> ( energy stored in the grid is proportional to f and U )
>  From a powerstation viewpoint you directly control input "torque" (energy in/out, phase)
> and only in result the frequency.
>
> > And the easiest way is to hold absolute phase against an external time
> > standard.
>
> You don't, you target to match average frequency to the reference frequency.
> ( Thats why AC referenced clocks have good longtime but bad shorttime timekeeping.)

As I said, that is not good enough. If you have a generator in Niagra
Falls and another in James Bay both feeding New York, if the phases
differ even by a small amount that is a huge amount of power sloshing
back and forth between Niagra and James bay doing nothing but heating
wires and burning out generators. You want to make sure that those two
have exactly the same phase (to much better than a degree) at all times.
Long term averages are not good enough. You can burn out systems ( but
more likely trip breakers and send nuclear reactors into emergency
shutdown mode) if your phases are mismatched. And that can take days to
bring back up again.
If your generator is the only one on the circuit, you can be sloppy,
but now adays, noone's is isolated. They are all part of huge grids.

>
> Controlling a widearea AC grid is quite a bit more involved
> than meets the eye on first blush.

It sure is. And phase control is part of that.

>
> uwe
>
```
 0

```Uwe,

In the very early history of the Internet, the ubiquitous Fuzzball
routers (and the time they provided to other hosts) were synchronized to
the power grid. There are three grids in the country, East of the
Rockies, West of the Rockies and Texas. Each is an island loosely
synchronized to civil time, more or less. I have graphs of the Eastern
grid in August, in which the time slips by up to five seconds during the
day and makes it up overnight. Since the Fuzzballs ran off the same
power grid, the only thing the time synchronization protocol (Hellospeak
at the time) was to set the clock from the WWVB receiver once at the
server and slew the offsets of the clients to the same value. Frequency
discipline was not necessary. The folks in Ohio managed the grid
generators as the load waxed and waned to keep the average offset from
civil time small, so the Fuzzballs in principle needed only to
synchronize only once. The Fuzzballs ran this way for several years
until the line-frequency clock was replaced by one driven from a crystal.

Since the Fuzzballs at the Earth stations in the US, UK, Norway, Germany
and Italy were synchronized to the various national grids, I had the
chance to measure the offset of each grid over a period of days. Norway,
which largely relies on hydro, was, excuse me, rather awful and did not
cling closely to civil time. The UK was somewhat better, but still
varied up to ten seconds over the day. The UK doesn''t have such wide
load variations as the US in August, so I inquired about the reason. I
was told the principal contributor to load variations was TV sets, where
the highest load is in the evening. With this understanding, I
volunteered to the BBC to provide a rating service where the number of
viewers could be calibrated by the time lag of the power grid. They
thought this was pretty funny, but didn't take me up on the offer.

Dave

Uwe Klein wrote:

> Terje Mathisen wrote:
>
>> Marc Leclerc wrote:
>>
>>> Hi,
>>>
>>> I am looking to stay on true time, the real issue here in those
>>> installation is not realy having the perfect time but that all the
>>> device in the field have the same time. There are new ways to acheive
>>> this such as IEEE 1588 but since no one is ready for this using GPS
>>> device is our closest friend. But it's funny you asked, soon we will
>>> tackel simple synchronous switching of breaker and then we'll have to
>>> keep up with the AC cycles
>>
>>
>>
>> This is actually somewhat easier:
>>
>> You only need 8 or 10 ms accuracy to do this, in order to determine
>> the start of each 50 or 60 Hz cycle, then you phaselock your switch
>> to the AC cycles.
>
>
> There is a (massive?) hitch.
> The grid 24h average is held to the nominal frequency.
>
> Shortterm frequency is load dependent.
>
> so you need to sync all boxes to the _same_ zerocrossing in a
> "variable frequency" domain with the help of a "true time" source.
> not easy.
>
> uwe
>
> _______________________________________________
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
```
 0

```unruh wrote:
> On 2010-05-16, Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
>
>>unruh wrote:
>>
>>>On 2010-05-16, Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
>>>
>>>
>>>>Terje Mathisen wrote:
>>>>
>>>>
>>>>>Marc Leclerc wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I am looking to stay on true time, the real issue here in those
>>>>>>installation is not realy having the perfect time but that all the
>>>>>>device in the field have the same time. There are new ways to acheive
>>>>>>this such as IEEE 1588 but since no one is ready for this using GPS
>>>>>>device is our closest friend. But it's funny you asked, soon we will
>>>>>>tackel simple synchronous switching of breaker and then we'll have to
>>>>>>keep up with the AC cycles
>>>>>
>>>>>
>>>>>This is actually somewhat easier:
>>>>>
>>>>>You only need 8 or 10 ms accuracy to do this, in order to determine the
>>>>>start of each 50 or 60 Hz cycle, then you phaselock your switch to the
>>>>>AC cycles.
>>>>
>>>>There is a (massive?) hitch.
>>>>The grid 24h average is held to the nominal frequency.
>>>>
>>>>
>>>>so you need to sync all boxes to the _same_ zerocrossing in a
>>>>"variable frequency" domain with the help of a "true time" source.
>>>>not easy.
>>>
>>>
>>>Well, it cannot be very dependent, since loads are all shared these
>>>days. That means that all providers have to have exactly the same phase
>>>or your get cross feeds(generator A dumps its current into generator B
>>>without having gone through any houses along the route. See the massive
>>>east coast power blackout where one generator system lost phase
>>>cascading to automatic shutoffs of the whole east coast)
>>
>>In a (widearea or not) homogenous AC grid the frequency goes down if
>>net energy is taken out and goes up when energy is pushed in.
>>( energy stored in the grid is proportional to f and U )
>> From a powerstation viewpoint you directly control input "torque" (energy in/out, phase)
>>and only in result the frequency.
>>
>>
>>>And the easiest way is to hold absolute phase against an external time
>>>standard.
>>
>>You don't, you target to match average frequency to the reference frequency.
>>( Thats why AC referenced clocks have good longtime but bad shorttime timekeeping.)
>
>
> As I said, that is not good enough. If you have a generator in Niagra
> Falls and another in James Bay both feeding New York, if the phases
> differ even by a small amount that is a huge amount of power sloshing
> back and forth between Niagra and James bay doing nothing but heating
> wires and burning out generators.

The grid as a distributed "very big flywheel" is about the best paradigm
to visualise the mechanics.

You insert energy by positive torque. ( Higher voltage, leading phase )
You remove energy by negative torque. ( Lower voltage, lagging phase )

Imbalance leads to rpm ( here frequency) increase or decrease.
( You don't control the grid via partial brownout! )

uwe
```
 0

```David Mills wrote:
> Uwe,
>
> With this understanding, I
> volunteered to the BBC to provide a rating service where the number of
> viewers could be calibrated by the time lag of the power grid. They
> thought this was pretty funny, but didn't take me up on the offer.

Afair a similar scheme was used in Germany to do early viewer estimations.
Other methods hooked into municipal water providers. ( People taking a leak
after "Tatort" or "Der Kommisar" )
Then they did viewer voting via lightbulb switching. Ha, the joys of
innovative missuse.

uwe

```
 0

18 Replies
354 Views

Similiar Articles:

7/24/2012 12:41:57 PM