Computing Useful Customer Analogies

Introduction

Communicating scientific concepts to the public is a tough problem. One of the major issues is that people have a difficult time imagining the relative scale of things — just try to think of 1000 of something versus 10 of the same thing. You cannot really visualize 1000 of something.

I normally try to work by analogy. This means comparing an unknown thing to something that is very familiar. Astronomers do this all the time. Here is an example from an astronomy article I read today about a distant supernova called Mingus. To convey a sense of how dim this supernova is, an analogy using a firefly’s light was used:

Mingus was so distant and so faint — the equivalent of looking at a firefly from 3,000 miles (5,000 kilometers) away — that its true nature remained a mystery for a while, researchers said.

People can at least try to imagine how bright a firefly is and how it might look from 3000 miles away — even though you really cannot imagine something that like.

On a less dramatic scale, I was asked if I could compare the yearly operating cost of one of our products (an Optical Network Terminal [ONT]) to that of a common electrical device — a 100 W incandescent light bulb. I thought it would be useful run through how I answered that request.

Background

The basic facts of the analysis are straight forward and are listed here:

• An ONT draws 8 W of power on average from a 12 V power adapter.
• The 12 V power adapter has a typical efficiency of 80%.
• A kilowatt-hour of electrical power costs $0.1076 in Minnesota (my home state).
• A 100 W incandescent light bulb uses 100 W — I know this seems obvious, but I felt I had to say it.

Our salesman a couple of simple pieces of information about ONT power usage that customers will remember:

• How much does it cost to power an ONT for a year?
• How does that cost compare to the cost of powering a 100 W lightbulb for some period of time?

Analysis

Figure 1 shows my calculations to estimate the values requested by our salesmen. I decided to provide the answers in the following form:

• Cost of running an ONT for a year in Minnesota.
• Cost of 1 year of ONT operation versus operating time for equivalent cost of operating a 100 W light bulb.
• Cost of 1 month of ONT operation versus operating time for equivalent cost of operating a 100 W light bulb.

Figure 1 shows how I computed the answers. Since an ONT draws 10 W from the outlet, the 100 W light bulb draws power at ten times the rate of an ONT.

Figure 1:Calculations for ONT Annual Operating Cost.

• Cost of running an ONT for a year in Minnesota = $9.43.
• Cost of 1 year of ONT operation equals that of a 100 W light bulb running for 5 weeks.
• Cost of 1 month of ONT operation equals that of a 100 W light bulb running for 3 days.

Conclusion

This was a simple calculation example, but it represents the kind of math that is routinely done to assist customers with understanding our products.

Lightning Protection Math

Introduction

I get asked a lot of questions about the specific values that are used in engineering standards. At some level, you just meet the required values in these standards. You do not need to know why they were set to their specific values — you just conform. However, it is useful to have some insight into where these numbers come from. The most common questions on standards that I receive are about the various wire gauges and voltage/current levels associated with surge protection (aka lightning protection). With respect to telephony circuits, the standard for short-length (< 500 feet) telephone circuits is GR-1089, and I refer people to that standard for specific numbers to meet. If folks are looking for the rationale behind commonly used telephony wiring practices, I generally refer them to this article from OSP magazine. In this post, I will walk through the mathematics behind the protection levels that are discussed in this article.

I like this article because it explains the origins of some magic numbers that I encounter all the time. This post is focused on US standards, so I will be using US units. While I do not like using these units, their use actually make sense when I am trying to explain the origin of US telephony standards.

Here are some specific telephone wiring numbers that I encounter frequently and I will address in this post.

• 2000 A surge current value.

  I am going to speculate on where this number comes from, but I believe that I have a reasonable rationale for it. It is based on a chart that gives rate of occurrence of various levels of surge current.

• Ground wire lengths of 20 feet between the service panel and the telephone interface

  This is a company-specific recommendation that I see all the time. I first encountered this specification for the maximum length of a grounding wire while working with a customer who had spent much of his career with GTE. It turns out that GTE was the source of the 20 foot ground wire distance limit. Using some common telecom assumptions, I will show how this length and the cable’s insulation rating are related.

• Communication cable with 5000 V insulation rating

  While not commonly seen today, 5 kV rated cable used to be common. It turns out that this wire rating is closely tied to the 20 foot ground wire length.

Wiring practices are frequently used for decades — once installers are trained, companies do not like to retrain them. I am not sure that some of these practices still make sense, but people still follow them. I do not understand that behavior — that is a topic for a blog on human behavior and is not appropriate for a math blog.

Background

Lightning Damage Example

There are some lightning strikes that are so powerful that they literally vaporize hardware. Figures 1 and 2 are from my brother’s house that suffered a lightning strike last year. Figure 1 shows where the lightning damaged the outside of the house (a metal chimney is right behind this wall), and Figure 2 shows a wall outlet blown out from the same lightning strike. Every outlet and appliance on that circuit was destroyed.

Figure 1: Damage to My Brother’s Chimney from Lightning.	Figure 2: One of a Number of Blown Outlets at My Brother’s Home.

I have seen many examples of lightning damage to electronic hardware. Some of these examples are quite dramatic — circuit boards literally blown to pieces. On field trips, I have inspected homes that had their entire sides damaged. No electronics will survive this type of strike. In other cases, the damage suffered is more subtle. A circuit card may be rendered inoperative, but with no visible damage.

We incorporate surge protection on all of our circuit boards to try to limit the amount of damage lightning does. However, there are limits as to the level of lightning-generated current and voltage surges that can be withstood.

Magnitude of a Lightning Strike Current Surge

Figure 3 shows the frequency of lightning strikes per year for a given current surge level (Source).

Figure 3: Frequency of Lightning Strikes By Current Surge Level.

Now for some speculation based on the following reasonable assumptions:

• Telecom gear is generally expected to have a mean lifetime of 10 years => We are looking for a yearly occurrence rate of 0.1 strikes per year. I illustrate how I read this value off of Figure 3 in the Analysis section of this blog.
• Most homes are in environmentally shielded regions.

Using these assumptions, we can read off of Figure 3 that we can expect to see a 2000 A (2 kA) current once every 10 years on average. I speculate that reasoning such as this was used when the 2 kA surge standard was established for lightning testing.

Home Electrical Model

Figure 4 shows the model for home wiring discussed in the OSP article.

Figure 4: Illustration of Home Wiring and the Levels of Surge Protection.

I want to highlight the following characteristics of the wiring in Figure 4.

• All wiring in the home is referenced to Earth at the service panel.
• The phone circuits are grounded to the service panel by a 20 foot long cable.
• A person on the phone touching a refrigerator could be exposed to the voltage difference between an appliance (metal grounded to the service panel through safety ground) and the phone ground.
• The home ground rod provides a resistance to Earth that can be as high as 25 Ω.

  This is the value allowed by the National Electrical Code (NEC). Unfortunately, the ground resistance often ends up much higher.

• The ground rod is connected to the service panel by a 2-foot long, #6 AWG

  This is the length assumed in this example. Most electrical inspectors recommend keeping this length as short as possible.

• The service panel is connected to the telephone NID (Network Interface Device) by a 20 foot long, #10 AWG wire.

  I know of many telephone system installers that enforce a 20 foot limit for this cable.

While this problem setup has been a bit long, we now can perform some basic analysis.

Analysis

Figure 5 shows how I setup my analysis for duplicating the results from the OSP article. Assume for this discussion that the lightning induces a negative potential on the ground (i.e. current is drawn from the house). Lightning can generate either positive or negative potentials — for this discussion, I find it a bit easier to visualize the surge current being drawn out of the house.

Figure 5: Surge Analysis Setup.

Figure 6 shows my analysis that duplicates the results of the OSP article.

Figure 6: My Derivation of Numbers from the OSP Magazine Article.

Conclusion

This blog post is a review of an article on the cable gauge and insulation requirements for telephony grounding. I wanted to make sure that I understood where all the numbers in a figure from that article came from. I believe that I have duplicated every result. These numbers may not be as relevant in today’s telecom market, but people still follow them.

Appendix A

I have included a PDF copy of the OSP article just in case the link moves.

Mothers and Sons

I had to laugh yesterday. We live next to a mom with two boys — a 4-year old and a newborn. As I went out for my nightly walk, this rather haggard-looking mom told me that her 4-year boy is defiant and difficult to handle. She knows that my wife and I raised two sons, so she asked me if it gets any easier as they get older. My answer was simple. I told her that, last weekend, my mother (79 years old ) accused me of being defiant and difficult to handle. I am 56 years old. So it does not get any easier.

Superman, Chicken Little, and Knowable Unknowables

I was having a discussion with other managers about the difficulty of creating accurate schedules for development programs. Typically, I work directly with the engineers involved and have them create time estimates for their portions of each development effort. I find that about half the engineers always generate optimistic schedules and the other half generate pessimistic schedules. I give these two types of engineers the following names:

• Superman

  These folks wake up every morning thinking they have an “S” on their chest. There is nothing they cannot do, if only management will get out of the way. If they do get behind schedule, they think that all they need to do to get back on schedule is to come in and work on a weekend. The theory here is that there are so many distractions during the week that real engineering can only occur when they alone and on the weekends. However, that miracle weekend never seems to occur.

• Chicken Little

  These folks are just the opposite of Superman. They find it impossible to plan because the number of things that could go wrong are too numerous to count. Why even try to plan when unexpected things happen every day?

I deal with Superman and Chicken Little the same way — I introduce the concept of “knowable unknowables.” Knowable unknowables are program events that will introduce delays in a program, but I cannot state what these events are at the start of the program. They include things like unexpected circuit board layout errors or undocumented defects in new chips. I know these events will occur, but they are unknowable at the start of the program. As long as you are willing to deal with averages, it is amazing how predictable these unpredictable events are.

With Superman, you introduce doubt into their plans by warning them about recent events that have slowed progress on other programs and that these events could occur on their program. Slowly, you get them to agree that things may not go as smoothly as they think. Slowly their schedule lengthens to reflect historical norms.

With Chicken Little, you just remind them that it is rare for every possible bad thing to happen on a program. You tell them that they need to plan for a reasonable number of unexpected events. I have gone as far as telling my Chicken Littles that they should assume 1 major problem (defined as slipping the schedule by 1 month) and 3 minor problems (a minor problem is a 2 week schedule slip). Plan for normal execution times for everything else. As with the Superman, Chicken Little soon has a schedule that reflects historical norms.

This approach seems to work. At least I can go home at night comfortable in knowing that my program schedules do not assume any miracles or disasters.

Exoplanet Orbit Example

Introduction

This is an exciting time for astronomy — we are just now beginning to obtain spectra from exoplanets. I was reading an article on Space.com about some great work on obtaining the spectra from planets orbiting HR 8799. While looking at the image, I thought it would be interesting to see if I can duplicate some of their orbital calculations.

Background

This analysis will be very approximate. I will apply some simple orbital mechanics. There are four planets in the article’s image. To estimate their orbital radii and periods, I need to make a few assumptions.

• The orbits are centered on the middle of the dark region.

  This is equivalent to saying that the star is much more massive the planets. A planet and its star rotate about a foci of the orbital ellipse called the barycenter. With the star being much more massive than the orbiting planets, the barycenter of the orbit is very near the star (maybe even inside the star’s diameter).

• The orbits are perfect circles.

  Another assumption that makes my analysis simple. This assumption allows me to measure the orbital radii by measuring from the middle of the dark region to the center of the planets.

• The orbital plane is perpendicular to our line of sight.

  I really have no idea as to the plane angle relative to our line of sight. I will simply make the simplest assumption. Again, this means that we are looking at a perfect circle.

Analysis

My analysis consists of two parts: (1) determination of the orbit size, and (2) determination of the orbital period.

Orbit Size Determination

Figure 1 shows how I estimated the orbital radii of the four planets. I put the image into Visio and I just started adding some dimensions. I then used the Wikipedia radius of 68 AU for planet e as a reference value to use to estimate the radii of the other planets.

Figure 1: Orbit Measurements Taken From Wikipedia Article on HR 8799.

Figure 2 shows my scaling calculations.

Figure 2: Orbital Radii Calculations.

My radii estimates are within 6% of the published values. Not bad considering the assumptions that I had to make.

Orbit Period Determination

Figure 3 shows how I estimated the orbital periods. Note how close my estimated values are to published values.

Figure 3: Determining the Orbital Period of the Planets of HR 8799.

My results are within a few percent of the published results. Again, not bad considering my assumptions.

Conclusion

I feel like I understand the orbital basics of this exoplanet system with just a little bit of algebra.

Goldilocks Problems

I have been working on a simple optical deployment problem that is all too common. A customer has put together an optical plant (fiber, connectors, splitters, etc) that does not have enough loss on it — the laser transmitter is so bright that it blinds the receiver. In other deployments, customers sometimes have too much loss in their optical plant and the laser light is too dim for the receiver to read the data reliably. I refer to this situation as a Goldilocks problem. Engineers do not like Goldilocks problems — not too little, not too much,  only just right works. In meetings with customers, I always refer to baseball and tell them that ideally they want the optical power “right in the middle of the strike zone.”

In this particular case, the amount of communication required to solve this simple problem has been surprising. Our modern trouble tracking systems are impressive, but they do generate a flood of email. I count 46 emails involved in resolving this issue — back in the old days there would have been four emails:

• report of trouble from the customer
• request for power data
• return of power data
• email diagnosing the problem and proposing a solution (i.e. add an attenuator — equivalent of sunglasses for optical telecommunication systems)

I am a student of the history of engineering. I find the story of how people came to be builders of things endlessly fascinating. Engineering processes and their history are also interesting. I started my engineering career as an integrated circuit designer with a handheld calculator and a set of x-acto knives for cutting rubylith. The changes during my 34 year career have been breathtaking. I sometimes wonder what it would be like to build the pyramids using the same approach to engineering processes that we use today. Could you imagine telling someone that they have to remove and rework a 100 ton block because a dimension was slightly off? The Great Pyramid of Giza contains almost 600,000 blocks — did they actually have a bill of materials?  Did they have Engineering Change Orders? I am sure they had some system of engineering control, but I have never seen any discussion about it.

The more I think about it, the more impressed I am with what the pyramid builders did. How many emails would we need today to build a pyramid?

Standards of Readability

I had a discussion with one of my engineers this morning about documentation and our company’s standard of readability. When I was in school, I always tried to write so that I could be understood. It was while working as a US Navy contractor that I discovered that I need to write so that I could not be misunderstood. This lesson was drummed into me by a safety engineer — a man to whom I am in debt. His writing is so clear that I hope that I someday get near his level. I tell the engineers in my group that we write so that we cannot be misunderstood.

I do have one documentation horror story that I want to relate. I used to work as a proposal manager on large defense contracts. I had a former physics professor (PhD from a very well known institution) who worked on some of my proposals as a technical contributor. I could not read a thing that man wrote! I even brought in a very good writing consultant to work with him and that did not help at all. Finally I sat down with him and told him that his writing was terrible and he was going to need to do something else. He demanded to know exactly what was wrong with his writing and I told him that no customer could understand what he was writing. He then told me that he viewed his writing as a form of filter — any customer that could not understand what he wrote should not be reviewing this proposal.

I then tried to explain to this very intelligent man what the life of a government proposal reviewer was like. I decided to present this poor writer with the following proposal review scenario:

• your proposal is the 20th one the reviewer has seen this week,
• most of the proposals have been a struggle to get through,
• Friday at 4:00PM is the first time he starts reading your proposal,
• your proposal is difficult to read
• the reviewer decides to give your work a low score and go home for the weekend,
• all of our work has been for nothing.

After some moaning and groaning, he got the point. You write for audience and you do not create unnecessary obstacles.