NerdMiner Modded v1.2.1 is out: the CYD now mines at ~990 KH/s, peaking over 1,000 KH/s with every hash checked.
Flash it from your browser: https://henryscat.github.io/NerdMiner-Modded/
Modded from the original to give ~950KH/s and some new themes.
GitHub https://github.com/HenrysCat/NerdMiner-Modded
Web flasher here https://henryscat.github.io/NerdMiner-Modded/
Why this hashrate is real...
The ~950 KH/s is what the miner actually hashes, not what a counter says:
- **Hardware limit** – the classic ESP32's SHA engine can't be loaded with an external midstate, so every nonce costs three hardware hash blocks plus two engine loads: about 228 CPU cycles of engine time, a ceiling of roughly 1.05 MH/s at 240 MHz. The mining loop keeps the engine busy for all but ~30 cycles of each nonce (257 cycles per nonce, ~930 KH/s); the second core adds ~25 KH/s in software.
- **Measured on the chip** – the loop's timing comes from an on-device bench (`-D SHA_BENCH`, see `src/sha_bench.cpp`) that checks every single hash against software, also while the other core hammers the peripheral bus. That is how the hardware quirk behind silently corrupted hashes in the usual pipelined loops was found: writes to the SHA registers less than three cycles apart can be dropped whenever the other core is using the same bus.
- **Only valid hashes are counted** – every candidate the hardware finds is recomputed in software before it is used. A hashrate counter on its own can look faster after an optimisation while the miner is quietly producing *fewer* valid shares, because corrupted hashes are still counted; here the firmware checks itself with a known-answer test at power-on and falls back to a slower loop if the fast one ever gets hashes wrong.
- **The rate is the rate it actually mines at** – it's the sustained average over a long run, not a short burst or a best-case peak.If a number sounds too good for this chip, check whether the shares it finds actually keep up with it.
I managed to squeeze around 650KH/s out of the Cheap Yellow Display with Claude, the photo is running on Heliospool, download here and flash with any online esptool
Flash factory file at 0x0 for first install
Flash firmware at 0x10000 to keep settings and update
So, after 2 failed CC2 cams I decided to try another one https://www.inno-maker.com/product/u20cam-1080p/
Its just a standard UVC camera and it works, I had to make an adapter as the orginal CC2 connector is 4 pin JST-ZH 1.5mm and the Inno-maker cam is a 5 pin PH 2mm or XH 2.5mm not quite sure but it did come with a cable so I cut that and added a ZH socket (the 5th pin the Inno-maker is just shield so not needed)
Its slightler wider at around 110 degrees where the stock CC2 cam is 90 degrees, but it works, even managed to design a mount in FreeCAD, bit bodgy but it works.
Hope this helps as the stock is clearly no good.
EDIT: here is the mount I designed, not very good but it works, also included the FreeCAD file in case anyone can improve it ;)
https://www.mediafire.com/file/6oagajuzylo78un/CC2_U20CAM_Mount.zip/file
I wanted a good brute force prevention plug in but it seems the all the good ones are paid or at least limited until you buy it, so I asked Claude to make one with all the features I wanted from various others and thought I would share for all to use, so here here it is, enjoy.
Had a couple of requests for the bigger display, it will actually works on both the 2.8" ESP32-2432S028R and the 4.0" 320x480 ST7796S just in case you have not seen it before.
Wanted to share a side project I've been building over the last couple weeks: a fully touch-driven desktop "flight radar" that shows real air traffic around my house in Buenos Aires, pulling live data from the OpenSky Network API.
Hardware:
What it does so far:
Auth to OpenSky is OAuth2 client-credentials, refresh rate adapts from 30s down to 5s automatically when a plane gets close (<10km) so I get near-real-time updates only when it matters.
Fun fact: getting the touch calibration wizard working with a wildly wrong pinout (copy-pasted from a tutorial for a different board) was 80% of the actual debugging time. Also found a nasty ArduinoJson gotcha — filtering a JSON array by numeric index re-indexes the result from 0, silently breaking every field position downstream. Cost me a full "why is nothing showing up" afternoon.
Not open-sourcing the repo just yet — still polishing the radar animation (working on a proper rotating sweep effect) and a full WiFi provisioning + web config portal so it's not hardcoded credentials anymore. Will share once that's in.
Happy to answer questions about the OpenSky integration, touch calibration, or the JSON gotcha if anyone's fighting similar things.
I started this project as a few educational games for one of the inexpensive ESP32 “Cheap Yellow Display” boards.
It gradually turned into a complete little console firmware called Braino!, with 31 games and activities, player profiles, persistent scores/progress, settings, diagnostics, sleep/lock behavior, optional Wi-Fi/BLE features, and a browser installer.
The part that became most interesting to me wasn’t adding more games—it was figuring out how to make all of this coexist on fairly constrained hardware.
My reference board is an original ESP32-class CYD using an ESP32-32E, 4MB flash, no PSRAM, and a 320×240 resistive touchscreen.
I could have moved the project to an ESP32-S3 with PSRAM, but I specifically wanted to see how far I could push the cheap boards people already have.
The CYD is also appealing because almost everything needed for the project is already on one inexpensive PCB:
No custom PCB is required.
For display and touch I’m using TFT_eSPI.
One of the early architectural decisions was not to make the UI dependent on a large full-screen framebuffer. Without PSRAM, I wanted the firmware to be able to render directly and update smaller areas when practical.
I learned why this matters while working on one of the Simon-style memory games.
My first version simply redrew most of the screen every time the sequence changed. It worked logically, but on the physical TFT it produced an obvious full-screen brightness flicker.
I changed the rendering so only the pads whose state changed are repainted.
That removed the distracting flash and also reduced unnecessary drawing.
That experience influenced the rest of the UI quite a bit: redrawing the entire screen because it’s convenient is not always the best approach on these displays.
Several games include visual datasets rather than just generated graphics.
For example, the firmware contains things like:
I deliberately compile those assets into the firmware rather than requiring an SD card or network connection.
The advantage is that the console is completely standalone.
The downside is that graphics consume a surprisingly large amount of flash.
The firmware therefore uses a larger application partition, and I’ve had to pay attention to what gets compiled into the main application rather than assuming 4MB is effectively unlimited.
There’s also an optional BLE/Nearby feature.
For that I use NimBLE-Arduino rather than the heavier traditional ESP32 Bluetooth stack because the firmware only needs a relatively small subset of BLE functionality and flash/RAM usage matters on this board.
The BLE wire format produced another interesting limitation.
The Nearby data fits inside the traditional 31-byte BLE advertising payload, but it is packed tightly enough that even changing something like the device-family identifier can affect the protocol.
So something that looks like a UI/product naming change can actually become a wire-format compatibility problem.
Another problem appeared when I started looking at other CYD variants.
Different boards can use different:
I didn’t want the application to turn into this everywhere:
if (boardA) {
// pin X
} else if (boardB) {
// pin Y
}
So the hardware configuration is separated into board profiles.
Board-specific information lives under the board configuration layer, while games and higher-level application code use the shared configuration.
There are now builds for multiple CYD variants.
I have not personally tested every one of those boards yet.
That’s actually one of the reasons I’m posting here. If somebody has another CYD revision and wants to flash it, reports about display, touch, backlight and orientation would be extremely useful—even if the report is “this completely fails.”
The project is built with PlatformIO.
The main external pieces include:
I eventually pinned the PlatformIO platform and library versions instead of leaving floating dependency ranges.
Once I started publishing binaries and tracking firmware size, it seemed wrong for somebody checking out the same commit six months later to silently receive a different compiler/library combination and potentially get a different result.
Development still uses PlatformIO normally, but I didn’t want somebody who just owns a CYD to have to install an embedded development environment before they could see whether they like the project.
So the release system generates prebuilt firmware and manifests for ESP Web Tools.
That means supported boards can be selected and flashed directly from Chrome/Edge.
The website generation itself is also exercised in CI so documentation/site changes don’t silently break the public installer.
Everything is GPLv3 and the complete source is here:
https://github.com/iamankushpandit/Gume
Browser flasher:
https://iamankushpandit.github.io/Gume/
There are currently 31 games and activities, but at this stage I’m probably more interested in outside testing and engineering feedback than simply adding game #32.
I’d particularly appreciate:
If anyone tries it, let me know exactly which CYD you used and what worked or broke.
And if you enjoy the project, a GitHub star is appreciated, but technical feedback is even more useful to me right now.
PS : I forgot to mention https://github.com/iamankushpandit/map-n-flag If anyone wants to use country and US state flags for their ESP32 CYD projects.
Posted this a while ago but there have been improvements since then, better quality map image, improved colours on propagation pages, added smooth scrolling to DX spots page.
Two new dashboard pages, taking the total to seven.
PSKReporter — reception reports for your callsign plotted on the world map, one marker per four-character grid, coloured by band, with a band legend and a furthest-report line.
POTA Spots — live Parks on the Air activator spots, with an optional great-circle distance filter from your locator and an option to hide automated RBN spots.
With a lot of help from Claude I managed to put together a little dashboard for the ESP32-2432S028R Cheap Yellow Display, it collects the data from a Docker container that connects to your OPNsense box via the api, 8 pages and a web ui to change settings.
Hope you like it, full details on GitHub
For the ESP32-2432S028R Cheap Yellow Display: live conditions and forecasts from your choice of 20 weather data providers, on-device history logging and trend graphs, sunrise/sunset and moon phase, configurable alerts, and a built-in web portal for setup — no companion app or cloud account required. GitHub link
ESP32-S3 Touch AMOLED 1.75C development board. Over four evenings, it somehow turned into a surprisingly nice little thingy.
It was very much a vibe-coding project. I guided some visuals, and forced optimization implementation decisions: how the display buffers and PSRAM should be used, which regions should be redrawn, how assets should be cached, and how animation should remain separate from slower network updates.
Getting beyond a basic mockup was a large part of the work: smooth radar and aircraft animation, partial screen updates, cached maps and imagery, and avoiding expensive full-screen redraws on the 466 × 466 gorgeous AMOLED.
It currently includes:
There are still things to polish, but I’m amazed by how much this little ESP32-S3 can handle when the rendering pipeline is designed carefully.
View the complete Aerospace Tracker interaction guide (PDF)
Source code is not yet public but I may do it sometime in the future if people are interested.
UPDATE:
The board: https://docs.waveshare.com/ESP32-S3-Touch-AMOLED-1.75C (got from AE for ~$40 i think amazon also has them). Mainly ordered due to OLED.
The dock: https://a.co/d/012B5Kl2
I used 3 services for tracking in cascade: open sky -> airlabs (when open sky not providing enough info, requires API key but free tier seems to be enough for my use case) and flightaware for specific flight tracking (same as airlabs, requires API key but has free tier).
I will make the code public soon since people are interested, but current implementation does require a mac, since the initial setup is done through mac companion app. I'm not planing to change that since that was my preferred route.
Used Claude to port GBADoom to the CYD board, full info on how to get it running on GitHub.
NerdMiner v2 modified by Claude.
https://www.mediafire.com/file/jf4naumsjz5f0yt/NMv2_Claude_ESP32-2432S028R.zip/file
Mining performance
Stability
abort()): classic ESP32's SHA hardware locks per algorithm type, so mining's SHA256 lock didn't block mbedTLS's SHA384 use during pool-API TLS handshakes — added a dedicated mutex closing that gap (soak-tested: 0 crashes over 1 hour)Pool stats
New feature
Auto-detects ILI9341 vs ST7789, walks you through touch calibration and orientation, tests every peripheral (SD, RGB LED, speaker, WiFi...), and spits out a report saved to SD card. Built with Claude over a few days of back-and-forth. https://github.com/HenrysCat/ESP32-2432S028-CYD-Diagnostic-Tool
I tried a few already out there but just didnt like them, so I asked Codex to make one for me, it includes HamQSL propagation data, a greyline map, DX spots, Wi-Fi setup, and a local web settings page.
Open source and on GitHub hope you like it.
Now we can use things like esptool, it's disabled by default so go to about:config and switch dom.webserial.enabled to true.
https://hacks.mozilla.org/2026/05/web-serial-support-in-firefox/
I tried a few already out there but just didnt like them, so I asked Codex to make one for me, it includes HamQSL propagation data, a greyline map, DX spots, Wi-Fi setup, and a local web settings page.
Open source and on GitHub hope you like it.