completing my first hardware project with an LLM
part 2: completing construction of my solar-powered battery pack, field testing, LLM learnings
TLDR: I built a solar-powered charger from scratch for a backpacking trip to Banff with Claude’s help and no hardware experience. This post covers how I soldered permanent connections, completed the charger, and field tested it. It worked! (mostly) and taught me a lot about leveraging LLMs for physical builds: what worked, what didn’t, and how it can be better.
context
Last month I built a solar-powered battery pack to charge my electronic devices on my backpacking trip to Banff. Part 1 covered the beginnings of the project + building the MVP. This part covers the completion of my project and learnings on using LLMs.
soldering permanent connections
The MVP of my charger worked with breadboard connections. But the breadboard was too big for my junction box, so I had to solder permanent connections (across my ESP32 - my Arduino board, my current sensor, my solar controller, and the power sources to my Arduino, the charger, and the solar panels) through a perfboard.
To create permanent connections to the perfboard I cut the heads of my dupont cables and stripped the wires to reveal the copper:
The goal was to join these three sets of copper wires together via the perfboard so they could each connect to one of the three devices I needed power / data to flow through. The breadboard did this with internal infrastructure that connected all the pins and wires, but the perfboard is a thin piece of fiberglass with a grid of holes. To join these connections permanently, I needed to learn how to solder!
Soldering involves melting iron filler (the “solder”) to join two or more pieces of metal together. I watched a quick tutorial on Youtube demonstrating how to do this since Claude did not sufficiently brief me. Below is the soldering iron I used, the curly wire is the solder, and the damp sponge was used to clean my iron every so often to remove the oxidation on the iron.
In the gallery below, the top and middle right images depict my first attempt. There’s sort of an ugly bubble. Middle left is the other side of my first attempt - sort of ugly indeed.
But after sacrificing the first connection, you can see in the bottom left and right photos that my technique vastly improved: there are shiny little peaks and no ugly bubbles!
The result was 4 sets of connections of 3 cables. As mentioned in part 1, the 4 connections are 2 power connections and 2 data connections:
power connections:
ESP32 3.3V ⇔ INA219 VCC ⇔ OLED VCC (voltage at the common collector, refers to the positive power supply)
ESP32 GND ⇔ INA219 GND ⇔ OLED GND (ground, common reference point in a circuit which is typically the zero-volt potential against which other voltages are measured)
data connections:
ESP32 A4 ⇔ INA219 SDA ⇔ OLED SDA (serial data, used in the I2C communication protocol)
ESP32 A5 ⇔ INA219 SCL ⇔ OLED SCL (serial clock, the other wire used in the I2C comms protocol - together with SDA, it facilitates communication between electronic components, like my controller and sensor)
I was also excited to solder pins to my INA219 current sensor that were previously disconnected and kept falling out. In the photo below, each of the six little iron mounds is my handiwork (the pins stick out the other side and connect to the other components via female-ended dupont cables.)
getting a little ambitious
After completing those soldering jobs, I figured I’d solder together my two pairs of red and black cables that connected the current sensor to the controller. Previously, I’d shoved all 4 cables into the green input terminal on the sensor. The copper wire was a bit exposed and got all tangled, which was problematic. I figured if I soldered them together, all the wires would fit in the terminal cleanly.
This proved to be challenging - my solder jobs ended up being too thick, as pictured below. Eventually, I used the iron to melt down the huge blobs of iron such that they could fit inside the terminals effectively, but this took a bit of iteration.
debugging
Another challenge arrived when after soldering everything, my OLED display stopped working. With Claude’s help (sort of) I traced the root of the problem.
First, the OLED wasn’t displaying anything at all. Claude suggested I check if it was a connection or power issue. I realized that the ESP32 itself wasn’t working properly, as nothing was updating in the IDE. This was a rookie mistake, as I wasn’t saving my IDE settings properly when I first entered the code. Think Claude incorrectly assumed I knew what I was doing in the IDE environment, perhaps as a result of my trying to prompt it to give me succinct answers instead of blasting me with 600 word responses at a time.
From there, I ran a simple test to see if the OLED was working by having it print “hello world!” This took a few attempts, and it eventually worked. But then no matter how I updated my code in the IDE, it remained stuck on hello world. This was eventually boiled down to an I2C address conflict.
I fixed that, but Claude forgot that my INA219 library had a different syntax which I then needed to fix as well. After we got those adjusted, it started reading accurately from the sensor again.
heating it up!
Once my components were reading correctly, it was time to place everything (battery pack, controller, ESP32, sensor, and the perfboard connections) inside the junction box. I wanted to have two cables coming out of the box - one for the connection to the solar panel, and one for charging my devices with.
The heads of my charger cables were too thick to fit through the holes I’d drilled into my junction box. So, I severed the charging cables and rejoined the internal wires by soldering them together before sealing them with heat shrink tubing so the cords could cleanly pass through. Jank but effective.
This ended up being a ton of fun because watching heat shrinking the tubing was sort of silly and magical. Heat shrink tubing works by placing a piece of tubing (the red, yellow, and green tubing pictured below) over the junction you want to cover that’s slightly roomy. Then with some heat - I used a hair dryer - the tubing shrinks to fit snugly around the junction!
There were a few layers of tubing to shrink - the first was in reconnecting my wires after cutting them in half then soldering them back together - these exposed copper wires needed to be covered for safety. You can see this process in the top two pictures within the gallery below.
After those were all sufficiently covered there were a few hiccups along the way. I had to redo a few because dumb and needed Meghna’s assistance (shoutout Meghna Mahadevan, pictured bottom left in our living room, the lab) for helping me hold these pieces while I soldered them. Then I recombined the pieces of the cable in one green covering (pictured bottom right).
wrapping it all together
Below is an example of how the components look in the box before they each found their permanent homes (taped down). I failed to take a photo after the heat shrink tubing process in my excitement to complete it, but this demonstrates how the junction box looks with just one cord coming out of it and connecting directly to my solar panel.
Further below, there’s a photo of the two wires coming out of the box. It’s a little chaotic and the box is bigger than I would’ve liked, but you win some you lose some. At this point everything’s working and it’s ready for the real world.
headed to banff
I packed the charger into my carryon bag the next morning. Luckily TSA had no questions for me despite it looking slightly suspect.
After we landed in Calgary, I started charging the battery pack on the ~2 hr car ride. The battery pack charged pretty slowly because the panel is just somewhat inefficient. After about 1.5 hrs of charging under not-so-direct sunlight (it was already ~5pm at this point) it charged about 5%, from about 55% to 60% capacity. To be clear, not the most time-efficient solution. Would not give it an A+ or even an A- for performance.
But it was fun and cool to then charge my phone and watch with (some) solar power before we started the backpacking journey!
on the trail
Below you can see that I clipped the solar panel to the top of my backpack, box left inside. The intention was to just charge it whenever we were in direct sunlight. Ultimately, it ended up a) being not that sunny so opportunities for direct exposure were rare, b) I didn’t use my devices all that much (I think I charged my phone and watch probably 1x over the course of 3 days being in backcountry Banff and c) I was generally too busy having fun and enjoying the park to remember to charge it.
LLM learnings
Building this was fun, surprisingly doable, and very instructive. I definitely wouldn’t have been able to finish it without an LLM, and I’m super grateful for its help and very impressed with the model’s capabilities.
This project taught me a lot about using LLMs and has shaped what I’m interested in working on next. Thoughts below!
why I picked Claude
I used Claude Sonnet 4. When asked why I chose it, my very honest answer was mostly vibes. The engineers on my team use Claude code so GPT wasn’t really in vogue, and while I primarily use 4o for other personal / work projects, I wanted to try a different tool to spice things up.
In hindsight, had I not been focused on getting this done as quickly as possible and committed to sonnet 4 early on, I would’ve prompted some other models with the same questions to compare responses or noodled more on optimizing tool selection. I think some combo of 4o + o3 or even o4 might’ve been a more effective partner. I’m sure engineers can think of much better tools as well that I could use instead but here we are.
what Claude was good at:
accessibility + breaking down concepts
Claude was great at breaking down technical concepts (wiring, circuitry) into plain English that was easy for someone with no engineering background to understand and apply.
research assistance (+ consolidating and vetting materials)
Researching and evaluating materials + doing comparisons across them was super easy with just some internet links.
navigating software
Setting up my Arduino ESP32 was pretty easy - its suggested effective code with minimal prompting and had good awareness of libraries + syntax involved.
interpreting visual aids
Claude was remarkably good at responding to photos / diagrams, making it at least 10x a more effective partner.
where Claude struggled:
context retention
Forgetting things because of a narrow context window and then hallucinating is perhaps the most obvious and universal pitfall. The materials I shared with it could have been more robust, but Claude often forgot the sizes of the items I was using despite having listed the specs for me further up the context window.
It was also bad at recalling decision tree logic across sessions. I did this project across 3 days, but even forgot decisions that were within the same chat window (e.g., it would continuously suggest that I use breadboard connections after I said we were pivoting to soldering permanent perfboard connections).
spatial awareness
Again, very obvious with hardware. Claude does not have eyes and without a constant data stream it struggled with reasoning around layout and placement and joining more complex pieces, providing nonsensical suggestions at times. Learning how to solder was impossible without watching video demonstrations on Youtube.
safety awareness
It never proactively flagged risks and sometimes made straight up bad suggestions that could’ve been dangerous - I often double checked procedures explicitly out of common sense.
troubleshooting inefficiencies
It missed some obvious fixes and gave verbose but impractical suggestions.
when all else failed, it gaslit me
When I rejected its recurring breadboard suggestions, it cheerfully agreed and said “you’re right! we’re just using it for testing right now!” We weren’t. But on brand and amusing.
future experiments & wishlist:
better memory + context retention: would probably be aided by better prompts, uploading full data sheets + wiring diagrams at the start. Finding these should be easier with Claude too.
LLMs + CAD or simple 3D modeling: I want real-time spatial feedback and the ability to create simulations before building which should help eliminating some troubleshooting and waffling around the design process.
a debugging assistant that can combine visual interpretation + tutorial search + diagramming: It’s great when I manually upload photos but falls short with more complex workflows that might require video demonstration. My build was pretty simple and even then it was hard to get a good shot sometimes.
multimodal tools & other sources of data input like video, voice, screen + keyboard monitoring, other sensors / streams. Integrating the right sources of data is probably the biggest barrier here for giving the LLMs visibility. Had a great chat with Hudzah and Anson Yu about these and thanks again to Rahim Iqbal for his thoughts too!
This was my first hardware build! It reminded me that doing is often the best form of learning. It taught me that we’re getting close but aren’t fully there yet to making LLMs reliable partners for this type of work. Most hardware engineers I’ve talked to have validated that their teams don’t use AI-native tools in their day to day workflows and that it’s pretty painful.
If you’re also exploring this space - physical projects, LLMs, hardware, energy, etc - I would love to connect.
Until the next one!
5% charge using the sun is definitely A+- congrats!!