# Beware of the square root

-March 14, 2014

If Mr. Murphy of "Murphy's Law" fame [1] had been a mathematician he would have had a warning something along the lines of: "Beware of Square Root of 2 errors."

I don't know why, but lately I have run across many examples of this kind of error. One involved a paper in a respected journal. Some folks were measuring very low frequency noise. To make a measurement, they used two of their devices and summed them together, then made the statement that this would double their voltage noise. This sounds logical, until you think of the random nature of noise and point by point examine what really happens when random noise is uncorrelated.

If the first random source of the noise happened to have a positive value at time Tn, any other random noise source in the universe is likely to have an opposite sign at time Tn, and even if it has the same sign it is likely to be of a different magnitude. So the summation is really not in phase or in series.

The probability is that over a long period of time the output of two uncorrelated noise sources summed together is really reduced by 1/Sqrt(2). And if you have N sources summed together the reduction is 1/Sqrt(N).

If they had carefully checked the result, which is sometimes very hard to do because you don't know what answer you are looking for in the first place, they might have spotted the error.

In a situation like this, simulating the measurement chain might help spot the error. Or inputting known signals and measuring them can help spot all sorts of issues.

100% in Error Every Time
Here is an example that is easy to see the error in, yet I have never seen it done completely right. The ubiquitous Discrete Fourier Transform (DFT) or, as it is commonly called, the Fast Fourier Transform (FFT) [2].

Now I understand that absolute accuracy of the result is not needed in many fields, but to us instrumentation folks we like to get an accurate amplitude out of our DFTs because we are making calibrated measurements [3].

Here is the scenario as you will see it on countless MATLAB and other programming language examples around the web:

Figure 1: A typical FFT example script that is found in every language (not just MATLAB) all over the web. Is the scaling here really right at line 17? [4].

Is the DFT scaling of the script in Figure 1 really right? To find out, let's look at the input and result. The input is merely a sine wave of 1 volt peak (or 2 volts peak to peak) (Figure 2).

Figure 2: Zoomed in portion of the waveform created by the script in Figure 1. Clearly this is a 1-volt peak sine wave, which is 1/sqrt(2) or 0.707 Volts rms.

The result of the script in Figure 1 is a single-frequency spike with an amplitude of 1 (Figure 3). All is good right? Well, no. The resultant units of a DFT is Volts rms, not Volts Peak!

Figure 3: The resulting DFT from the script in Figure 1. It shows 1 volt peak at 100 Hz, but are those really the right units? No - the result of a DFT scaled for spectrum analysis is Volts rms.

We put in a sine wave with an amplitude of 1 Volt peak, which is 0.707 Volts rms. Wait, what was that DFT result again? It was 1 Volts rms, but that is not what was input to the DFT. Guess what? The result is off by the square root of 2! Everyone apparently gets lulled into thinking that the result is scaled properly because it just so happens in this case that 1 volt peak input gave a DFT amplitude of 1.