Assembling Click V4

After weeks of routing traces in KiCad, tuning 3D enclosure tolerances, and updating firmware logic, I reached a massive milestone for Project Click: I assembled three physical units of the new RP2354A hardware revision.

Holding three fully assembled Click devices in my hands feels surreal. My entire professional background is in mechanical product design, CAD modeling, and plastic engineering. I know how to tune tactile button click feel, design snap-fit enclosures, and optimize DFM profiles. When it comes to low-level C++ firmware and PCB layout, I rely 100 percent on prompt-based AI as my virtual systems architect.

The new hardware design is significantly sleeker and more compact than our earlier ESP32 prototype. However, putting three real devices through physical testing immediately revealed our biggest hardware struggle yet: battery life.

The Compact Enclosure and the 380mAh Battery Shift

To achieve the slim, pocket-ready form factor that I wanted for Click, I made a deliberate mechanical change. I switched from our larger 400mAh battery cell to a much more compact 380mAh LiPo battery.

In mechanical CAD, the space savings were perfect. The new battery sits cleanly behind the PCB inside the snap-fit resin housing without bulging or placing stress on the display ribbon cable. But once I flashed the new firmware and ran active power tests, the battery drained far quicker than expected.

On paper, this should not be happening. The Raspberry Pi RP2354A microcontroller is known for its low power consumption, efficient internal voltage regulation, and flexible sleep modes. A 380mAh capacity should easily power a monochrome 128x64 OLED display and simple micro-applets for days of active fidgeting and weeks on standby.

Legacy Code vs. New Silicon

The root cause of this power drain comes down to a classic software artifact: legacy code.

Because I do not write C++ firmware from scratch, the initial codebase running on these three assembled units is built on logic originally optimized for our earlier ESP32 prototype. The ESP32 and the RP2354A handle power management, register states, and peripheral isolation in completely different ways.

While our event-driven OS manager uses a non-blocking state machine driven by elapsed time checks, the underlying hardware routines are not yet optimized for RP2354A silicon:

1. Unoptimized Sleep States: The light sleep routines currently do not fully power down unused internal clock blocks or force all floating GPIO pins into high-impedance states.
2. I2C Bus Leakage: The SSD1306 OLED display controller and I2C lines can draw parasitic current if the pull-up registers are not held in a clean INPUT_PULLUP configuration during idle periods.
3. ADC and Sensor Polling: The battery voltage monitoring circuit on GP29 reads through a 100k/100k resistive divider, but the sampling frequency is running continuously rather than sleeping between quantized reads.

In short, the hardware is capable of ultra-low power consumption, but the firmware is treating the RP2354A like an ESP32.

Handing Over 3 Units to Hardware and Embedded Experts

Instead of trying to debug deep register-level power states alone with AI prompts, I decided to do what open-source hardware is made for: collaborate.

I am handing over the three newly assembled Click devices to three of my close friends who are seasoned experts in hardware electronics, embedded software, and C++ firmware engineering.

Each of them will take an assembled unit, plug it into their bench instruments, measure exact current draws across active, idle, and sleep states, and help optimize the codebase specifically for the RP2354A silicon architecture.

Building an Open-Source Community Flywheel

From day one, the vision for Click has been 100 percent open source. My goal is to make hardware and electronics accessible to everyone, regardless of whether you are a mechanical designer like me, a software engineer, or a hobbyist who has never touched a PCB before.

Having expert friends debug these first three physical units is the first step toward building a true community around Click. Once they identify the firmware inefficiencies, fix the power leakage, and streamline the sleep recovery routines, all of those optimizations will be pushed straight back to the open-source GitHub repository.

If you are interested in low-level embedded optimization, reverse engineering power states, or writing custom 1-bit micro-applets, all schematics, STEP models, and C++ firmware files are available on GitHub.

I will share a full breakdown of our battery profiling results and power fixes in the next devlog once the team completes bench testing.