[time-nuts] Low cost synchronization
cfmd at bredband.net
Sun Aug 21 14:40:40 EDT 2005
From: "Poul-Henning Kamp" <phk at phk.freebsd.dk>
Subject: Re: [time-nuts] Low cost synchronization
Date: Sun, 21 Aug 2005 20:24:47 +0200
Message-ID: <58785.1124648687 at phk.freebsd.dk>
> In message <20050821.193225.53123034.cfmd at bredband.net>, Magnus Danielson writes:
> >> For the NordPool area (Norway, Sweden, Denmark, Finland) nobody tried to keep
> >> the average at 50Hz.
> >Which is what I recalled that you where saying. This is again my point, that
> >just because it is in one place, that is not universally true for all places.
> >The reasoning why people don't care as much should be fairly evident from the
> >discussion so far.
> Just got off the phone with a guy who writes for the same paper as me,
> has been teaching this stuff for ages.
> As a regulation domain gets larger, (and "larger" is measured in
> [MW * km * s] in this context), the inherent regulation mechanisms
> may develop instabilities for which the only currently known cure
> is a external frequency reference.
> The reason they don't do that in NordPool is because they don't
> think they are big enough to need it *and* because they have a
> couple of HVDC lines to other larger regulation domains where they
> can dump surplus or pull deficit on very short notice.
> However, external frequency references are not the perfect cure because
> they tend to trip more generators on faults in the network than the
> traditional mostly MVAR (reactive power allocation) based regulations.
> He said that the places he knew off that used it, had a two state
> mode, in one state, the frequency locked state, the delta-frequency
> (not delta-phase!) is limited relative to the external reference, and
> an effort to keep the delta-phase low was purely manual. The other state
> gives up on all external references and just tries to avoid a collapse
> of the grid.
> As usual with big systems, the big problem is that they never get to test
> and they're never ready when they get a chance to collect experience :-)
Interesting. Thanks for the report!
> >Also, how do you encode a leapsecond over 50 Hz, 60 Hz or whatever and has it
> >been done?
> Well, since they don't encode UTC in the first place, they can just encode
> leapseconds just like any other second :-)
There is a simple method, just run a thad below 50 Hz (or 60 Hz) so that you
have the same number of cycles on 86401 seconds as you normally would for
86400 seconds. That would turn out to be about 49,999421303 Hz on average.
Thats -578,697 mHz or -1,157394E-5 relative.
> The interesting thing is that they have been seriously thinking
> about transmitting UTC and tarriff information on the grid, but it
> looks it is cheaper to just use GPRS mobile phones.
Indeed. In Sweden that has become a big thing, with the deregulated market we
have. We haven't chosen that path here at home yeat, but I guess it is a
question of time like everything else.
> >BTW, measuring the 53rd overtone frequency may not give a clear picture of the
> >frequency deviations at the base frequency.
> Even worse, it may not be a "real" overtone in the first place, it could be
> a PWM tone from some regulated async motor.
That will be part of the energy, but the PWM would create sidebands around
the overtone. Diode-bridges, triacs etc. etc. all help to create overtones.
The current reactive load on the line will also affect the fundamental, and the
insertion and removal of capacitance on the power-grid will shift the phase.
If you thought the MW balance a headache, the MVAR balance is a real long
hangover all the time.
More information about the time-nuts