> ## 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 connection is behaving better - URL: https://sreekars-journal.labvion.com/pq-16-the-communication-is-behaving-better/ - Published: 2025-07-29T12:30:00.000Z - Updated: 2026-10-29T08:26:52.000Z - Description: A communication result and a measurement result can arrive at different stages. The report describes the move to soldered perfboard after connection trouble. The later log records a scanner PASS at 0x48 while its current-sensor investigation remains In Progress. That distinction helps me explai - Author: Sreekar - Tags: Power meter, #Import 2026-10-29 10:08 A communication result and a measurement result can arrive at different stages. The report describes the move to soldered perfboard after connection trouble. The later log records a scanner PASS at 0x48 while its current-sensor investigation remains In Progress. That distinction helps me explain progress precisely. A converter can answer the controller while the signal being converted is still difficult to understand. Communication is one possibility. If the controller keeps finding the ADC and completing its requests, that tells me something about the link between them under the conditions of the check. The analog reading is another possibility. It could move around even when communication works, because a changing signal or an input problem is a different question. The final displayed quantity is another layer again. It depends on the conversion and calculation. I can't use one steady-looking result to clear every layer without thinking about what produced it. This is where the earlier small sketches remain useful. The scanner doesn't need to interpret volts or amperes. The raw sampler doesn't need to explain real power. If I want to say what changed after the hardware work, those simpler questions help identify the improvement. I don't need the biggest program to produce the most useful evidence. I need a program whose job matches the claim I'm trying to make. Otherwise I might describe a display improvement when I really mean that the communication stopped dropping out in the checks I performed. ![Photograph of the assembled prototype. The module marking reads ESP32-S2-WROOM.](https://sreekars-journal.labvion.com/content/images/2026/10/report-image2.jpg) Photograph of the assembled prototype. The module marking reads ESP32-S2-WROOM. I'm using an example to see the limit. In this case, a device answers ten repeated requests. That’s a good observation to record. If I write that it answered those requests under those conditions, the result stays useful. If I write that the system can never fail again, I have turned a limited observation into something the check never established. The stronger sentence would actually contain less reliable information. The same applies to a reading that looks steady. A steady number can be correct, but steadiness alone doesn't tell me that it is correct. A wrong offset can produce a repeatable answer. A display can hide variation by rounding or applying a cutoff. A changing input can legitimately produce a changing number. So I need two kinds of question: does the system behave consistently in the situation being checked, and does the value represent the intended quantity? Those can support each other, but they aren't the same test. The small sketches make those stages visible. The scanner checks replies, the raw sampler prints channel values, and the RMS sketch applies offset, scale and smoothing. Saying which behaviour improved is more useful than attaching stable to the entire meter. A better connection can make it easier to study a calculation without automatically validating the calculation. I can keep the reported physical improvement and the later recorded observations at their own stages rather than turning them into a new, perfectly ordered test sequence. I don't want this to take the pleasure out of making the hardware behave better. The improvement matters because it lets me investigate the next part with fewer moving uncertainties. It’s much easier to think about an RMS calculation when I'm not simultaneously wondering whether the ADC has stopped responding. That doesn't mean I can forget the connection forever. It means I can keep the simpler check available and concentrate on the next layer for a while. Progress can be useful without being absolute. Writing down what was actually checked will help if a symptom returns. Which sketch was running? What arrangement was being used? Was the board restarted between checks, or was it one continuous session? Those conditions change what a repeated observation means. I'm not inventing a test duration or a successful restart sequence here. I'm noticing the information that would make a statement about stability easier to interpret. If it isn't recorded, I should leave it open rather than borrow certainty from how permanent the soldered board looks. I also need to remember that the photographs show an assembly, not its entire behaviour over time. They are useful for understanding layout, sockets and connections. They don't turn a short observation into an endurance test. The module marking in the photograph is information worth keeping, especially because the board names in the report don't all agree. The image supports that visible detail. It doesn't settle every historical version or tell me who completed each stage of the build. One thing I can keep from this stage is the question behind the word stable. If I use it again, I want to be able to say which behaviour I observed. That will make the next comparison more useful than simply deciding that the board feels better now. Better becomes a useful description when it has a particular behaviour beside it. With a clear communication check available, the next question can concentrate on what the readings actually represent.