Delay(500) looks quite ordinary at the end of the raw sampler. Against a 50 Hz waveform, it is a long wait: half a second contains 25 ideal cycles. Before that wait, the sketch reads A0 and A1, converts them with computeVolts and prints counts beside input volts. That makes its purpose clearer to me. It exposes a channel and its scale; its readable output is not a detailed record of everything the waveform did between lines.
The simple arithmetic makes the difference obvious. An ideal 50 Hz signal completes one cycle in 20 ms. Five hundred milliseconds contains 25 of those cycles. If I take one reading, wait half a second and then take another, a lot has happened between them that I haven't observed. I can still learn something about the channel. I can't draw all the missing detail back in just by joining the printed values with a line.
The delay is only one part of the time. Reading the ADC, transferring information and printing can add more. So even calling the output exactly two samples per second would need care if I meant the whole program's measured rate. The wait alone already tells me that this isn't a closely spaced view of the waveform.
There’s an interesting trap here. If the sampling interval lined up exactly with a whole number of cycles of a perfectly steady signal, repeated readings could land near the same phase. The values might look almost constant even though the signal was changing in between. Real clocks and signals won't necessarily have that exact relationship. The paper case is still enough to show why slow repeated values can be misleading.
That’s helping me understand the difference between a channel check and waveform sampling. A channel check may ask whether data arrives and whether its scale is plausible. It doesn't necessarily need to capture the detailed shape. A waveform calculation asks about values over time, and the timing becomes part of the information. I shouldn't judge a little test by a job it wasn't designed to do, or give its output a claim it can't support.
The serial monitor adds another source of confusion because it is the most visible part. Slowing the messages makes the program easier for me to watch. That’s useful for reading labels and spotting obvious changes. But the speed that suits my eyes isn't a rule for the measurement. The controller can collect information on a different schedule from the one used to show a summary, if the application is deliberately arranged that way.
The gain and the delay answer different questions. GAIN_ONE supplies the conversion scale of 0.125 millivolts per count; the wait shapes how often the loop can return to print another pair. Removing the wait would change the schedule but would not remove conversion time, the order of the channel calls or serial work. I can therefore explain why this little program remains useful without treating it as the complete waveform-acquisition method. A genuine raw value still needs a time relationship appropriate to the claim being made from it.
I haven't made that rearrangement and obtained a new result here. I'm reading the existing sketch and separating the purposes of its lines. The delay has a reasonable purpose in a small demonstration. It becomes a problem only if I forget that purpose and use the same output as though it represented something much more detailed. A convenient display choice can quietly become an assumption about the signal.
The ADC has its own conversion rate. The program has an order of operations. There may be two channels involved. The actual interval between useful samples needs to come from that whole route. Removing a visible wait changes one part of the route; it doesn't prove the final timing or make the inputs simultaneous.
This is where the small sketch is teaching me something beyond the numbers it prints. I have to ask what it includes and what it leaves out. A raw value can be completely genuine and still be unsuitable for the explanation I’m trying to give. The mistake would be in the use I make of it, rather than necessarily in the ADC returning the value.
For a later timing check, I would want the interval measured at the relevant point in the program and recorded with the code version and settings. That would let me compare the actual collection schedule with the question I'm asking of the data. Until then, I can describe the visible delay and its consequences without pretending to have measured a new sample rate.
The distinction is useful when looking at plots as well. I need to know what time belongs to each point, not only what value it has. A line connecting sparse points can look more continuous than the observations behind it. That doesn't make plotting useless. It means the graph needs an honest description of what was collected and how the points are placed.
The same line of code means more when I put it beside the signal's period. Readable serial output and useful waveform timing are both worthwhile goals, but the program has to make room for each deliberately.