I've been building this for about two months and recently open-sourced everything. Patternflow is a custom ESP32-S3 board driving a 128×64 HUB75 LED matrix with 4 rotary encoders. Each pattern runs natively on the chip and the knobs map to pattern parameters in real time.

For context: I'm a visual design student, not an EE. Most of what I know about embedded came from this project, so this post leans toward the stories I actually lived through rather than firmware internals I'd struggle to defend.

Hardware

• ESP32-S3-WROOM-1 N16R8 (16MB flash, 8MB PSRAM)
• 128×64 HUB75 RGB LED matrix, driven by mrcodetastic/ESP32-HUB75-MatrixPanel-DMA
• 4 rotary encoders with push-buttons
• USB-C, single PCB
• Arduino IDE + ESP32
• KiCad sources in the repo
• 3D models(STL), Blender file in the repo

Cold boot bug

Most useful thing I learned. The board wouldn't reliably boot on first power-up; needed a manual reset or a power cycle. Symptoms were confusing:

• Quick reconnect (<1 min from unplug) → boots fine
• Long unplug (3+ min) → fails to start firmware
• Reset button → always works

Spent close to two weeks chasing this, mostly down wrong paths (slowing EN rise time, removing a 1000µF bulk cap that turned out to be a USB inrush violation but unrelated to the boot bug, pullup on HUB75 OE).

Actual root cause: GPIO0 was left NC in my original pinout. It's a strapping pin sampled at power-on — HIGH = normal boot, LOW = serial bootloader. With nothing on it externally, residual charge held it HIGH on quick reconnects (firmware ran). Long unplugs let it discharge into indeterminate territory, sometimes reading LOW on cold start → ESP entered bootloader → firmware never ran. Reset re-samples strapping pins under different conditions, so reset always worked.

Fix: 10kΩ pullup from GPIO0 to 3V3. Per the S3 datasheet, GPIO 0, 3, 45, 46 are all strapping pins and shouldn't be left floating.

Failed remote-streaming attempt

Tried building a mode where shaders authored in the browser (WebGL2/GLSL) are streamed live to the ESP32 and rendered on the panel — no firmware rebuild, and patterns too heavy for the chip become viable.

Data path: Browser WebGL2 → readPixels → chunked over WebSocket → ESP32 triple buffer → render task on Core 1 → HUB75.

Stalled at 13–17 fps with visible tearing and occasional brief blackouts.

Bottleneck identified: per-pixel drawPixel calls — ~70 ms just to call it 8192 times. The HUB75 library author has acknowledged in discussion #117 that per-pixel calls cap well below 30 fps on this stack, and the only paths forward are writing directly into the BCM bit-plane buffer or forking the driver.

Shelved for now. If anyone here has actually pushed HUB75 past the per-pixel call ceiling — BCM bit-plane writes, library fork, alternative driver — I'd really like to hear how.

Links

• Website: https://patternflow.work/
• GitHub: https://github.com/engmung/PatternFlow
• build guide: https://github.com/engmung/PatternFlow/blob/main/docs/BUILD.md
• More story: https://patternflow.work/journal/en

Happy to talk about the hardware, debugging, the remote-streaming attempt, anything.

Hey!

Some of you might remember Patternflow — ESP32-S3, 128×64 LED matrix, 4 knobs, a device for generative patterns. 17 days ago I open-sourced it (the Open Source Hero badge still doesn't feel real, thank you). Here's where it's gone since then. A few things happened I didn't expect.

Someone actually made a pattern.

This is the part I keep going back to. A few days ago someone took the JS pattern template, wrote their own, and sent it to me. I helped port it to C++, and we posted it as a collab on our Instagram. Flashing someone else's code onto my hardware and watching it run was a weird feeling. Good weird. It's the whole reason I open-sourced this thing, and it happened faster than I thought it would.

The porting wasn't perfectly smooth, so I'm writing up the gotchas as a GitHub issue

The v2 build guide is real now.

The original docs were placeholder, honestly. The new one walks through four stages — parts, PCB, assembly, firmware — and there's a 3D preview on the site that updates per stage. It's here.

The cold-boot bug some of you helped debug (pull-up on GPIO0, for anyone else hitting it on AliExpress ESP32-S3) is fully fixed in v2.

Why AI is in this workflow.

The original section was unclear, so let me lay this out properly. AI shows up in two places:

1. JS for web preview. I sketch patterns in JS first so I can see them in the browser quickly. AI helps translate what I want into that JS.
2. JS → C++ port. Once a JS pattern looks good, AI helps convert it to C++ that runs on the ESP32.

The pushback focuses on #1. #2 is more accepted because it's well-defined code-to-code translation. But structurally, they're the same operation. #2 translates JS to C++. #1 translates an English description to JS. Same operation, different input format. If AI translating between two formal languages is fine, the case for AI translating from a looser source into a formal one rests on the same structure.

There are two reasons AI is here:

One: showing the device's range. The patterns I post daily on Instagram aren't curated artwork. They're mass-produced to demonstrate that this hardware can run a wide variety of generative styles, not just one aesthetic. AI lets me produce enough variations that the breadth becomes visible. Hand-writing every one would mean one pattern a month and nobody understanding what this thing can hold. (Side observation: audience reactions are wild. Ones I think are beautiful flop. Ones I'd discard go to 70k+ views. One did, this week. I clearly don't understand what people see.)

Two: keeping the door open to non-coders. My main goal with Patternflow being open source is that someone with no coding background can sit down and make their own pattern. The end artifact is still algorithmic code — noise, weighted random, modular arithmetic, reservoir sampling, exactly the techniques the top comment listed. AI is the bridge that gets a non-coder from "I want it to feel like X" to working code on the board.

There's a more general point underneath this. Most of us didn't get into coding because someone handed us a math textbook on day one. We got in because something small worked first — an LED blinked, a hello world printed, a sketch ran — and that "oh, this is mine" moment made the harder learning afterward feel worth doing. Interest came first. Discipline came after.

For someone with no coding background today, AI can be what produces that first "oh, this is mine" moment. It doesn't replace learning fundamentals — it gives them a working thing they care about, so that when they later open the code and want to know how it actually does what it does, the learning has something to anchor to. If a non-coder uses Patternflow with AI help, makes a pattern they love, and a month later starts reading the source out of curiosity — that's exactly the path I'm trying to build.

For what it's worth, I personally love the fundamentals. I plan to hand-write my own patterns eventually, and I think that's where the real art lives. The AI workflow exists so the system is open to people who don't have that background yet, not because I prefer it for myself.

The "gacha" framing in the original was about where #1 still falls short — current LLMs aren't reliable enough yet, maybe 1 in 10 outputs is interesting. So my next step is making that bridge more dependable: define the algorithmic primitives (noise type, color rule, knob mapping, motion function) as constrained options, let the LLM combine them, and always have a human tune the result. If anyone has better workflow ideas in that direction, I'd really like to hear them.

One question I want to ask you.

From the waitlist survey: about half of respondents said they want to make their own patterns rather than just run preset ones, and a handful asked about MIDI and OSC. I hadn't planned for performance use from the start, but the more I think about it, the more it fits.

If you have opinions — USB MIDI, network OSC, both, neither, something else — I'd really like to hear them. I'm at the stage where decisions stick.

More context

If you want the long, more personal version of all this, I wrote a blog post about it over the weekend — originally in Korean, translated to English. Fair warning, it's long.

https://patternflow.work/journal/me-and-patternflow

This subreddit has been a big part of why Patternflow kept going. Still is.

Hi everyone. Putting myself out there because I've been stuck on this for a while.

Quick context: I'm a visual design student, not an EE — this is my first custom PCB, designed after maybe 2 days of fumbling with KiCad. So apologies in advance if I'm missing something obvious. My friend who knows electronics has been helping but we're hitting a wall, and we'd rather not just slap an external reset IC on it without understanding what's going on first.

What it is

Generative pattern art piece. ESP32-S3-WROOM-1 (N16R8) driving a 128×64 HUB75 LED matrix, with 4 rotary encoders for control. Repo: https://github.com/engmung/PatternFlow

The problem, with what I think is the key diagnostic pattern

On cold power-up, the board often fails to start — LEDs stay off, firmware doesn't run. Pressing the reset button always works, 100% of the time, and once it's running everything is rock solid (WiFi, full brightness, encoders, all fine indefinitely).

The interesting part is a clear time-dependent pattern. Originally, before any bodges:

• Cold power-on: never boots on first try, always needs reset
• Unplug, then plug back in within ~1 minute: usually boots fine
• Unplug, wait 3+ minutes, plug back in: fails again, just like a cold start

So whatever's going wrong seems tied to something slowly discharging while the board sits unplugged. Quick reconnect = OK, leave it sitting = fails. That's our most distinctive clue.

After my friend added the 330Ω bodge (described below), cold power-on started succeeding sometimes — went from always-failing to intermittent. The time-dependent pattern stuck around though.

So the chip, firmware, and wiring all seem fine. The failure is purely in the power-on sequence.

Hardware

• ESP32-S3-WROOM-1 N16R8 module on my custom carrier PCB
• 128×64 HUB75 LED matrix
• 4× rotary encoders w/ switches
• Powered via USB 5V from a regular power bank (no PD, ~2A capable)
• Power doesn't seem to be the bottleneck — full white runs fine once booted
• Side note: HUB_A is on IO46, which is a strapping pin. I've since learned that's not best practice; not sure if it's relevant here.

What we've tried (rough chronological order)

1. Caps on the EN line, up to 1000µF — no help, just made boot slower
2. Various resistors between EN and GND — no effect
3. Resistors between RST and GND — no effect
4. Delaying system init in firmware — no effect
5. 10kΩ pull-up on the HUB75 OE line (the theory was OE floating LOW during boot causing panel full-white inrush and a brownout) — no effect. The bodge wire is visible in the photos. So I think we can rule out the panel-inrush story.
6. Added a 330Ω resistor between 3V3 and the RST/EN pin (visible in photos, alongside the existing 10kΩ pull-up). This is our current best fix. Cold boot used to fail every time; now it's intermittent. Reset still always works.

Friend's working hypothesis

Slow EN rise time, with something on the EN line (or upstream of it) holding a charge that takes a minute or two to dissipate. Quick reconnect catches it before it's fully discharged → fast EN rise → boots OK. Slow reconnect → fully discharged → slow rise → ESP32 ends up in some undefined boot state. The 330Ω bodge improves the rise time but doesn't fully fix it, so something else is also at play.

What I don't have

• An oscilloscope, and honestly I don't really know how to use one yet
• Serial logs from a failed boot — board's fully assembled in its enclosure and the UART pins are awkward to get to without disassembly. Happy to do it if it'd be the deciding piece of evidence, just wanted to ask first.

Questions

1. The time-dependent pattern — quick reconnect works, slow reconnect fails — does that ring any bells? Feels like the key clue but I don't know what it points to.
2. Given that reset always works and post-reset operation is stable, this seems like a pure power-on sequencing problem rather than anything wrong with the chip, firmware, or wiring. Does that read right to you?
3. Could the IO46 strapping-pin loading be contributing? What's the typical symptom if so?
4. If we can't fix this on the existing PCB, what would you reach for as an external reset solution for ESP32-S3? I've been reading about TPL5010, MCP130, DS1813, or a basic 555 RC delay holding EN low for a few hundred ms. Curious if there's a usual go-to or anything to avoid.
5. Anything else we're obviously missing as beginners?

Detailed debugging history with my friend's notes — https://github.com/engmung/PatternFlow/issues/16

Thanks for reading. Happy to provide any other info, run any tests within my limited toolkit, and I'll come back to update the thread once we figure it out — for posterity if nothing else.

Hey, 12 days ago I posted my 4-knob LED pattern controller here and the response was way bigger than I expected.

What changed since then:

- Designed my first PCB in KiCad (PCBway sponsored the manufacturing after seeing the original post — huge thanks)

- Swapped all 4 potentiometers for rotary encoders with push switches

- Cleaner case design to fit the new PCB and encoders

- All files on GitHub: schematics, PCB artwork (Gerber), 3D models for the case, firmware

I also built a website and just wrote the first post on it — a long build log looking back at the whole journey, in both English and Korean. Wrote it today while pausing to think about where this is heading.

GitHub: https://github.com/engmung/PatternFlow

Site + build log: https://patternflow.work/journal/v1-30-days

If it's useful to you, a star on the repo would mean a lot.