Code sits still while I read it. A loose contact does not. The report describes time spent looking for software bugs that were actually caused by physical connections, and the saved sketches help me see how easily the screen can hide that distinction. The raw sampler prints counts and input volts before any power equation enters the route. Those intermediate values give the investigation a more particular starting point.
I think part of the attraction is that code sits still while I read it. I can follow a variable, inspect a loop and find a line to change. A breadboard connection is less satisfying to reason about from a chair because I have to go back to the actual arrangement. But the circuit isn't divided according to what I find convenient to inspect. A measurement depends on the whole path. The code can be logically sensible and still produce an unhelpful answer from an unreliable input.
I'm trying to work backwards in smaller steps. What was displayed? Which calculation produced it? What readings went into the calculation? Was the ADC still communicating? Where did the signal enter? That isn't a magic list that identifies every fault. It’s a way to stop treating the final number as if it contains its own explanation. If I can find the earliest point where the behaviour becomes unexpected, I have a smaller part of the project to understand. Changing the final formula before checking that point can hide the useful clue.
An example makes the danger obvious. In this case, a program reports a current that seems too small. I could increase a multiplier until the number looks more reasonable. But perhaps the raw signal is being reduced or interrupted by a connection. A larger multiplier would then mix a physical problem with a software adjustment. When the connection behaves differently, the adjustment would still be there. I would have two things to untangle instead of one. This isn't a new fault I'm claiming to have observed; it is why a plausible output isn't enough to justify a change.
There’s a separate software issue I can actually locate too. The RMS sketch multiplies smoothed RMS voltage and current, calls the variable apparentPower, and prints W after it. That’s a mismatch between the calculation and its label. It’s different from a connection changing the input. Both can make a display misleading, but they belong to different places in the explanation. I find it more useful to follow those places than to decide that hardware or software must always be the guilty part.
There’s a similar trap in changing the display. If I smooth or round an unstable reading, the screen may look calmer. I want to know which problem I'm solving. Is the input unreliable? Is the calculation unsuitable? Or is the display showing more variation than a person needs to see? Those can lead to different choices. The fact that all of them can make a number look steadier is exactly why I shouldn't use appearance alone to decide.
The scanner gives me one way to step away from the full calculation. It asks about a device response rather than the meaning of watts or amperes. A raw-reading sketch gives me another layer. Neither one proves the whole meter correct, but that isn't what I need from them during debugging. I need a question whose answer I can interpret. If I ask the whole program whether everything works, the answer can be an unexpected number with too many possible explanations. The smaller test is useful because it deliberately leaves most of the project out.
I also want to pay attention to whether a change is repeatable. If a problem disappears after I have moved the board, restarted it and edited the code, I can't confidently say the edit fixed it. It would be easy to remember only the last action and give that action all the credit. The order of events matters. Even a failure that remains unresolved can teach me something if I know what stayed the same and what changed. A lucky success after several unrelated changes may teach me less than I first think.
This doesn't make the software less interesting. It gives me a more precise reason to inspect it. I want to understand which assumptions each part makes about its input and which of those assumptions I have actually checked. The RMS loop assumes it is receiving values that represent the intended signal. The power calculation assumes the voltage and current information mean what their names suggest. A variable named current doesn't prove that the value has become amperes correctly. That responsibility sits in the route through the program and the circuit together.
I can examine the input, its transformation and the printed label separately. The route gives me a reason for the next check, instead of only another part of the program to change.