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

# Can the controller find the ADC?
- URL: https://sreekars-journal.labvion.com/pq-05-can-the-controller-see-the-adc/
- Published: 2025-06-19T12:30:00.000Z
- Updated: 2026-10-29T08:51:43.000Z
- Description: The scanner asks a wonderfully small question: does anything answer at this address? In the saved program, the loop tries addresses from 1 to 126, calls Wire.endTransmission and prints an address when the returned error is zero. It uses GPIO 8 for SDA, GPIO 9 for SCL and 115200 baud for the ser
- Author: Sreekar
- Tags: Power meter, #Import 2026-10-29 10:08

The scanner asks a wonderfully small question: does anything answer at this address? In the saved program, the loop tries addresses from 1 to 126, calls Wire.endTransmission and prints an address when the returned error is zero. It uses GPIO 8 for SDA, GPIO 9 for SCL and 115200 baud for the serial output. The later lab log gives a concrete result for this arrangement: one responding device at 0x48 on 19 June 2025\. That’s a communication milestone with a definite meaning.

I²C lets devices share communication lines while addresses identify which device the controller is trying to reach. I'm thinking of the scanner as a series of small attempts to start that communication. It goes through addresses and looks for a response. It isn't asking the sensor whether its measurement is accurate. It isn't testing every part of the ADC. That limit is useful rather than disappointing. A simple test is easier to understand when I don't ask it to answer questions it never attempted.

I'm reading the Wire calls in the scanner alongside the idea. The names can make it tempting to copy the sketch, run it and treat any printed result as complete success. I want to understand where the program begins a transaction and where it looks for the response. I don't need to memorise the library to make the test useful. I do need enough understanding to explain what the program tried, because otherwise a missing address could send me looking at the wrong part of the project.

The saved pin choices are definite: GPIO 8 for data and GPIO 9 for clock, with the ADC begun at 0x48\. They describe this sketch rather than every possible controller arrangement. The physical board version still matters when matching those software choices to the assembly, and the shared ground and supply belong beside the communication connections.

A failure helps me think about the order of checks. In this case, the scanner prints no address. That result doesn't uniquely tell me that the ADC is damaged. The program might be using the wrong communication pins, a connection might be unreliable, or the device might not be operating as expected. The scan has narrowed the question to communication. It hasn't chosen the reason for a failure. I still need the physical setup and the configuration beside the result.

The scanner also counts how many devices replied. If the count stays at zero, it prints a short connection checklist; after either outcome it waits five seconds and scans again. The 0x48 label is connected to ADDR being tied to ground in the described setup. I can follow the result through the program rather than treat the printed address as a mysterious success message. A response says that the transaction received an answer during the check. The gain, sensor relationship and later calculation still have their own jobs.

I want to keep a record of the configuration with the result, too. An address without the board and pin arrangement would be awkward to reuse. Repeating a test means repeating the relevant conditions, not just opening a file with the same name.

The other direction matters as well. In this case, the scan finds the address I'm expecting. That’s encouraging, but it doesn't prove the reading configuration is right. The next program could select an unsuitable range or convert counts with the wrong scale. The sensor could give a signal I don't understand. So I want to keep the scanner result as one stage in the explanation. It would be a shame to get a useful answer from a small test and immediately make it less useful by pretending it establishes everything else.

I'm also noticing how valuable a test can be even after I've moved on. If the full meter starts behaving strangely later, I can return to the scanner and ask whether the communication still works. That doesn't solve every problem, but it splits the investigation. It’s a way to stop several unknowns becoming one vague statement that the meter has stopped working. The simple sketch gives me a question I can repeat without also changing the RMS loop or the display code.

There’s something appealing about how little the first target asks for. I don't have to understand the entire ADS1115 configuration before I can learn something real about the connection. I can learn in pieces. At the same time, I don't want learning in pieces to become forgetting how the pieces fit. Finding the address belongs to the route from controller to ADC. Reading a channel belongs to the next part. Interpreting that channel's value is another part again. Each answer should make the next question clearer.

The useful achievement here is a question and answer I can interpret. Before voltage, current or power reaches the display, I have a smaller way to examine whether the controller is talking to the converter.