The first build began in June 2025 and took about four months in my project notes. Looking back at the saved work, I can give that period a more particular shape: communication with the ADC, trouble with temporary connections, the move to perfboard and the mathematics that gives sampled values physical meaning. The later code and lab notes add another view of the same project. I keep their dates visible while explaining what the different stages taught me to look for.
At the beginning, I wanted voltage and current readings. Those still matter, of course. What has changed is what I think a reading involves. I no longer picture the sensor handing the controller a finished answer. There’s a signal, an ADC value, an offset, a scale and a calculation. There’s also a time when the reading was taken. Leaving out any of those can change what the final number means.
The physical connections have probably been the most persistent reminder that a program isn't the whole system. A result appears on the computer, so I naturally want to look for a software mistake. But a loose connection can change what the software receives. The breadboard trouble made that harder to ignore. I could spend a long time thinking about an equation when I also needed to think about the path carrying the signal into it.
Moving the assembly away from the breadboard changed the kind of decisions involved. The arrangement had to make sense as something I might need to inspect or repair, rather than as temporary wires I could keep moving around. The socketed parts and the underside of the board are part of that story. A photograph is useful for seeing the arrangement, while the connections still need their own drawing and explanation.
I'm keeping the construction and measurement questions separate. An assembly behaving more dependably is useful progress. It doesn't automatically establish the accuracy of every quantity on the screen. The calculations still need their assumptions checked, and the sampling and calibration still need their supporting details. I don't want one kind of success to quietly stand in for all the others just because I'm reaching the end of this phase.
The maths has become more interesting because I can see what each operation asks from the hardware. RMS needs a meaningful set of values. Real power needs the relationship between voltage and current. Frequency needs events and elapsed time. These aren't only formulas to choose from a chapter. Each one gives me questions to ask about how the program obtained its inputs. Sometimes the code looks right until I follow those inputs backwards.
The final file makes the route concrete. It stores the voltage and current readings, estimates each channel's centre and accumulates voltage squares, current squares and voltage-current products. The 30 September 2025 log also preserves a scanner success and an unfinished current-sensor investigation. That later open thread does not erase the earlier build; it shows why a project can have a completed phase and still contain questions worth pursuing. I can describe both without making an old filename or a screen do the work of a measurement record.
That’s probably the biggest change in how I read a result. I still enjoy seeing numbers appear, but I now want to know the route behind them. Two values can look reasonable alone and become a different problem when I combine them. A familiar ratio can look reassuring while its inputs remain uncertain. A display can print more digits than the evidence supports. None of that was visible in the first list of quantities I wanted to show.
The help I've received belongs in the account too. There are things I learned from explanations, things I worked through with my mentor and parts built on existing examples. I need to keep my own tasks clear beside that help. I can be proud of learning to bring the parts together without pretending that every idea, tool or line began with me. Knowing where an explanation came from also helps when I need to return to it.
In this later look-back, the saved material gives some definite answers and preserves some differences. The wiring notes report the abandoned Pico plan. The final acquisition loop uses 400 sequential channel pairs. The calibration method is written down, while the reference readings behind the different constants are not. These belong to the later review of the work, with their own dates and context.
I would also like the next person looking at the project to see what is complete at this stage. There’s a physical assembly and a chain of code to understand. There are quantities being calculated and report examples to examine. There are also limits on what the available records establish. Calling this the first build is useful because it gives the phase an ending without pretending the project has run out of questions.
Some of those questions are more interesting to me now than the feature list was at the start. How would I recognise a misleading measurement? What smaller check would isolate the problem? Which piece of evidence would actually answer it? I couldn't have made a very useful list of those in June. I needed to work through the parts before the questions became this particular.
What stays interesting is the changing meaning of a reading. I began with quantities to put on a display; I can now follow more of the signal, timing and calculation that each displayed quantity asks for.