Sensor Data Collection: Reading the Physical World

A Thermometer Cannot Talk to a Computer

Hold a mercury thermometer outside on a hot Delhi afternoon in May. The mercury climbs to, say, 42°C. You can read that number because your eyes and your brain can interpret the height of a silver thread against a printed scale. Now ask a different question: how would a computer inside a weather-monitoring app know that it is 42°C outside, right now, without a human reading a thermometer and typing the number in? The computer has no eyes. It cannot look at mercury. All it can ever receive, at the most basic level, is a change in electric voltage — a number that a circuit produces. Somewhere between "the air outside is hot" and "the app shows 42°C," a physical quantity that has nothing to do with electricity had to be turned into an electrical signal, and that electrical signal then had to be turned into a clean digital number a program can store, compare, and act on. That whole conversion — physical world to voltage to digital number — is the subject of this chapter, and the device that starts the chain is called a sensor.

This is not a small, niche topic. Every automatic streetlight that switches on at dusk, every fitness band counting your steps, every smoke alarm, every Automatic Weather Station operated by the India Meteorological Department (IMD), and every air-quality display you see in a metro city is built on exactly the ideas in this chapter. Once you understand how a sensor's reading turns into usable data, you can reason about almost any "smart" device you encounter.

What a Sensor Actually Does

A sensor is a device that detects a physical quantity — temperature, light intensity, sound, distance, pressure, moisture, motion — and converts it into an electrical signal, almost always a voltage, whose value changes in a predictable, related way. The technical word for "a device that converts one form of energy or quantity into another" is transducer; a sensor is a transducer whose output happens to be electrical.

Consider a very common, inexpensive sensor used in school electronics kits across India: the LM35 temperature sensor. It is a small three-pin component, and its behaviour is defined by one clean rule: it outputs 10 millivolts (0.01 V) for every 1°C of temperature. This relationship is linear, which means it can be written as a simple algebraic equation:

voltage (in volts) = temperature (in °C) × 0.01

So at 28°C, the LM35 produces 28 × 0.01 = 0.28 V. At 35°C it produces 0.35 V. Notice what this equation buys us: temperature, something you cannot plug into a calculator directly, has been turned into voltage, a number a circuit can measure. That is the entire job of the sensor itself — nothing more. It has not yet produced a number a computer program can store in a variable. Voltage is still a continuously varying physical quantity, not a digital value.

Analog Signals: The World Doesn't Speak in 0s and 1s

The voltage coming out of the LM35 is called an analog signal. "Analog" means the signal can take any value within a range, and it varies smoothly and continuously as the real-world quantity changes. As the temperature drifts from 27.0°C to 27.1°C to 27.13°C, the voltage drifts smoothly too — there is no jump, no gap, no missing value in between. In principle, an analog quantity has infinitely many possible values between any two points.

A digital computer cannot store "infinitely many possible values." A variable in a program holds a specific number, represented internally using a fixed number of binary digits (bits). To get from a smoothly varying voltage to a specific stored number, two separate things must happen, and students very often blur them into one step by mistake:

• Sampling: deciding when to look at the signal — you cannot record every instant of a continuous signal, so you take a reading at specific points in time.
• Quantization: deciding which discrete digital value best represents the voltage you measured at that instant, since the true voltage might not land exactly on any of the finite values your computer can represent.

Together, sampling and quantization are performed by a circuit called an Analog-to-Digital Converter, or ADC. Every microcontroller board used in Indian school robotics and IoT clubs — Arduino Uno, ESP32, and similar boards — has one or more ADC channels built in specifically to read sensors like the LM35.

How an ADC Turns Voltage into a Number

An ADC has two important specifications you must know to use it correctly. The first is the reference voltage (V_ref), the maximum voltage the ADC is designed to measure. The second is the resolution, measured in bits, which tells you how many distinct digital values the ADC can produce. An Arduino Uno's ADC has a resolution of 10 bits and, in its default configuration, a reference voltage of 5 V.

With 10 bits, the ADC can represent 2¹⁰ = 1024 distinct levels, numbered from 0 to 1023. The rule connecting an input voltage to the output digital number is:

digital_value = round( (voltage / V_ref) × (2^bits - 1) )

Let's use the exact worked example from earlier: our LM35 is reading 28°C, so it outputs 0.28 V. Feed that into an Arduino's 10-bit ADC with V_ref = 5 V:

digital_value = round( (0.28 / 5.0) × 1023 )
              = round( 0.056 × 1023 )
              = round( 57.288 )
              = 57

Here is that same calculation written as a small, real Python function — the kind of code you would actually run to check your work:

def voltage_to_digital(voltage, vref=5.0, resolution_bits=10):
    max_value = (2 ** resolution_bits) - 1   # 1023 for 10 bits
    digital_value = round((voltage / vref) * max_value)
    return digital_value

print(voltage_to_digital(0.28))

Tracing it: max_value becomes 2**10 - 1 = 1023. voltage / vref is 0.28 / 5.0 = 0.056. Multiplying by 1023 gives 57.288, and round() takes it to the nearest whole number, 57. The program prints 57. This is the number that actually gets stored in the microcontroller's memory — not "28," not "0.28," but the integer 57. The board itself has no idea this number means "28 degrees Celsius." Converting 57 back into a temperature your program can display is a separate, deliberate step the programmer must write, using the sensor's known relationship (10 mV per °C) in reverse.

Quantization Error: The Precision You Lose

Here is the part most explanations skip, and it matters a great deal: converting 57 back into a temperature does not perfectly reproduce 28°C. Let's check, again with real, traceable code:

def digital_to_temperature(digital_value, vref=5.0, resolution_bits=10):
    max_value = (2 ** resolution_bits) - 1
    voltage = (digital_value / max_value) * vref
    temperature = voltage / 0.01          # LM35: 0.01 V per degree C
    return round(temperature, 1)

print(digital_to_temperature(57))

Tracing it: voltage = (57 / 1023) * 5.0. Now 57 / 1023 = 0.055718…, and multiplying by 5.0 gives 0.278592… V. Dividing by 0.01 gives 27.8592…, which rounds to one decimal place as 27.9. The program prints 27.9, not 28.0.

Where did that missing 0.1°C go? It was lost the moment the true, continuous voltage of 0.28 V was forced into one of only 1024 available "boxes." The ADC's smallest distinguishable voltage step is:

step size = V_ref / 2^bits = 5.0 / 1024 ≈ 0.00488 V (about 4.88 mV)

Since the LM35 produces 10 mV per °C, a 4.88 mV step corresponds to roughly 0.49°C of temperature. In other words, this particular sensor-and-ADC combination simply cannot tell the difference between, say, 27.8°C and 28.1°C — both would most likely round to the same digital code. This unavoidable rounding-off is called quantization error, and every digital sensor reading you will ever see carries some amount of it. Increasing the resolution (using a 12-bit or 16-bit ADC instead of a 10-bit one) shrinks the step size and reduces this error, which is exactly why more expensive scientific instruments advertise higher-bit ADCs.

Sampling Rate: How Often Should You Look?

Resolution answers "how precisely can one reading be measured?" A completely separate question is "how often should readings be taken?" — this is the sampling rate, usually measured in Hertz (Hz), meaning samples per second.

The correct sampling rate depends entirely on how fast the physical quantity you are measuring actually changes. Room temperature drifts slowly — sampling once every 10 seconds captures it perfectly well, and sampling 1000 times a second would just waste memory and battery power recording nearly identical numbers. But consider a car's airbag crash sensor, which measures sudden deceleration: a collision unfolds and needs a response within a few milliseconds, so that sensor must be sampled thousands of times per second, or the dangerous event could happen and finish entirely in the gap between two samples, leaving no trace in the recorded data at all. A step-counting accelerometer in a fitness band is a good middle case: a typical walking step takes somewhere around half a second to a second, so the accelerometer needs to be sampled fast enough — commonly tens of times per second — to clearly see the rise and fall of each step, rather than possibly missing steps or blurring two steps into one.

The general principle, which you will meet formally in later years as the Nyquist sampling idea, is simple to state even without the formal mathematics: you must sample noticeably faster than the fastest meaningful change you care about, or you risk missing or misreading real events. Sampling too slowly loses information permanently — there is no way to recover what happened between two samples after the fact. Sampling faster than necessary is not wrong, but it is wasteful: it burns more memory, more storage, and more battery on a mobile or embedded device, for no gain in useful information.

Noise: Why a Single Reading Can Be Misleading

Real sensors, connected by real wires, sitting in a real electrically noisy room, rarely produce a perfectly steady value even when the physical quantity itself is not changing. Tiny electrical interference, minor vibrations, and imperfections in the sensor circuit cause the reading to jitter slightly from one sample to the next. This random fluctuation is called noise.

Suppose a temperature sensor sitting in a genuinely stable 27°C room is sampled six times in quick succession and, due to noise, reports these six values: 26.8, 27.3, 26.5, 27.9, 26.6, 27.1. None of these individually is exactly 27.0, yet the room's temperature was not actually changing. Treating the very last reading (27.1) as "the" temperature, or reacting instantly to any single spike, would be a mistake. A standard fix is to compute a moving average: keep a small window of the most recent readings and report their average instead of any one raw value, so random noise on individual samples cancels out.

readings = [26.8, 27.3, 26.5, 27.9, 26.6, 27.1]

def moving_average(data, window=3):
    smoothed = []
    for i in range(len(data)):
        start = max(0, i - window + 1)
        chunk = data[start:i + 1]
        smoothed.append(round(sum(chunk) / len(chunk), 2))
    return smoothed

print(moving_average(readings))

Tracing this by hand for the first few steps: when i = 0, start = max(0, 0-3+1) = 0, so chunk = [26.8] and its average is 26.8. When i = 1, start = max(0, 1-2) = 0, so chunk = [26.8, 27.3], summing to 54.1, averaging to 27.05. When i = 2, the window is full: chunk = [26.8, 27.3, 26.5], summing to 80.6, averaging to 26.8666…, which rounds to 26.87. From i = 3 onward the window slides forward, always keeping only the three most recent values: [27.3, 26.5, 27.9] averages to 27.23, [26.5, 27.9, 26.6] averages to 27.0, and [27.9, 26.6, 27.1] averages to 27.2. The full printed list is [26.8, 27.05, 26.87, 27.23, 27.0, 27.2] — visibly steadier than the raw readings, and clustering much closer to the true 27°C than several of the individual raw samples did.

Calibration: Making Sure the Sensor Tells the Truth

Smoothing fixes random jitter, but it cannot fix a sensor that is consistently wrong in the same direction — called a systematic error or offset error. Imagine a soil-moisture sensor that, when placed in a container of completely dry soil that should read 0%, actually reports 8% every single time. Averaging many readings will not help, because every single reading shares the same 8% bias — the noise-cancelling trick only cancels out random variation, not a consistent shift.

The fix is calibration: measuring the sensor's output against one or more physical quantities whose true value is already known (a completely dry sample, a completely saturated sample, ice-melting water at a known 0°C), and using that measured offset to correct every future reading mathematically, typically with a formula such as corrected_value = raw_value - known_offset, or a more general linear correction when the sensor's error also depends on scale, not just a constant shift. Any lab-quality instrument, and any properly built school science project using sensors, requires a calibration step before its data can be trusted for real conclusions.

A Misconception Worth Correcting

A very common belief is: "a digital sensor reading is the exact, true value of whatever is being measured." You now have the tools to see why this is false. Every digital reading has already passed through at least two lossy stages — sampling (which can only capture the instant it happens to look, never the continuous signal in between) and quantization (which rounds the true voltage to the nearest one of a finite set of digital codes) — and very often a third source of error, sensor noise, on top of that. The worked example above showed a real, concrete case: a true 28°C reading, passed correctly through a real ADC formula, came back out as 27.9°C purely from quantization, with no mistake anywhere in the process. A "wrong-looking" reading is not necessarily a bug; understanding sensor data means understanding its built-in limits of precision, not assuming every number is perfect.

A Complete Small Pipeline

Putting sampling, conversion, smoothing, and a simple decision together is how real embedded programs are structured. Here is a compact but complete and traceable example: a soil-moisture monitor that takes several digital readings, converts each to a percentage, and decides whether to trigger a warning that a plant needs water.

digital_readings = [612, 598, 640, 605, 615]   # raw ADC codes, 10-bit (0-1023)

def digital_to_percent(value, max_value=1023):
    return round((value / max_value) * 100, 1)

percentages = [digital_to_percent(v) for v in digital_readings]
print(percentages)

average_moisture = round(sum(percentages) / len(percentages), 1)
print(average_moisture)

DRY_THRESHOLD = 65.0
if average_moisture > DRY_THRESHOLD:
    print("Soil is dry: start irrigation")
else:
    print("Soil moisture is adequate")

Tracing the conversions: 612/1023 × 100 = 59.82… → 59.8; 598/1023 × 100 = 58.45… → 58.5; 640/1023 × 100 = 62.56… → 62.6; 605/1023 × 100 = 59.14… → 59.1; 615/1023 × 100 = 60.12… → 60.1. So percentages prints as [59.8, 58.5, 62.6, 59.1, 60.1]. Summing these five values gives 300.1, and dividing by 5 gives 60.02, which rounds to 60.0. Since 60.0 is not greater than the threshold of 65.0, the program prints "Soil moisture is adequate." Notice how the raw sensor codes (values like 612 and 598, which mean nothing on their own to a human) had to travel through unit conversion and averaging before the program could make a sensible, human-readable decision.

Sensor Networks at Work Across India

These exact ideas run continuously, at large scale, in systems you may already have encountered. The India Meteorological Department operates a nationwide network of Automatic Weather Stations that combine temperature, humidity, rainfall, and wind sensors at a single site, sampling conditions repeatedly through the day and transmitting the digitized readings back to central servers without any person standing at the site taking readings by hand. ISRO's INSAT-3D and INSAT-3DR satellites carry an imager and a sounder — instruments that sense infrared and visible radiation from far above the Earth and convert it into digital data used to estimate cloud patterns, sea-surface temperature, and vertical profiles of atmospheric temperature and humidity, feeding directly into weather forecasting and cyclone tracking. In several Indian cities, the Central Pollution Control Board runs Continuous Ambient Air Quality Monitoring Stations that use gas and particulate sensors to measure PM2.5, PM10, and other pollutants at fixed intervals, feeding the live Air Quality Index numbers displayed on public boards and government apps. After Mumbai's severe flooding in 2005, the city administration invested in a denser network of automatic rain gauges specifically so that heavy rainfall could be detected and reported within minutes rather than depending on delayed manual observation.

Even the phone in your pocket is a small sensor-data-collection system: an accelerometer senses motion and tilt, a gyroscope senses rotation, an ambient light sensor adjusts screen brightness, and a proximity sensor turns the screen off near your ear during a call. Every one of these performs the same underlying chain you traced by hand in this chapter: a physical quantity becomes an analog voltage, an ADC samples and quantizes it into a digital number, and software then smooths, calibrates, and interprets that number before it becomes something you can see or that triggers an action.

Diagram: From Continuous Signal to Digital Steps

The blue curve is the true, continuously varying analog voltage — exactly what a sensor like the LM35 actually produces. The red dots mark the fixed instants when the ADC samples it; anything the signal does between two red dots is simply never recorded. The orange staircase is the resulting digital signal: flat between samples (because the stored number cannot change until the next sample arrives) and only ever equal to one of a finite set of allowed levels (because of quantization), which is why it never matches the smooth blue curve exactly. This single picture is the mechanism behind every worked example in this chapter.

Check Your Understanding

1. An LM35 sensor is at 33°C. What voltage does it output? (Use: voltage = temperature × 0.01 V)
2. Using a 10-bit ADC with V_ref = 5 V, what digital value (0-1023) will that voltage produce? Show the calculation.
3. A classmate says, "My digital thermometer showed 24.9°C and then 25.1°C a second later, so the room temperature must have actually jumped." Using what you learned about noise, explain a more likely reason, and describe one technique that would help tell the difference between real noise and a real temperature change.
4. A weighing sensor at a shop always reads exactly 50 g heavier than the true weight, no matter what is placed on it. Is this best fixed by (a) averaging many readings, or (b) calibration? Explain why the other option would not work.
5. A wildlife camera trap needs to photograph animals that dash past in under half a second. Would you sample its motion sensor once every 5 seconds, once every 0.1 seconds, or once every hour? Justify your choice using the idea of sampling rate.
6. Explain, in your own words and using the words "sampling" and "quantization" correctly, why a digital sensor reading is an approximation of reality rather than a perfectly exact value.

Summary

A sensor converts a physical quantity — temperature, light, sound, distance, moisture, motion — into an analog electrical voltage that changes continuously and predictably with that quantity, often following a simple linear rule like the LM35's 10 mV per °C. Because computers can only store specific digital numbers, an Analog-to-Digital Converter must sample that voltage at chosen instants in time and quantize each sample into one of a fixed set of digital codes determined by the ADC's resolution in bits; this two-step process is precisely defined by the formula digital_value = round((voltage / V_ref) × (2^bits - 1)), and it necessarily discards some precision, called quantization error, which shrinks as resolution increases. Sampling rate, chosen independently of resolution, must be fast enough relative to how quickly the measured quantity actually changes, or real events between samples are permanently lost; too fast wastes memory and power for no benefit. Real sensor data is also affected by random noise, addressed by smoothing techniques such as the moving average, and by systematic offset errors, addressed only by calibration against known reference values — averaging can never fix a consistent bias. These exact mechanisms run continuously inside IMD's weather stations, ISRO's weather satellites, CPCB's air-quality monitors, city flood-warning rain gauges, and the sensors inside your own phone, all built from the same chain: physical quantity, analog voltage, digital number, and only then, a decision.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where sensor data collection: reading the physical world is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting sensor data collection: reading the physical world to at least 3 other topics you have studied.