An Arduino-based waveform logger can be genuinely useful for slow, low-voltage signals, but it is not an oscilloscope in the protected, calibrated sense. On a classic UNO R3 the ADC is 10-bit and A0 through A5 are its analog inputs, and the official reference describes roughly 100 microseconds per analog read on ATmega-based boards while noting that this is not a bandwidth guarantee for a complete application. Those facts, plus sequential sampling, set the ceiling on what such a logger can honestly claim.
Conversion timing sets the ceiling
The Arduino reference puts a single analog read at roughly 100 microseconds on ATmega-based boards and explicitly says this is not a bandwidth guarantee for a complete application. Add loop overhead, display updates and storage and the achievable sample interval only grows. The ATmega328P datasheet adds that the result is 10-bit and single-ended, referenced to the selected VREF, and that the input expects a source impedance of roughly 10 kilohms or less because of sample-and-hold charging limits. Together these define a tool that can follow slowly varying signals well and becomes unreliable as signal frequency rises.
Sequential channels and aliasing
With one converter, multi-channel logging reads channels one after another, so traces are not simultaneous and carry a small time skew. The larger trap is aliasing: if you sample more slowly than twice the highest frequency present in a signal, fast content can appear as a slow, false waveform that looks perfectly plausible. A logger that does not acknowledge this can produce confident and wrong pictures. The datasheet also reminds us that absolute maximum ratings are stress limits, not operating conditions, so exceeding an input window is never justified by them.
Diagnostic table: what you are seeing and why
| Observation | What it probably means | What to check |
|---|---|---|
| Amplitude reads wrong | Scaling or reference problem, not a signal problem | The scaling method and the VREF reference |
| Frequency reads low or unstable | Sampling too slow, aliasing or loop jitter | The actually achievable sample interval |
| Two traces look shifted | Reads are sequential, not simultaneous | The ordering and timing of channel reads |
| Baseline wanders when a signal is present | Source impedance too high for the sample-and-hold | Source impedance against the recommendation |
| Trace pinned at an endpoint | The signal exceeds the usable input window | The input range and any divider |
| Trigger looks jittery | Software timing rather than hardware triggering | How triggering is actually implemented |
An ordered evaluation process
- Connect only known, current-limited, low-voltage signals referenced safely to board ground. Mains, floating power circuits and RF transmitter outputs are out of scope.
- Measure the achievable sample interval in your actual loop rather than assuming the raw conversion figure.
- Work out the highest signal frequency you can honestly represent given that interval, using the sampling relationship, and note the aliasing risk above it.
- Verify amplitude scaling against a known DC source before trusting any waveform shape.
- Check source impedance against the recommendation so the sample-and-hold can settle.
- Test how sequential channel reads affect timing if more than one channel is used.
- State the tool’s honest bandwidth and decide whether it meets the task, rather than presenting it as an instrument.
Scope and safety
This is an educational logger, not a protected or CAT-rated instrument, and no accuracy or certification is claimed. State an honest bandwidth for your build and verify it against a known signal rather than assuming it. For related ADC and accuracy-budget context see the milliohm meter article, and for divider and ADC calibration see the OLED voltmeter guide.
Reader questions
Can it capture fast digital or RF signals?
No. Conversion timing and front-end limits rule it out, and no RF capture capability is claimed here.
Is it a real oscilloscope?
No. It is a sampling logger without the input protection or calibration of a bench instrument.
Why does a fast signal look slow on screen?
That is aliasing: sampling more slowly than twice the highest frequency present folds fast content down to a false lower frequency.
How can I improve it?
Remove loop overhead, acknowledge the sampling ceiling and keep inputs within safe limits; the hardware itself cannot exceed its conversion timing.
Documentation: Arduino analogRead() reference (official reference-en source); Microchip ATmega328P datasheet, 7810D automotive edition.
Documentation only: the cited sources cover ADC resolution, conversion timing, input mapping, referencing and source-impedance guidance. No bench testing or code execution was performed, so achievable sample rate, display behaviour and any two-channel performance must be measured on your own build.
