> ## Content Index
> Fetch the complete content index at: https://sreekars-journal.labvion.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# The reading changed when I moved a wire
- URL: https://sreekars-journal.labvion.com/pq-09-the-wire-moved-so-did-the-reading/
- Published: 2025-07-03T12:30:00.000Z
- Updated: 2026-10-29T08:13:30.000Z
- Description: A reading changing after a wire moves is a very physical clue. The report describes desk bumps and wire touches followed by a frozen I²C bus, ADC-not-found messages or raw readings jumping. That gives me a path to follow before changing another formula. Information has already travelled through
- Author: Sreekar
- Tags: Power meter, #Import 2026-10-29 10:08

A reading changing after a wire moves is a very physical clue. The report describes desk bumps and wire touches followed by a frozen I²C bus, ADC-not-found messages or raw readings jumping. That gives me a path to follow before changing another formula. Information has already travelled through contacts and wires by the time the calculation receives it, so the program can stay identical while the input becomes different.

My first instinct with a strange result is usually to open the code. There’s a lot to inspect there, and it feels as if I should be able to find the explanation by reading carefully enough. The circuit has given me a reason to look somewhere else. If moving a connection changes the behaviour, I have to think about the physical path as well. The program can be completely unchanged while the information reaching it becomes different.

That doesn't let me jump straight to naming the fault. A reading changing after a wire moves is an observation. A loose contact is a possible explanation. I need to keep those apart until I know more. Otherwise I could replace one assumption with another and feel as if I had solved something. The useful question is what exactly changed and whether I can connect that change to a particular part of the system. Describing the readings as strange isn't enough to guide the next check.

![Breadboard photograph, shown as context for connection troubleshooting. The source filename is preserved in the image inventory; it is not backdated to 2025.](https://sreekars-journal.labvion.com/content/images/2026/10/photo-051518510.jpg)

Breadboard photograph, shown as context for connection troubleshooting. The source filename is preserved in the image inventory; it is not backdated to 2025.

There are several layers where an unreliable connection could matter. Communication between the controller and ADC is one. The analog signal arriving at an input is another. Power and reference connections affect the arrangement more broadly. I'm trying to stop a single word, wiring, from becoming as vague as the word software was before it. The physical circuit has different paths, and I need to know which path the symptom points towards.

A comparison helps. In this case, the ADC disappears from a scan when a connection is disturbed. That would send me towards the communication arrangement before the RMS calculation. Now suppose the device still responds but the raw channel values behave unexpectedly. The scan result doesn't clear the entire physical circuit; it only answers the smaller communication question. Those two cases could both be described as a meter that isn't working, but they would lead to different next steps. That’s why I want the small sketches available.

The saved scanner and raw sampler expose different stages of that route. The scanner counts replies from devices. The raw sampler prints the channel count beside its input-voltage equivalent. A missing reply and a strange analog value after a successful reply would therefore ask different questions. That makes the reported movement-sensitive symptom useful without making it a complete diagnosis. I can follow which stage first changed, rather than expect the final output to identify its own cause.

I also have to think about what I changed while looking. If I move several leads, reset the controller and alter the program before trying again, I may get a different result without knowing which action mattered. It’s tempting because I want the circuit to behave, not to spend the entire session describing its misbehaviour. But a result that I can't connect to a change doesn't give me much to use next time. I want the check to be small enough that I can follow the relationship between the action and the response.

The breadboard is useful precisely because I can change things easily. That same convenience means the arrangement can move while I'm working. I hadn't been paying equal attention to both sides of that fact. I was treating the wiring as something completed before the software began, as though it could stop being part of the investigation once there was a program to inspect. The signal doesn't care how I divide the work in my head. Every reading still depends on the physical connections that brought it to the ADC.

The interesting thing is that the circuit can make the code look guilty. The unexpected value appears on a screen after the program runs, so it seems natural to blame the part I can read. But the program might be faithfully printing information that was already wrong or interrupted before it reached the calculation. That doesn't mean I should stop checking software. It means I should ask where the unexpected behaviour first appears. A later calculation is a poor place to look for information that was missing at the start.

I want to show the actual arrangement and the symptom when I ask for help. A photograph can preserve the general layout, although it won't prove every contact is sound. The relevant sketch can show what the controller was asking for. The observation can say what changed when the circuit was disturbed. Those pieces together are more useful than only saying that the reading went wrong. My mentor can help me interpret them, but I still need to pay attention to the details that make one explanation fit better than another.

The wire brings the hardware back into the explanation. A smaller question about the signal path gives me a more useful beginning than asking the complete calculation why the meter looks wrong.