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

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,
we've never had any).

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

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

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,
> we've never had any).
>
> 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 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.

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.

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

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
>
>
>

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>

/* #define USE_UNSIGNED_MASK */

#ifdef USE_UNSIGNED_SHIFT
typedef unsigned mask_t;

# define INC_IF_MASK(x,mask) ((x) += (mask) & 1)
# define DEC_IF_MASK(x,mask) ((x) -= (mask) & 1)
#else
typedef int mask_t;

# define INC_IF_MASK(x,mask) ((x) -= (mask))
# define DEC_IF_MASK(x,mask) ((x) += (mask))
#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_t mask = (mask_t) (m -= 3);
	/* Mask will now be in the (mask_t) -2 to 9 range, a shift by 4 is 
enough to make it -1 or 0: */
	mask >>= 4;

     DEC_IF_MASK(y, mask);			/* Decrement year if jan/feb */
     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;
	mask_t mask;

     /* 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 = (mask_t) daysToMonth[m+1] - (mask_t) days;
	/* mask will be in the -18 to 18 range, use shift by 5: */
     mask >>= 5;
     /* If the guess was wrong then the mask will be -1, otherwise 0: */

     /* Increment month if needed */
     INC_IF_MASK(m, mask);

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

     /* Correct for the March 1 starting point: */
     mask = (mask_t) (9 - m) >> 4;
     m += 3;
     INC_IF_MASK(y, mask);
     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;

	mask = (mask_t) (10 - m) >> 4;
	m += 2;
	INC_IF_MASK(y, mask);
	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"

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?

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"

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"

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

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

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.
>>
>>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)

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

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.
>>>
>>>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)
>
> 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
>

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

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.
>>>>
>>>>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)
>>
>>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. 

Please read up on Power Grid Management basics.

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

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