How Averaging Hides a Fault

Why this matters

You can calculate, before you ever set up a logger, whether the fault you are hunting is capable of showing up in the data you are about to collect. Most techs do not, and the result is a week of clean trend logs offered as proof that nothing is wrong, on a machine that is failing every afternoon. The arithmetic is one line long and it applies to three things at once: the averaging inside your meter, the interval on your data logger, and any average you work out yourself from a column of numbers. A sibling article covers what a meter's internal damping smooths away; this one is about how to compute the size of the window that can still see your event, so you can choose it deliberately.

The one line of arithmetic

An averaging window reports the baseline plus the excursion, diluted by how much of the window the excursion occupied:

Reported average = baseline + (peak minus baseline) x (event duration divided by window length)

The unit of analysis is one event inside one window, on one measured channel. If more than one event lands in the same window, the durations add before the division. That is the whole model, and it is exact for a square event and close enough for anything with a short rise.

The consequence is the part worth memorizing. The excursion is not reduced a little by a long window, it is reduced in exact proportion to it. Doubling the window halves what you see. Multiplying the window by sixty divides what you see by sixty.

Worked example: the same event through four windows

A motor circuit runs at a steady 18.0 A. Something in the control sequence causes a brief surge to 54.0 A lasting 0.5 seconds. The excursion above baseline is 54.0 minus 18.0, which is 36.0 A, or twice the running value again on top of it. In the machine, that is a large event.

Read the first and last rows together. A one-second window reports a value that doubles the running current and no one could miss it. A fifteen-minute window, which is a completely ordinary logging interval on a building system, reports 18.02 A against 18.0 A. The event did not get smaller. The window ate it.

Turn it around: the longest window that can still see your event

Now solve the same line for the window instead of the value. You need the excursion to clear a detection floor, which is whatever level of wobble you would dismiss as noise or instrument uncertainty. Pick that floor deliberately.

Say your floor is 3 percent of baseline, so 0.03 x 18.0 A, which is 0.54 A. Set the diluted excursion equal to that floor:

36.0 x (0.5 / W) = 0.54, so W = 36.0 x 0.5 / 0.54 = 33.3 seconds

Any averaging window longer than about 33 seconds cannot show this event above your own noise floor. That is not a judgment call, it is arithmetic, and it tells you before you leave the truck whether the logger setting you were about to use is worth the trip.

Three parameters go into that answer, and all three have to be stated for the number to mean anything: the excursion size, the event duration, and the floor. Change any one and the answer moves proportionally. A floor of 1 percent of baseline, 0.18 A, pushes the usable window out to 36.0 x 0.5 / 0.18, which is 100 seconds. Set the floor honestly rather than optimistically, because the floor is the thing you will actually be willing to call a finding at two in the afternoon.

Repetition is the other variable, and it works in your favor

A single event is the hardest case. Events that repeat within a window add their durations before the division, which is why a nuisance that happens constantly is easier to catch on a slow instrument than one that happens once a day.

Same event, same 60-second window, but it now occurs four times inside it. Total event duration is 4 x 0.5, which is 2.0 seconds. The reported value becomes 18.0 + 36.0 x (2.0/60), which is 18.0 + 1.2, so 19.2 A - the same figure the single event produced in a 15-second window. Duty cycle and window length trade off exactly one for one.

That gives you a diagnostic in itself. If a long-window average sits noticeably above the value you measure by hand during a quiet moment, something is happening between your visits often enough to move the average, and you now have an estimate of how much: the difference between the two, divided by the excursion size, times the window, is the total event time per window.

Estimating the event duration when you do not know it

The window calculation needs an event duration, and that is the one parameter you usually do not have. There is a way to measure it with the instrument already in your hand, using a property of the same arithmetic: while the window is longer than the event, halving the window exactly doubles the excursion you see. Once the window reaches the event duration, halving it stops changing the reading. The window where the doubling stops is your estimate of how long the event lasts.

Run it on the same example. Starting at a 15-second window and halving:

• 15 seconds: excursion 36.0 x (0.5/15) = 1.2 A
• 7.5 seconds: 36.0 x (0.5/7.5) = 2.4 A
• 3.75 seconds: 36.0 x (0.5/3.75) = 4.8 A
• 1.875 seconds: 36.0 x (0.5/1.875) = 9.6 A

Each step doubles, which tells you every one of those windows is still longer than the event. Keep going and the doubling continues until the window closes on the 0.5-second event, at which point the reading levels off at the true peak of 54.0 A and further halving changes nothing. That plateau is the signal to stop, and the window where it appears is roughly the event duration.

Two conditions on this method, both worth stating. It assumes one event per window, so it works on a repeating fault only if you are sampling faster than the gap between events, and it needs a reasonably square event; a slow rise and fall softens the plateau into a bend rather than a corner. Read the bend as an upper bound rather than a precise duration.

What to use instead of an average

• Min/max or peak-hold on the instrument. These capture the extreme rather than the mean, which is the correct tool. Check the published capture time: an instrument that samples for peak capture at a stated interval still misses an event shorter than that interval, and the specification is the only place that number lives. Do not assume peak-hold means instantaneous.
• Inrush mode, which is built specifically to catch the first fraction of a second of a starting load and ignore the settled value afterward.
• A shorter logging interval on the channel that matters, rather than everywhere. Storage and battery are finite, so spend the fast sampling on the one or two channels where you computed that the window matters, and leave the rest slow.
• An event-triggered capture, if the instrument supports it, which records only when a threshold is crossed and sidesteps the window question entirely.

Where this is a safety matter, not a diagnostic one

Exposure limits are averages too, and the same dilution applies to your own lungs. Carbon monoxide is the case that matters most in this trade. 29 CFR 1910.1000 Table Z-1 sets a permissible exposure limit of 50 ppm as an 8-hour time-weighted average, and NIOSH publishes a 200 ppm ceiling. Those two numbers do different jobs on purpose: a short, high peak that would harm someone immediately can sit inside a compliant 8-hour average, which is exactly the dilution the table above describes, applied to a person.

So use an instrument that alarms on the instantaneous value and a ceiling, not one that only shows you a running average, and treat the alarm as an evacuation instruction rather than a data point: everyone leaves the building immediately, no switch is touched on the way out, no ignition source is operated, and the space is ventilated from outside before anyone re-enters. Never let a carbon monoxide decision rest on an averaged readout or on how the air feels.

What this looks like when it goes wrong

The recognizable failure is a service file that contains a week of clean data on a machine with a real intermittent fault, offered to a customer as evidence that the complaint is imaginary. Everyone involved is acting in good faith. The logger did exactly what it was set to do, and the setting was chosen because it was the default.

The tell is a complaint with a short, sharp character - a trip, a flicker, a momentary noise, a control that resets - paired with trend data whose interval is measured in minutes. The moment you see that pairing, do not argue about the data. Compute the maximum usable window from the event's likely duration and excursion, compare it to the interval that produced the clean file, and show the customer the arithmetic. It converts an argument about whether the fault is real into an agreement about what to measure next.

The second failure is subtler: averaging across units rather than time. A fleet average, a per-building rollup, a monthly figure spanning many machines dilutes one bad unit exactly the same way a long window dilutes one short event, and the same line of arithmetic estimates how bad a single unit has to be before the rollup moves.

How to verify you got this right

Before you deploy any logger, write down three numbers: how big you expect the excursion to be, how long you expect it to last, and what change you would be willing to call a finding. Divide as above and set the interval from the answer. If the arithmetic says the interval you have available cannot see the event, say so before you leave rather than after a week of collection, and propose peak-hold, inrush capture or an event trigger instead.

Afterward, sanity-check the log against a hand reading taken while you were standing there. If the logged average sits above your hand reading on a quiet system, the difference is telling you how much is happening while nobody is watching.

References

• 29 CFR 1910.1000 Table Z-1, carbon monoxide 8-hour time-weighted average; NIOSH ceiling value for carbon monoxide
• Instrument manufacturer's published specification for peak-hold and inrush capture response time
• See related: Averaging and Spikes: What Your Meter Hides; Why a Static Reading Lies About a Loaded Fault; Interpreting a Fluctuating Reading