What a Sampling Interval Hides

Why this matters

A logger set to one-minute intervals produces 1,440 rows a day per channel. That looks like a lot of evidence, and the file behaves like evidence: it opens, it plots, it has timestamps. What it does not advertise is everything that happened between the rows, and for the intermittent faults people buy loggers to chase, that is usually where the fault lives.

This article is about the negative space. Not what a log shows, but what it structurally cannot show, what it will invent instead, and why neither problem can be fixed after the file comes off the instrument. A tech who knows the shape of the hole reads a clean-looking log correctly. A tech who does not will report "nothing abnormal in the data" about a machine that failed four times that week.

What the interval is, and what it is not

The interval is the spacing between stored records. It is not the instrument's speed, and confusing the two causes half the errors here. Many loggers sample far faster internally than they store, and what happens to those extra samples - discarded, averaged, or reduced to a minimum and maximum - is a setting, usually a separate one, and it changes what the file means.

So there are two numbers to know before you deploy anything: how often the instrument stores, and what it does with the time in between. The manufacturer's documentation states both, and it is worth reading rather than assuming, because the defaults differ between instruments that otherwise look identical.

What cannot be in the record: the event shorter than the interval

If the instrument stores an instantaneous sample every interval, an event shorter than the interval either lands on a sample or it does not. There is no partial credit and no attenuation. A brief dropout does not appear as a shallow dip; it appears as a full-depth reading or as nothing at all.

The probability is arithmetic, not luck. An event lasting a fifth of the interval is caught roughly one time in five. Miss it three times running and the file says the machine was fine.

The mirror of this is just as important and gets forgotten: an event long compared to the interval cannot hide. Anything lasting longer than two intervals must land on at least two consecutive stored samples, because there is no way to fit two full interval gaps inside it. That gives you a bound that runs both directions, and it is the most useful thing a single anomalous sample tells you. One low sample, with normal samples on either side, means the event was somewhere between an instant and about two interval lengths. It does not tell you where in that range, and no processing of the file will narrow it.

What the record invents: the cycle that is not there

Undersampling does not only erase. When the thing you are measuring is itself repetitive and the interval lands near its period, the file shows a pattern with no physical counterpart.

Two ends of the same mechanism, and they point the same way:

• Interval exactly equal to the cycle period. Every sample lands at the same point in the cycle. The record is a flat line, and the machine is cycling its full range the whole time.
• Interval close to but not equal to the cycle period. Each sample lands slightly later in the cycle than the last, so the record shows a slow wave that is purely an artifact of the two rates sliding past each other. Its apparent period is one divided by the difference of the two rates. A load cycling every 9.5 minutes, sampled every 10 minutes, produces an apparent cycle of about 190 minutes, a bit over three hours. Nothing in the building has a three-hour cycle. The file says otherwise, convincingly, with a smooth curve.

Both cases require the sample interval to be near the signal's own period, which is why this bites on cycling loads, on staged equipment, and on anything driven by a repeating control action, and does not bite on a slow drift. The formal requirement is that a periodic signal must be sampled at more than twice its own frequency to be represented at all. In field practice, detecting an event is a lower bar than characterizing its shape and duration, so aim for several stored samples inside the shortest feature you care about, and take the instrument's own stated minimum where it gives one.

What averaging inside the interval changes

Storing an average of everything the instrument saw during the interval fixes the miss problem and creates a different one. Now every event contributes something, so a short excursion cannot vanish entirely. But it is diluted in proportion to how brief it was: a five-second excursion inside a sixty-second average contributes one twelfth of its own magnitude to the stored number, which for most excursions is smaller than the ordinary variation in the signal and is therefore invisible in the noise.

Averaging also destroys direction. An interval containing a spike up and a sag down averages to something unremarkable, and there is nothing in the stored value that says two opposite things happened. A sibling article covers what averaging hides in a handheld meter's display; the mechanism in a logger is the same, applied to a stored record instead of a screen.

What a minimum or maximum channel gives back, and what it still hides

Many loggers can store the minimum, the maximum and the average of each interval. This is the best trade available for most field work, and it is worth understanding precisely what it recovers.

It recovers the extreme. If the excursion happened, its depth or height is in the file. That alone answers a large class of questions: did the voltage go below the control's stated minimum, did the pressure exceed the setpoint, did the temperature reach the limit.

It does not recover duration. A minimum column tells you the lowest value seen during that minute. It says nothing about whether that value was held for a tenth of a second or for forty seconds, and duration is what usually decides whether a control should have reacted.

It does not recover time within the interval. The extreme is located only to the interval. If you are trying to establish which of two events came first, and both are located to the same minute, the record cannot answer it, no matter how many decimal places the columns carry. Two instruments logging at one minute cannot establish sequence between events under a minute apart. That is a limit of the record, not of the analysis.

It does not recover count. Three separate excursions in one minute and one excursion in one minute produce the same minimum. A file showing one low minute may be one event or a dozen.

Why this cannot be fixed afterward

Everything above is a property of the file, not of how you read it. Interpolation between stored samples produces a smooth line, and that line is drawn, not measured. Smoothing removes the samples that were real and keeps a curve that never existed. Re-plotting at a finer scale magnifies the drawing.

This is the practical reason the interval decision has to be made before the run and not argued about afterward: the interval is the only parameter of a logging run that cannot be revisited without going back to the site. Placement can sometimes be reasoned around. A missing channel can occasionally be inferred from another one. A too-coarse interval is a permanent hole.

Worked example: a twenty-second dropout on a sixty-second log

A control drops out for about twenty seconds, resets itself, and the customer sees it as an occasional hiccup. A logger goes on the supply at a sixty-second interval, storing instantaneous samples, for one day: 1,440 records.

Catch probability per event. Twenty seconds out of a sixty-second interval is one third, so any given dropout has about a one in three chance of being on a stored sample.

Over three real dropouts. The chance of missing all three is two thirds multiplied by itself three times, which is eight in twenty-seven, or roughly thirty percent. So there is close to a one in three chance the file is clean after a day in which the fault occurred three times. The report writes itself wrongly: "logged 24 hours, no anomalies."

If it is caught. One low sample with normal samples either side. That establishes the event happened and how deep it went. It bounds duration between an instant and about two minutes, because anything longer than two intervals would have landed on two consecutive samples. Two minutes and an instant are on opposite sides of every control decision that matters here, so the caught sample has not answered the question either.

The fix, and its cost. Drop the interval to five seconds and a twenty-second event lands on about four consecutive samples: detected every time, with a duration you can read off the record. The file grows from 1,440 records a day to 17,280, twelve times as many, which is the real trade being made. If the instrument cannot sustain five seconds for the duration required, the alternative is a minimum and maximum channel at sixty seconds, which will catch the depth of every dropout and will still not tell you how long any of them lasted. Choose which of the two questions you actually need answered, because at this interval you cannot have both.

How to verify an interval before you commit to it

Prove the setting on the bench, not on the customer's roof. It takes about a quarter of an hour and it catches the two failures that ruin runs: an instrument that reverted to a default interval, and an averaging or instantaneous setting that is not what you believe it is.

Set the instrument up exactly as it will be deployed. Produce a step change you can time yourself with a stopwatch - for a temperature channel, move the element from room air into a cup of cool water and back out after a counted number of seconds, which involves no heat and no pressure. Download the file and check three things: the timestamps are spaced at the interval you set, the step appears, and the number of records covering the step matches the seconds you counted divided by the interval. If any of the three is off, the setting is not what the menu said it was, and you have found that out with the truck still in the yard.

References

• Manufacturer documentation for the logger's internal sample rate, storage interval, and averaging or minimum and maximum options
• Trade-standard practice for data logging in field service and commissioning
• See related: Averaging and Spikes: What Your Meter Hides; How to Set Up a Logging Run That Answers a Question
• See related: How to Log an Intermittent Fault Over Days