Fiddle-Factors, Factors of 2 & Fatal Errors

It's amazing how much confusion there is among otherwise highly-competent engineers around certain factors of two in engineering equations, particularly in the RF and signal processing domain.

For example, I’ve seen the following question in multiple engineering forums: “Why is a Single Side Band Noise Figure 3dB higher than a Double Side Band Noise Figure? This intuitively seems backward…” At least the questioner knew that the SSB noise figure is typically 3dB higher in spite of his intuition to the contrary.

Consider the consequences when someone decides to trust their intuition and applies the 3dB offset in the wrong direction, thereby making a 6dB error in the effective noise figure! An error like that in the noise budget of a receiver could easily be fatal to a project.

Another common confusion arises over one-sided vs. two-sided spectral density. I’ve known people to question why the two-sided noise density isn’t twice as high as the single-sided noise density; after all, doesn’t the term “two” mean twice as much? Of course, the truth is that the same noise power, when accounted for by integration over positive and negative frequency spectrum (two-sided noise spectrum), implies half the spectral density.

Unfortunately, I have seen an experienced contractor make a factor-of-two error in the noise spectral density equation used throughout a complicated radio receiver noise budget spreadsheet. It's perhaps understandable how this could happen, but it's not forgivable when it occurs in a professional context and millions of dollars of development investment are at stake.

Other factors of two occur in such areas as differential versus single-ended voltages, peak versus mean power in sinusoidal waveforms, power-matched potential difference versus Thévenin equivalent source voltage, complex envelope representation of modulated carriers, and many more. The best RF systems engineers not only recall these relationships reliably, but can clearly explain to their colleagues which way round they apply and why.

Few of us start our careers with a comprehensive grasp of all, but hopefully by the time we hold senior engineering positions, we get these things right with high reliability (but not infallibility).

I vividly recall making the mistake early in my career of relying on my memory of a text book equation for power spectral density of noise, and using it for some requirements analysis for a circuit block. I didn’t check whether the text book was using two-sided noise density throughout (it was) and multiplied the density I had by the one-sided bandwidth of my receiver. I was very properly chewed out by a senior engineer who reviewed my work. That guy did me a big favor, even though I found it painful at the time.

This illustrates one reason that well-organized development teams always hold timely reviews of each other’s work. Whether these reviews are formal or informal is less important than that they happen. It's essential to ensure that mistakes and unjustified fiddle-factors are not allowed to live long enough to do real damage.

The value of a bug caught early (especially a system-level bug) is very high to a development organization, and should be treated as such. “Measure twice and cut once,” is still good advice in today’s high tech world, and can generalized to mean: Hold a review before you commit.

3 comments on “Fiddle-Factors, Factors of 2 & Fatal Errors”

1. eafpres
February 20, 2013

Hi Charles–good points.  Doing things from memory can make you seem smart at the time but really dumb later.

The last few engineering groups I managed were extremely “lean” due to tight budgets.  Workload was very heavy, and the groups were very “flat”.  (Catching all that management speak for “we have cut you below the resources you need but we expect you to work harder to make up for it”?).

Have you seen as a result of the economic downturn less oversight of junior engineers due to staff reductions?

2. Charles Razzell
February 20, 2013

Hi eafpres,

I appreciate the point that you are making.

It is clearly important to “engineer” teams to have the right mixture of mature, experienced individuals and younger engineers who may know less, but ideally are hungry to learn and achieve. We have to actively manage that mix to obtain a high performing team, and it is certainly helpful when higher management understands that true value is not just a ratio of headcount to dollars!

Another factor that can make it difficult to provide sufficient review and oversight is geographically dispursed teams. This is an increasingly prevelent situation that requires high levels vigilence (and good design review habits) to manage well.