The data logger sampling interval is the single setting that determines what a recording can ever reveal. Anything faster than the interval is either averaged away or captured by luck, and no amount of later analysis brings it back. Choosing that interval is a decision about which questions the data will be able to answer.
What happens between samples
Loggers handle the gaps between recorded points in one of two ways, and it matters enormously which one yours uses. Some take a single instantaneous reading at each interval and store it, ignoring everything in between. Others sample continuously at a high rate and store the average, and sometimes the minimum and maximum, for each interval. With instantaneous sampling, a brief event is recorded only if it happens to coincide with a sample, so a short spike is usually missed entirely and occasionally captured in full, producing a record with isolated outliers that look like errors. With averaging, that same spike is diluted into the interval and shows as a small rise. If the logger can record minimum and maximum alongside the average, enable it; that option preserves the peaks at almost no storage cost.
Averaging hides exactly what you were looking for
A ten-minute average is a comfortable way to view a day of temperature data and a poor way to catch a motor inrush. The averaging window acts as a low-pass filter, and short events are attenuated in proportion to how much of the window they occupy. This is why a logged current trace can show a perfectly flat profile on a circuit whose breaker trips daily: the trip is caused by a peak lasting a second inside a window that spans hundreds of seconds. Matching the interval to the phenomenon is the fix, and if you do not know the timescale of the phenomenon, start short and lengthen once you have seen the data. It is always possible to average fast data afterward; it is never possible to recover detail from slow data.
Aliasing produces trends that are not there
A load that cycles regularly and a logger that samples regularly can beat against one another. If a compressor runs on a period close to a multiple of your sampling interval, the samples will land at systematically similar points in its cycle and produce a slow apparent drift that has no physical cause. This is the same aliasing that catches people on oscilloscopes, and the giveaway is the same: change the interval and see whether the pattern persists. A genuine daily or weekly cycle stays where it is; an artifact moves or disappears. Where the risk is high, some loggers offer a small random variation in the interval specifically to break up this kind of correlation. Averaging loggers are much less vulnerable, because every moment contributes to some interval.
Memory, battery and the length of the run
Interval, channel count and memory together set how long a logger can run, and battery life sets a second, often tighter limit. A run that ends before the event you are hunting is a wasted deployment, and this is the most common failure of logging studies. Work the arithmetic in advance: samples per hour multiplied by channels multiplied by hours, compared against the memory available, and the expected battery endurance at that sampling rate compared against the intended duration. Check also what happens when memory fills, since some instruments stop and others overwrite the oldest data, and those two behaviors lead to very different outcomes. If a study must run long, consider a shorter interval on the channel that matters and a longer one elsewhere where the instrument supports it.
Timestamps are part of the data
A logged record becomes useful when it is aligned with something else, whether that is a second logger, an equipment fault log, a weather record or a production schedule. That alignment depends entirely on the clock. Set it deliberately before every deployment, note the time source you used, and record whether the instrument is keeping local time and how it handles a daylight saving change mid-run. Loggers whose clocks drift measurably over weeks should be checked against a reference at the end of the run so the offset can be applied. When several loggers are deployed together, synchronize them all from the same source at the same moment. A perfectly sampled record with an uncertain timestamp cannot be correlated with anything.
What to check before you act
- Find out whether your logger stores instantaneous samples or interval averages.
- Enable minimum and maximum recording if the instrument offers it.
- Calculate memory and battery endurance for the interval before deploying.
- Set and note the clock, and check it again when the run ends.
Common questions
What interval should I use if I do not know the timescale?
Start with the shortest interval that still covers your intended duration, review the first day of data, then lengthen it. Averaging down later is easy; recovering detail is impossible.
Why does my logged data show a slow drift that nobody can explain?
A cycling load beating against the sampling interval is a common cause. Change the interval and see whether the pattern survives before investigating the equipment.
The practical takeaway
Choose the interval from the timescale of the thing you are chasing, not from what makes a tidy graph. Record minimum and maximum where you can, size memory and battery for the full intended run, and pin the record to a clock you have deliberately set. Those four choices determine whether the data can answer anything at all.
References and further reading
- Department of Energy: estimating appliance and electronic energy use
- NREL PVWatts: modeling that relies on interval performance data
- NFPA: electrical safety resources and code background
Numerical scenarios are illustrative unless identified otherwise. Follow the exact product instructions; component ratings and local installation requirements can differ.
