> ## 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. # Following the voltage reading - URL: https://sreekars-journal.labvion.com/pq-04-tracing-the-signal/ - Published: 2025-06-16T12:30:00.000Z - Updated: 2026-10-29T08:26:52.000Z - Description: My meter's voltage path has several different kinds of information along it. The ZMPT101B module produces a signal for an external ADS1115, and the controller receives converted values over I²C. I find the drawing more useful when I follow that route instead of only recognising the boxes. The A - Author: Sreekar - Tags: Power meter, #Import 2026-10-29 10:08 My meter's voltage path has several different kinds of information along it. The ZMPT101B module produces a signal for an external ADS1115, and the controller receives converted values over I²C. I find the drawing more useful when I follow that route instead of only recognising the boxes. The ADC-input voltage, the original voltage being measured and a digital number on a communication link all belong to the system, but they mean different things. Explaining one arrow properly stops me silently skipping a conversion. The first separation is between the original quantity and the sensor's output. The sensor gives the rest of the system something it can handle. That output still needs to arrive at the ADC in an appropriate form and range. Then the ADC produces a digital reading. The controller gets that reading and uses the configuration and sensor relationship to calculate the quantity for the display. Writing the stages in order helps me notice that the controller doesn't directly know the thing I'm asking it to report. I'm finding it useful to imagine putting a label beside each arrow. Not just voltage, because there can be different voltages in different places. What unit does this signal have? Is it changing around zero, or has it been shifted around a middle value? Is this arrow an electrical connection or a communication link carrying a number? Those are quite different things to hide under the same line on a diagram. If I don't say which kind of arrow I mean, I can skip an entire conversion without noticing. ![System diagram labelled RP2040. The wiring notes describe a planned Pico/Picoduino replaced by ESP32-S3; the photographed ESP32-S2-WROOM still leaves the final physical-board identity unresolved.](https://sreekars-journal.labvion.com/content/images/2026/10/report-image1.jpg) System diagram labelled RP2040\. The wiring notes describe a planned Pico/Picoduino replaced by ESP32-S3; the photographed ESP32-S2-WROOM still leaves the final physical-board identity unresolved. For a signal path, suppose a sensor represents a changing quantity with a smaller signal around a midpoint. The ADC reads that shifted signal, not the original quantity. The calculation has to account for the midpoint and the sensor's scale before the result makes sense. This isn't a description of a new test. It’s a way to ask whether I can explain every stage without using the final answer as the explanation for the beginning. If I can't follow the path in a small example, more boxes won't help. The controller's role is becoming clearer too. It requests readings, keeps track of them and runs calculations, but it isn't a magical box that fixes the information arriving from the sensor. If the range is wrong, or if the offset is misunderstood, the program can carry the mistake all the way to a neat output. That's part of what makes this interesting. The electronics and the software aren't two projects that meet only at the end. A choice in one changes what the other is allowed to assume. The wiring notes also preserve a change in the controller plan: a Pico or Picoduino was abandoned after power and computer-detection trouble, and the notes describe moving to an ESP32-S3\. The assembly photograph carries an ESP32-S2-WROOM marking. I keep the general signal path separate from that unresolved board identity. The important point for this drawing is that the external ADC performs the conversion and the controller communicates with it. A board label needs to match the actual version before its pin details can describe the physical assembly. The Pico change in the wiring notes explains part of the controller history, but it does not settle every name in the material. The photograph and the notes still identify different ESP32 modules. That uncertainty belongs beside the board-specific details; it does not prevent an explanation of how the sensor signal reaches an external ADC and then a controller. That uncertainty doesn't stop me understanding the general path, but it does stop me treating every board-specific detail as settled. Pin names and programming assumptions belong to the actual controller. A general explanation can remain useful while a particular label needs correction. I'm trying to get comfortable with that distinction instead of choosing between believing the whole drawing and throwing it away. The useful question is which part the drawing supports and which part needs checking against the board and the saved code. I also want the arrows to show direction clearly. A number requested over a communication link is different from power being supplied to a board. If I use the same vague explanation for both, the drawing becomes tidy at the cost of explaining less. The current path will eventually join the voltage path in the calculations. For now, keeping it separate helps me see what I still need to explain about voltage. I don't want two channels to become one larger confusion. Once I can say what the voltage reading means, I can ask the equivalent questions about current and then about the relationship between them. The final power number depends on that relationship. It isn't only a matter of taking two finished labels and multiplying them together. The arrows give me a way to explain the system one relationship at a time. Once I can say what enters a stage and what leaves it, the complete drawing becomes a route I can follow.