In Synaptec we often say we measure ‘at the speed of light,’ but what does that mean? Is it true, or has the marketing department had too much coffee? In this post I am going to consider what measuring using light means in practice, using the time-critical application of power system protection as an example.
As many of you will know, the speed of a traveling wavefront in a cable is about 150 metres per microsecond. In general, the speed of a travelling wave in a conductor is inversely proportional to the dielectric constant (relative permittivity). A travelling wave in a theoretically lossless line would travel at the speed of light, but in cables the wavefront can achieve around half the speed of light.
In optical fibre, the wavefront speed is governed by the refractive index of the glass. In standard telecoms singlemode fibre (used for long-distance telecoms, including fibre bundles in trefoil power cables), the wavefront moves at a speed of 204 metres per microsecond, or around 2/3rds the speed of light.
In short, optical signals in fibre are significantly faster than electrical signals in cables.
Now, let us consider what this speed advantage means in practice. As you know, Synaptec’s sensors continuously transform an electrical signal into an optical one. They do this passively via a precision piezoelectric component. This is a physically simple and fast process because it does not involve digitisation – it is purely an analogue transformation from one medium to another.
The moment the sensor is subject to an event in the electrical signal, for example the inception of a fault, the waveform is recreated optically in the fibre.
The wavefront of the original electrical event and the replica optical wavefront are now racing neck and neck to the terminals of the cable.
It takes around a microsecond for the sensor to transform the electrical signal to light form, so the electrical wave has a small head start in this race of the wavefronts. But in cable circuits more than a few hundred metres in length, the higher speed of the light more than compensates for this head start. In fact, the fault will be recorded at the Refase IED before the fault has arrived at the cable termination!
Now let us compare this response time with the situation where there is instead a digital measurement relay at the remote location. These systems will communicate measured values via optical fiber to an IED located at the circuit terminus. So, if that method also uses fibre, can it react this quickly too?
In short: no. It is impossible for the remote system to digitise the measurement, and then transmit the measurement data over a digital telecom channel, faster than a simple analogue signal takes to propagate on that same channel. Why? Because digital communication requires a bit stream to be transmitted over the channel, meaning the first digitised measurement sample is not received until the stream is correctly received and decoded. This process requires a message to be composed, serialised, and sent by multiple transmissions, and meanwhile the measurement wavefront has long since arrived.
As the optical replica of the fault wavefront arrives at the Refase IED, it is sampled simultaneously to local sensors located at the cable end, allowing immediate comparison of the remote and local waveforms in real time as they evolve and diverge. This allows protection and monitoring response times to be as short as physically possible. This allows Refase IEDs to publish Sampled Value data streams, containing local and remote measurements, within 200 microseconds. Similarly, line differential protection can be performed onboard the Refase device, enabling the world’s fastest trip times – providing a useful advantage for minimising the damage from faults and helping ensure system stability.
I hope this brief post has shone some light (sorry) on the relative speed of travelling waves in optical fibres and power cables and given you some ideas on the applications that are possible when waveforms can be transposed from one medium to another at remote locations. And if I have generated a few questions or some ideas, I would love to hear from you.
Philip (CEO, Synaptec) – firstname.lastname@example.org
 This is without taking into account further delays in the order of milliseconds due to the nature of TDM comms channels such as SDH, or from MPLS packetization. Using SV + GOOSE avoids some of these issues, but only if a native wide-area packet network exists.