Docs / When it doesn't work
Numbers scrolling past too fast to make sense of? Watch them as a graph instead
Your sensor is printing values to Serial Monitor and they're technically readable — but a column of scrolling digits doesn't show you the shape of what's happening. A live graph does.
What you're seeing
You've got a sensor wired up and printing numbers — a light level, a distance, a temperature — and the values change when you'd expect them to. But you can't tell from scrolling text whether a reading is noisy, drifting slowly, or actually stable; whether it responds instantly or lags; or exactly where a threshold should sit.
Why a graph shows what a column of numbers hides
A stream of numbers asks you to hold several recent values in your head at once just to notice a trend — and trends are exactly what a graph is built to show at a glance. Noise looks like a jittery line instead of digits that "seem to vary a bit." Drift looks like a slow slope instead of a change you might not notice until it's already large. A response delay is a visible gap on the timeline instead of something you'd have to time by hand.
Setting it up
-
Print only the number, one value per line
Serial.println(sensorValue);— a plotter reads each line as one point. Extra text on the same line (like a label) can stop some plotters from parsing it as a number at all. -
Open the plotter view at the same baud rate you set in code
The same baud-rate rule that applies to reading text output applies here — mismatched rates produce a flat or garbled line, not an error message.
-
Interact with the sensor while watching it
Cover a light sensor, wave a hand in front of a distance sensor, breathe on a temperature sensor — the live response is exactly what a graph makes easy to see and a scrolling column doesn't.
-
Note where the value actually sits at each extreme
The graph's high and low points, not a guessed number, are what a real threshold should be based on.
A worked example
Say you're calibrating an LDR (light-dependent resistor) to decide "day" from "night" for an automatic light. Printing the raw analog value and watching it as a graph — rather than guessing a threshold — shows you the actual number in daylight, the actual number covered, and exactly where the line sits between them. That measured midpoint, not a number picked from a tutorial, is the threshold worth using in code.
| Part | Why it's there | Price |
|---|---|---|
| Arduino Uno R3 (CH340G) | reads the sensor and prints the value | ₹230 |
| GL5528 LDR | the sensor being calibrated | ₹5 |
| Resistor Variety Pack | completes the voltage divider | ₹75 |
| Core of the example | the threshold comes from the graph, not a guess | ₹310 |
Letting Soldr do it
Once your build's code is generated and the hardware is in your hands, watch the readings it prints live rather than reading them as scrolling text — the same graph view applies to whatever sensor your build uses.
If the graph itself looks wrong
- A completely flat line usually means the wrong pin is being read, not that the sensor is broken.
- A line that never settles, constantly jittering across a wide range, often means a missing or wrong-value resistor in the sensor's circuit.
- Still unclear? Paste a short capture of the printed values into Soldr alongside what you expected to see.