Home › Guides › Data Loggers Explained

Data Loggers Explained: How They Record the World, One Sample at a Time

A data logger is a small device with one job: watch a measurement over time and write it down faithfully, even when nobody is watching. It might sit in a cold room recording temperature through the night, ride along on a delivery vehicle tracking humidity, or sit beside a machine logging vibration or voltage for weeks. The readings it collects become the evidence behind decisions — whether goods stayed cold, whether a room stayed within limits, or when exactly a fault began. This guide explains how data loggers work from the inside out: sampling, resolution, storage, timestamps and sensor interfacing, and finishes with practical logger builds you can put together at safe low voltages.

If you are new to the electronics underneath, start with our electronics circuits basics guide, which covers voltage, current, resistance and the laws that tie them together. The digital side of a logger — how it counts, compares and decides — is covered in our logic gates explained guide, and the displays many loggers use are covered in LCD and OLED displays explained.

What a data logger actually is

Strip away the enclosure and every data logger contains the same five building blocks. A sensor converts a physical quantity — temperature, pressure, humidity, light, voltage, current — into an electrical signal. Signal conditioning cleans that signal up: it may amplify a tiny voltage, filter out electrical noise, or convert a current signal into a voltage the rest of the circuit can read. An analogue-to-digital converter, or ADC, turns the conditioned analogue signal into a number. A processor or microcontroller takes that number, attaches a timestamp, and writes it to memory. Finally, a power supply — usually batteries, sometimes a USB supply or a small solar panel — keeps the whole thing running unattended.

Two broad families exist. Standalone loggers are sealed units: you configure them on a computer, deploy them, and retrieve the data later, either by plugging them in or over a wireless link. Logger systems built around a microcontroller board are the opposite: open, flexible and cheap, but you assemble and program them yourself. A standalone logger is the right choice when the data matters for compliance or a dispute, because its behaviour is tested and documented. A home-built logger is the right choice for learning, prototyping and personal projects where you control every part of the design. Knowing which family you need is the first decision, and it shapes every other choice in this guide.

Sampling: how often is often enough?

Sampling is the act of taking a measurement at a chosen instant and repeating it at regular intervals. The sampling interval is the time between readings, and the sampling rate is its inverse — one reading per minute is a rate of one sample per minute; one reading per second is sixty times faster. The single most common beginner mistake is choosing the interval by gut feeling instead of by the thing being measured.

The rule is simple: sample fast enough to capture the fastest change you care about. A room warming up over an afternoon changes slowly, so a reading every few minutes captures the whole story. A motor starting up, a door opening and letting in a blast of warm air, or a voltage dip during a switching event may last only seconds. Sample once a minute and those events vanish between readings, leaving a smooth-looking graph that hides exactly what you wanted to catch. As a practical rule of thumb, sample at least several times faster than the fastest event you want to resolve, and faster still if you want to see the shape of the event rather than just its existence.

There is a deeper reason behind that rule. When a signal changes faster than the sampling rate can follow, the fast changes fold back into the data as false slow patterns, an effect called aliasing. A flickering light sampled at just the wrong rate can appear steady, or appear to flicker slowly, and no amount of later analysis can recover the truth — the information was never recorded. The cure is either to sample faster or to filter the signal before sampling so that only changes slow enough to be captured reach the converter. Good loggers include such an anti-aliasing filter; home-built ones should at least average several rapid readings into each stored sample, which has a similar smoothing effect.

Sampling faster is not free, and that is the trade-off at the heart of logger design. Every extra sample costs storage space, processing time and battery energy. A logger sampling once a second produces sixty times more data than one sampling once a minute, and if it wakes its processor and writes to memory for every sample, its battery life falls sharply. The art is to match the rate to the job: fast during the interesting moments, slow during the quiet ones. Many loggers support triggered or burst logging for exactly this reason — they sample slowly in the background, then switch to a fast rate when a reading crosses a threshold, capturing the event in detail without paying the fast rate all day.

Resolution and accuracy: two different promises

Resolution is the smallest change a logger can report. It is set by the ADC and by the measurement range it is configured for. A converter with more bits divides its input range into finer steps: doubling the number of bits roughly halves the step size. A temperature logger measuring a wide range with a coarse converter may only be able to report in steps of a fraction of a degree, while the same converter on a narrow range can resolve much finer changes. Resolution is about the fineness of the ruler, not about whether the ruler is correct.

Accuracy is how close a reading is to the true value, and it is almost always the weaker of the two. Accuracy depends on the sensor itself, on the signal conditioning, on temperature drift in the electronics, and on calibration. A logger that displays three decimal places is not automatically accurate to three decimal places — those extra digits may be noise dressed up as precision. When you compare loggers, read the accuracy specification, usually given as a value plus or minus a percentage of reading or of full scale, and check whether it holds across the whole temperature range you will deploy in. A sensor calibrated at room temperature can drift noticeably in a cold store or a hot plant room.

Calibration is what ties a logger's numbers to reality. It means comparing the logger against a known reference — a calibrated thermometer in a stable bath, for example — and recording or correcting the difference. For casual projects, a simple comparison against a trusted instrument is enough to catch gross errors like a miswired sensor or a wrong range setting. For compliance work, calibration must be traceable to a recognised standard and repeated at defined intervals. Either way, the habit is the same: never trust a logger you have never checked, and re-check it after any repair, battery change or long deployment.

Storage: how much data, and in what form?

Storage planning is simple arithmetic, and doing it before deployment saves the most common field embarrassment: a logger that stopped recording halfway through the job because its memory filled up. Multiply the number of channels by the number of samples per day by the number of days, and compare the result with the logger's capacity. One channel sampled once a minute produces 1,440 readings a day; over a month that is more than forty thousand readings. Add four more channels and sample every ten seconds, and the total grows by orders of magnitude. Memory cards make capacity cheap in home-built loggers, but battery life and file handling still limit how fast you can practically sample.

Most loggers store readings as timestamped rows, often in a simple text format such as comma-separated values, which any spreadsheet can open. Some use a proprietary binary format that only the manufacturer's software can read, which is a real cost: if the software stops working or the company disappears, the data can become stranded. When choosing a logger, prefer one that exports to an open format. Keep the raw exported file untouched as your master copy and do all analysis on a copy — edited data is no longer evidence.

When memory fills, loggers behave in one of two ways, and you must know which yours does. A stop-when-full logger simply stops recording, preserving the earliest data. A wrap-around or circular logger overwrites the oldest data with the newest, preserving the most recent period. Neither is wrong, but confusing them is: a stop-when-full logger deployed for a month with a week's capacity silently misses three weeks, while a circular logger retrieved late may have overwritten the very event you deployed it to catch. Check the setting before every deployment, and size the memory with margin for the deployment running longer than planned.

Timestamps: the clock is part of the measurement

A reading without a trustworthy time is barely a reading at all. If two loggers disagree about when an event happened, you cannot line up their data, and if a single logger's clock drifts, its data slowly slides against every other record — shift logs, weather data, alarm histories. Most loggers keep time with a small battery-backed real-time clock, and every such clock gains or loses a little time. The drift is tiny over days but adds up over months, so for long deployments, sync the clock before you start, note any offset when you retrieve the data, and correct for it in analysis rather than silently trusting the timestamps.

Where the logger supports it, syncing to a network time reference or a satellite time signal removes drift almost entirely, which is why connected loggers are popular for multi-site work. Even without that, one good habit covers most cases: record the logger's clock reading against a trusted watch or phone at deployment and again at retrieval. The difference tells you the drift, and a steady drift can be corrected across the whole dataset. Also watch for time-zone and daylight-saving traps: store and analyse data in one consistent time reference, and note the local offset in your deployment notes, so a one-hour jump never masquerades as a real event in the data.

Sensor interfacing: connecting the real world

The sensor is where a logger meets reality, and interfacing is where most home-built projects succeed or fail. Sensors fall into a few families, and each needs different handling.

Voltage-output sensors

The simplest sensors produce a voltage proportional to the measured quantity. Interfacing them is mostly a matter of matching ranges: the sensor's output range must fit within the ADC's input range, or the top of the range will clip and readings will flatline at maximum. A resistive divider can scale a larger voltage down, but it also loads the sensor, so the divider values must be high enough not to disturb the measurement. If you are learning this from scratch, our electronics circuits basics guide explains dividers, loading and Ohm's law with worked examples.

Current-loop and resistive sensors

Industrial sensors often output a current loop signal, which is robust over long cables because current, unlike voltage, does not sag with cable resistance. A logger reads it by passing the current through a known precision resistor and measuring the resulting voltage. Resistive sensors such as thermistors and resistance temperature detectors work the other way: the logger passes a small known current through the sensor and measures the voltage, or places the sensor in a divider. Keep the excitation current small, because current through a temperature sensor warms it slightly and biases its own reading — a subtle error known as self-heating. Our RTD versus thermocouple guide compares the two main temperature sensor families in detail.

Digital sensors

Many modern sensors do the conversion internally and hand the logger a finished digital number over a serial bus. This removes analogue noise and range-matching problems, but adds protocol work: the logger must speak the sensor's bus correctly, handle its timing, and check for communication errors. A reading that arrives garbled must be flagged, not silently stored as if it were real. For beginners, digital sensors are usually the fastest route to a working logger, and the ESP32 projects for beginners guide shows microcontroller boards talking to digital sensors in complete working projects.

Signal conditioning and noise

Real signals arrive with noise: mains hum picked up by long cables, switching spikes from nearby equipment, and thermal noise in the electronics themselves. Short, twisted, shielded cables, a single clean grounding point, and keeping sensor wiring away from power cables remove most of it. What remains can be reduced by averaging several rapid samples into each stored reading, which is cheap and effective for slowly changing quantities. If a reading jumps wildly while the physical quantity cannot possibly have changed that fast, suspect wiring and noise before suspecting the sensor — in the field, the cable is guilty more often than the component.

Practical logger builds

The best way to understand a logger is to build one. All three builds below stay at safe low voltages — battery or USB powered, a few volts at most — and none of them connects to mains wiring. That boundary matters: mains-powered measurement needs proper isolation, rated components and qualified supervision, and it is not a beginner project.

Build 1: a single-channel temperature logger

Take a small microcontroller board, a digital temperature sensor, a memory card module and a battery pack. Every minute, the board wakes, reads the sensor, attaches the time from its real-time clock, appends one line to a text file on the card, and sleeps again. Sleeping between readings is the key to battery life: a board that sleeps properly can run for weeks on ordinary cells, while one that stays awake may last only a day. Test it first on your desk for a full day, comparing its readings against a trusted thermometer, before trusting it in the field. Add a small display if you want live readings — our LCD and OLED displays explained guide covers choosing and driving one.

Build 2: a multi-channel environmental logger

Add humidity, light and air-pressure sensors to the same board, and the project becomes a lesson in trade-offs. Each channel adds samples, storage and power draw, and each sensor has its own quirks — humidity sensors are slow to respond, light sensors saturate in direct sun, pressure sensors need temperature compensation. Log each channel at its own sensible rate rather than forcing them all to the fastest one, and give every channel a clear name and unit in the file header. A file whose columns are labelled is usable a year later; a file of bare numbers is a puzzle nobody will solve.

Build 3: a triggered event logger

For catching rare events, build a logger that samples slowly but watches continuously. It might read a sensor every minute, and the moment a reading crosses a threshold — a temperature spike, a door opening, a vibration burst — switch to sampling every second for a fixed window, then return to the slow rate. This is the design used, in more rugged form, for fault investigation: the slow background record shows the context, and the fast burst shows the event itself. The logic behind the threshold decision — comparisons, combinations of conditions, latching an alarm state — is exactly the digital logic covered in our logic gates explained guide.

Choosing a logger: a short checklist

Before buying or building, answer these questions in order. What quantity, over what range, with what accuracy? How fast does it change, and therefore how fast must you sample? How long must the deployment run unattended, and what does that imply for memory and battery? Will the data be used as evidence, which pushes you towards a calibrated standalone logger with an open export format? And what environment will it survive — moisture, dust, heat, vibration, theft? A logger that is perfect on a desk and dead after one rainy night was the wrong logger. Work through the list honestly and the choice usually makes itself.

Common mistakes, and how to avoid them

The classic failures are depressingly repeatable. Deploying with a flat battery, or with a clock that was never set. Sampling too slowly and missing the event. Storing data in a format nobody can open. Labelling nothing, so the data is orphaned the moment the person who deployed it forgets the details. And the most expensive: building a mains-connected measurement without isolation and damaging the logger, the equipment, or a person. Every one of these is prevented by a short pre-deployment ritual — check the battery, set and note the clock, verify the sampling rate and memory setting, record the sensor positions and channel names in a deployment note, and confirm the whole setup stays at safe low voltages unless a qualified person has designed the mains side. Keep that note with the data file, not in your head.

Frequently asked questions

Related guides

Continue with the foundations behind this guide: electronics circuits basics for the analogue side, logic gates explained for the digital decisions, ESP32 projects for beginners for complete microcontroller builds, and LCD and OLED displays explained for adding a live readout to your logger. Then browse all guides for the wider LOTICI library.