> ## 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.

# A useful reference is still a different circuit
- URL: https://sreekars-journal.labvion.com/pq-a04-this-drawing-uses-a-different-setup/
- Published: 2025-12-08T12:30:00.000Z
- Updated: 2026-10-29T08:13:31.000Z
- Description: The reference drawing and the ADS1115 program follow different routes. The drawing names ESP-WROOM-32, takes the sensor signals into the controller's ADC inputs and shows I²C serving an LCD. The application reads an external ADS1115 over I²C instead. I find the comparison useful because the pur
- Author: Sreekar
- Tags: Power meter, #Import 2026-10-29 10:08

The reference drawing and the ADS1115 program follow different routes. The drawing names ESP-WROOM-32, takes the sensor signals into the controller's ADC inputs and shows I²C serving an LCD. The application reads an external ADS1115 over I²C instead. I find the comparison useful because the purpose is similar while the connections carrying out that purpose differ. Recognising the same sensor names is not enough to make the drawing and code describe the same arrangement.

The reference is credited to CIRCUITDIAGRAMS.IN and ELECTROGADGET. That credit should stay with it. It tells the reader where the drawing came from and reminds me that I’m studying someone else's example. Including it in the project material doesn't turn it into my own schematic or establish that the photographed build follows every connection shown there.

I'm finding it useful to compare the job of a stage before comparing the parts. Both arrangements have to turn a signal into something a controller can use. In the reference, the ADC path is drawn directly. In the ADS1115 arrangement, an external converter reads its input and the controller communicates with that converter. The common purpose helps me learn, while the different route explains why I can't carry the wiring or settings across without checking.

That’s an easy mistake to make when reading quickly. I recognise a sensor, a controller and a display, so the whole picture starts feeling familiar. Then I might assume the arrows represent exactly the same data path. But the arrows are the important part. What signal enters the converter? Where does the numerical result go? Which program calls belong to that route? Recognising the boxes doesn't answer those questions.

![Third-party reference from the ZIP, visibly credited to CIRCUITDIAGRAMS.IN/ELECTROGADGET. It depicts a different direct ADC/LCD arrangement; it is not Sreekar’s final ADS1115 schematic or wiring instruction.](https://sreekars-journal.labvion.com/content/images/2026/10/IMG18.jpg)

Third-party reference from the ZIP, visibly credited to CIRCUITDIAGRAMS.IN/ELECTROGADGET. It depicts a different direct ADC/LCD arrangement; it is not Sreekar’s final ADS1115 schematic or wiring instruction.

The display is another example. An LCD in a reference can help show the idea of presenting a measured quantity. A display is at the end of the chain; the drawing's value for understanding one stage doesn't make it an exact description of the stages before or after it. I want to be able to say which part I'm learning from.

I'm treating the comparison as a reading exercise rather than a set of new wiring instructions. The actual board identity, input arrangement and connections have to come from the real setup and its documentation. There are already conflicting controller descriptions elsewhere in the material. Adding another unqualified picture would make that confusion worse, even if the picture is clear on its own.

The image's CIRCUITDIAGRAMS.IN and ELECTROGADGET credit belongs with it. It’s an example to learn from, and the difference is part of what makes it worth explaining. In one route, the controller handles the ADC input directly; in the other, an external converter supplies digital values to the controller. The saved wiring notes also describe an abandoned Pico plan before the ESP32 route. Keeping those versions labelled gives me a clearer picture than trying to fit every drawing into one final schematic.

An ideal note beside the reference would answer a few ordinary questions. Where is it from? What is it being used to explain? What differs in this project? Which drawing should someone use to understand the actual assembly? Those questions don't need a long defence of every borrowed idea. They need enough information that another person doesn't mistake an illustration of a principle for a record of the final build.

This matters to my own understanding too. If I use the wrong diagram while reading the code, I can spend time looking for a connection that the code was never written to use. The program may appear confusing because my mental picture belongs to a different circuit. Comparing the actual route first gives me a better chance of noticing that kind of mismatch before changing a working line for the wrong reason.

I want a drawing of the actual connections kept beside the photographs. The photograph shows the physical arrangement; the drawing should explain the electrical route. Neither does every job alone. A neat reference diagram can't certify the real assembly, and a photograph doesn't necessarily reveal every connection underneath a board. Together with the correct code version, they can make the account much easier to follow.

The source credit also helps keep my contribution clear. Learning from an existing circuit is part of building the project, and there is no reason to pretend otherwise. What I need to explain is which ideas I used, how the actual arrangement differs and what I personally configured or checked with help. The useful story is in that work, not in removing a name from a picture so everything appears to have begun with me.

I can still keep the reference. It has value as a comparison, especially when I can point to the exact stage it helps explain. The important change is in the caption and the way I talk about it. A reader should know immediately that this is another example, rather than discover halfway through the code that the picture and program describe different routes.

A reference is most useful when I can say which idea it explains and where the actual project takes another route. The comparison makes both the shared principle and the different connections easier to understand.