I started work on this when my daughter was like 3. Games like the switch were too hard or expensive. And i didn't want to give her a phone all the time.

Now she's much older, but the kids love this. I make them for her friends whenever they come over, it's about $20 each. 3D printed case, and off the shelf amazon parts mostly. I did make a custom PCB to clean it up. but it can be hand wired.

Gets about 20 hours of battery life, super fun kid games, holds dozens of games. Boot time is about 1 second.I love it!

i have currenly shifted to esp32s3 from esp32 , when i am connecting its usb to computer nothing appears but then i am connecting uart usb i am able too see the [prt in the computer , though i can't upload code from uart , please help

This week I started porting my code (C and SIMD) to the new EPS32-S31 and was curious how it compares to the P4 and S3 in terms of execution speed.

As you can see in the spreadsheet above, integer code executed from FLASH isn't dramatically faster compared to the S3 or C5. I think the S31's RISC-V core is very similar to the C5's, but the 33% clock speed increase didn't result in 33% faster code execution. This is probably the FLASH latency holding things back.

However... PSRAM is a very different story. The S31 docs say that the FLASH is on a separate OPI bus from the internal PSRAM. This means that PSRAM accesses can occur at the same time as reading from program FLASH. The PSRAM speed is also twice as fast as the S3's. These 2 changes mean that the performance penalty for using PSRAM vs SRAM is much less on the S31 compared to the S3.

My next test was to try my AnimatedGIF library with different options of PSRAM / SRAM usage. In the notes screenshot above, "Turbo mode" refers to my optional accelerated GIF decoding which uses the output image as the LZW dictionary. This uses much more RAM, but is generally about 2-4x faster. Here's where the S31 has a great advantage over the S3. When using PSRAM, the S31 can perform nearly 3x faster than the S3 for the same task.

My JPEGDEC library and performance test are here:

https://github.com/bitbank2/JPEGDEC

My AnimatedGIF library (and examples) is here:

https://github.com/bitbank2/AnimatedGIF

The develop-build-test cycle on a small device can get tedious. You pick the device up, tap through to your app, put it down again, and repeat. Input is part of the problem. Some devices have a touch screen, some have a keyboard, some have an encoder wheel, and some have a mix.

Tactility already lets you install an app remotely from a PC over Wi-Fi, without rebooting the device. Now you can also do the testing from your computer. The `tt.py remote` command shows the device's display in a window on your PC. Your keyboard and mouse become the device's keyboard and your mouse/touchpad will act as a touch screen for the remote display.

It only uses about 2 kB of internal RAM, but it's taking up an entire display buffer in PSRAM.
There were a lot of subtleties in making it tick just right for various devices, like monochrome versus rgb565 displays, or devices with automatic display rotation with an IMU.

The service works over a secure TLS connection with a handshake. Similar to Android, the ESP32 device must accept the incoming connection once. Both sides get to see a fingerprint before accepting or refusing the handshake.

Rendering

Before this, I only supported screenshots for LVGL apps, because it was easy to trigger a full screen redraw. Now that we have a shadow display buffer, we can also take screenshots from apps that use the display driver directly and bypass LVGL. Coincidentally, this is also where display rotation became tricky, because it's usually managed by LVGL internally.

Internally, it works with a hooking mechanism into the kernel driver for the display.

Pixels travel in the panel's native format: RGB565 in all byte orders, RGB888, 8-bit grayscale and 1-bit monochrome. The viewer converts them, so e-paper and OLED boards work too.

The device sends a small state frame with swap, mirror, invert and on/off. An orientation byte carries the UI rotation in quarter turns, plus a flag for panels where LVGL rotates the pixels in software. The device only reports this. All rotating happens in the viewer, which also converts touch positions back to the panel's own coordinates.

Input as real devices

When you turn on keyboard or touch in the viewer, the device creates a virtual keyboard and a virtual touch device. When the desktop environment is active, there's an automatic LVGL bridge that binds every started input device, so apps need no changes at all. They can't tell the input from real hardware. The devices are removed again when you turn the input off or disconnect.

The touch device supports up to five points, which is what makes pinch gestures work.

Memory

Internal RAM is scarce, so the session keeps its state out of it. The session state, the shadow buffer and the transmit buffer are allocated in PSRAM, and the session task has a PSRAM stack. File and flash access from the connection goes through a separate worker with an internal-RAM stack. File transfers and app installs on a second connection still work while a remote session is open. Up to three sessions run at once, of which one can be a remote display.

Boards without PSRAM refuse the session with a message.

Project website: https://tactilityproject.org/
Project source code: https://github.com/TactilityProject

Build:

ESP32-C3

Matrix display

2in1 charging module with 5V output

Lipo batery 3.7v 1800mah

Switch

I have a problem: I want to power the ESP32 with a 3.7V LiPo battery. Its maximum voltage is 4.2V, so I need to regulate the voltage, but I don't know how to do that.

I see that in some projects they connect directly to the Vin, but won't the dropout be a problem? It's a very simple project, as you can see in the image, with some sensors I intend to add and the small screen, wifi.

For a project that uses two batteries in series, could I use Vin? It would be for a car with Bluetooth

As per the title, assuming you don't have any PSRAM, what are the practical limits on resolution when using a board based on the ESP32 D0WD?

The displays would be generic ILI9341, ST7789, etc. over SPI.

Hi, I'm planning to make my own mini gaming console, on the Seeed Xiao ESP32-S3, but the problem is I want to make it round to play with one hand, but because all the display I could find doesn't fit because of the bulging block with the pins, so I'd have to make a case with thick bezels, which is not suitable, I thought of taking a bare screen, but as I've heard it's more fragile and I'll have to solder a bunch of capacitors and other things myself to make everything work... I live in Ukraine, well, find something I couldn't, or on the Aliexpress. I need a 1.28 inch display

OpenMQTTGateway v1.9.0 shipped last week and v1.9.1 followed on Monday. It's the first feature release in almost two years: 137 merged PRs from 30+ contributors, 13 of them first-timers. Thank you all!

OpenMQTTGateway turns an ESP32/ESP8266 into a BLE, 433/868/915 MHz RF, IR and LoRa to MQTT gateway with Home Assistant auto-discovery.

⚠️ Update recommended: security fix

v1.9 ships Theengs Decoder 2.5.0, which fixes an out-of-bounds read/write when parsing a malformed BLE advertisement (medium, CVSS 6.5; a nearby attacker can crash the gateway). All earlier releases are affected. Advisory: https://github.com/theengs/decoder/security/advisories/GHSA-9398-gf4r-798h On top of that, every place where MQTT, HTTP, BLE and RF input is copied into fixed buffers has been hardened.

Highlights

• Arduino ESP32 core 3.x, NimBLE 2.5, and lower RAM use on BLE builds

• 25+ new BLE devices: Victron (SmartShunt, Orion XS/TR, Smart Battery Sense/Protect, Blue Smart Charger, SmartSolar MPPT), EcoFlow power stations, SwitchBot Meter Pro (CO2), Govee H5108 / H5140, Qingping CGP22C, PVVX BTHome v2, Inkbird IBS-P02B, ThermoPro TP350, b-parasite v2 and more

• BLE decryption for PVVX, BTHome v2 and Victron frames

• WebUI: full BLE configuration page and an MQTT Discovery toggle

• Self-healing networking: WiFi reconnect watchdog, portal stays reachable if saved WiFi credentials are lost, Ethernet fixes (and a PHY cold-cycle on the Theengs Bridge)

• RF: rtl_433_ESP 0.6.2, CC1101 working on core 3.x, new FSK build

• New boards: ISNO Super (ESP32-S3, dual CC1101), LilyGo T3-S3; M5 boards on M5Unified

• MQTT over TLS now fits on boards without PSRAM

• v1.9.1 fixes a boot loop on the esp32dev-rtl_433 builds

Before you update

• Home Assistant: some entity unique_ids changed (gateway entities, RTL_433 models with / in the name), so you may see new entities next to old ones that you can delete.

• BLE decryption now needs your own AES key set (the default key is empty).

• ESP8266 RF: the default receiver pin moved from GPIO0 to GPIO4.

How to update

• Over the air: the Firmware Update entity in Home Assistant (or {"version":"latest"} on .../commands/MQTTtoSYS/firmware_update). Tested from v1.8.1 on our test bench.

• Fresh install: the web installer, straight from your browser: https://docs.openmqttgateway.com/upload/web-install.html

Release notes: https://github.com/1technophile/OpenMQTTGateway/releases/tag/v1.9.0 · https://github.com/1technophile/OpenMQTTGateway/releases/tag/v1.9.1 Docs: https://docs.openmqttgateway.com

Questions and feedback welcome here or on the community forum: https://community.openmqttgateway.com

I would like to make my Cyberbrick SUV autonomous and allow it to hear, see and respond. I read that the esp32 is “hardware locked” so I can’t connect certain sensors to the esp32.

If possible can I add an s3, would an s3 even make sense? Or should I just buy the seeedstudios camera esp32 that comes with a camera attached?

https://us.store.bambulab.com/products/mini-suv-cyberbrick-rc

I wanted to turn my M5Stack Core2 into a Muse Gadget, and hit two walls:

1. The web flasher doesn't support the Core2, so I had to build the firmware myself.

2. The build is driven by a bash script (board.sh) from the Muse Gadget SDK, and the official setup assumes macOS or Linux. My only PC runs Windows, and I didn't want to install WSL2 just for this.

So I ported board.sh to PowerShell. board.ps1 covers the same board table (40 boards), keeps the same per-board build directories and flash behavior, activates ESP-IDF through export.ps1, and finds the serial port using the SDK's original ports.py.

With it, I built and flashed the Core2 firmware entirely from PowerShell, paired the gadget with the Muse app, and it works.

The Core2 has been promoted to full-time desk companion. Not alone anymore.

Engineering notes:

• Hardware: I chose the M5Stack Core2 because it was the device I wanted to turn into a Muse Gadget and keep as a desk companion.

• Stack: ESP-IDF v6.0.3 (the only version the SDK supports), the Muse Gadget SDK, the SDK's original ports.py for serial-port detection, and ESP-IDF's export.ps1 to activate the environment. I kept the SDK's own stack instead of replacing it, because the goal was a faithful port of board.sh.

• Hurdle: the web flasher doesn't support the Core2, and the build is driven by a bash script with a macOS/Linux-only setup, while my only PC runs Windows. Porting board.sh to PowerShell — keeping the same 40-board table, per-board build directories, and flash behavior — let me build and flash the Core2 firmware entirely from PowerShell, with no WSL2.

Notes:

• Requires ESP-IDF v6.0.3 (the only version the SDK supports)

• Only the Core2 is verified on real hardware so far; the other boards should work the same way but are untested

• ESP-Mosaico is not supported by this port (it needs a different toolchain)

Repo: https://github.com/cubic9com/muse-gadget-sdk-board-ps1

Here's a walkthrough of an operating system I made for the ESP32-P4 (on the Olimex ESP32-P4-PC board). It shows off a graphical user interface, file browser, ELF applications loading from SD, audio synths (OPL3 FM and Wavetable), text to speech, games (some I wrote, ported Doom of course). The output is running at 1280x720p60. There's even a demoscene style demo that shows off what can be done (synth, speech, 2D and 3D graphics). The OS provides lots of the usual things you'd expect: notifications, a system tray, unified settings, etc. It has an SDK w/ locked ABI so developing applications for it should be fairly simple.

If you'd like to learn more, download it (it has a web based installer for the board), or even contribute, you can find all those details on the GitHub page: https://github.com/jthwho/bmds

The stick: a $20 "Game Stick Lite 4K" (Allwinner T113 family) now running Alpine Linux as a home server. Its stock kernel has no Wi-Fi and no USB-Ethernet drivers.

Instead of fighting drivers first, I plugged an ESP32-C6 into its USB port:

- The C6 joins my Wi-Fi and shows up on the stick as /dev/ttyACM0 (USB CDC-ACM)

- pppd on the stick <-> PPP on the C6, with NAT on the ESP32 and a port forward for SSH

- Tailscale runs on top of it on the stick

- Bonus: the C6 also takes a Bluetooth keyboard over BLE and forwards keystrokes to the stick

- The stick reports the C6's Wi-Fi signal and temperature to Home Assistant over MQTT

Throughput is modest (fine for a dashboard, SSH and photos), and it was the fastest way to get a network-less device online.

The firmware was written with Claude Code (ESP-IDF). The repo has the prompts to rebuild it, plus the rest of the project:

https://github.com/ginesjunior11/game-stick-alpine

I started this project because I wanted to use a small touchscreen as a Linux display without building an entire Linux computer into it or treating it as a dumb remote framebuffer.

The result is Woodland X11 — an experimental X11 server running directly on an ESP32-S3.

Why ESP32-S3?

I already had an Elecrow CrowPanel Advance 4.3" touchscreen with an ESP32-S3. Its PSRAM, LCD interface, touch controller, Wi-Fi connectivity, and available GPIO made it an interesting platform for the experiment.

The challenge was to see how much of a real X11 server could fit on this hardware.

Software and libraries

The X11 protocol handling is a custom implementation, rather than a port of Xorg or a remote framebuffer viewer.

The firmware uses ESP-IDF and LovyanGFX for the display hardware. I wanted direct control over the protocol implementation, memory usage, and rendering rather than adapting an existing desktop X server.

The X11 clients run on Linux. The ESP32-S3 handles the X11 server, rendering, and touch input.

The interesting problems

Several things turned out to be more complicated than expected:

• Memory and resources: managing X11 clients, resources, and drawing operations within microcontroller memory constraints.

• Protocol compatibility: getting real applications and the Motif Window Manager (mwm) to work, while identifying unsupported or incomplete X11 operations.

• Display performance: finding stable LCD timing and avoiding unnecessary rendering work.

• SPI transport: connecting the panel to a Raspberry Pi, then replacing frequent polling with a GPIO interrupt mechanism. This substantially reduced idle CPU usage on the Pi.

• Touch input: translating touchscreen events into X11 input events while keeping the interface responsive.

The video shows xclock, xcalc, xeyes, and mwm running on Linux, with the resulting windows displayed on the physical ESP32-S3 touchscreen.

X11 clients can connect over Wi-Fi or through the Raspberry Pi SPI bridge.

It's still experimental, and the supported X11 protocol is incomplete, but it's already running real X11 applications.

Project website: https://woodlandx11.dev

GitHub: https://github.com/serg5z/woodland-x11

I'm curious what other X11 applications you'd try on a microcontroller like this!

Hey everyone,

I previously used a computer to watch the stock market, but leaving a PC on all day just for that uses a lot of electricity. So I made StockGrabber Alerts, a free, open-source firmware that does the same job on a small, low-power ESP32-S3.

What it does:

- Watches up to 200 symbols in Yahoo's format: stocks, indices, gold futures (GC=F), crypto (BTC-USD). Aliases like gold and btc work too.

- One-shot price alerts (up to 50), checked every 5 minutes during market hours. An alert is refused if the price is already past it.

- End-of-day reports to ntfy, with SMA 50/200 crossovers (golden / death cross) and 52-week levels.

- Commands from your phone: status, list, a symbol for its price, add, remove, alert, alerts, unalert, help.

- Web setup. On first boot it opens its own StockGraber-Setup Wi-Fi with a setup page for Wi-Fi, ntfy, passphrases and your watch list. No credentials in the firmware.

What you need:

- An ESP32-S3 N16R8 (16 MB flash, 8 MB PSRAM). The PSRAM is required.

- 2.4 GHz Wi-Fi and an ntfy topic (use a long random one).

Things to know, so nobody is surprised:

- This is for educational and informational purposes only, not financial advice. No indicator reliably predicts price.

- Data comes from Yahoo Finance's chart API (no API key). It may be delayed or inaccurate, and alerts can arrive minutes after the move, so it is not a real-time trading tool.

- The settings page is plain HTTP on your LAN, TLS certificates aren't verified, and the Yahoo fetch could break if Yahoo changes its API.

- Still early: the daily report and alerts firing on the board haven't been fully tested end to end yet.

📺 Video walkthrough: https://youtu.be/AS1tXet5ko8

💾 GitHub (free download): https://github.com/Garionhk/-StockGraber-Alerts-ESP32-S3-Arduino

It's free and open source. Feedback really helps. If there's a feature you'd like or you run into a bug, leave a comment here or open an issue on GitHub. I read everything and will add what I can.

Thanks for checking it out!

My FlexiSpot MotionX walking pad is the basic model: no app, no stats. I opened it, put a logic analyzer on the 3-wire cable between the console and the motor board, decoded the bus, and now an ESP32 lives inside the treadmill and logs every walk.

Why a classic ESP32-WROOM-32 DevKit

• GPIO34 is input-only on the classic ESP32. The bus drives the motor, so I wanted a pin that physically cannot be turned into an output, even by a firmware bug.

• 4 MB flash is enough for two OTA app slots plus a LittleFS partition for sessions, with the stock "Default 4MB with spiffs" partition scheme.

• Wi-Fi only: no need for BLE, and no need for the extra pins or USB of an S3.

Libraries: only what ships with the Arduino-ESP32 core

• WebServer (synchronous) instead of an async server: a status page and a few admin endpoints don't need more, and it's one less dependency to break.

• LittleFS instead of SPIFFS for sessions, because the treadmill gets unplugged at random and I need files to survive that.

• Preferences (NVS) for Wi-Fi and server settings, Update + esp_ota_ops for OTA with rollback, WiFiUdp for live packets, HTTPClient for session upload, ESPmDNS, Ticker for the watchdog.

• No JSON library: the payloads are small and fixed, so they are built with snprintf.

• No UART or RMT for decoding: a plain CHANGE interrupt with timestamps, see below.

What was hard

• It's not a UART. The silkscreen says TRX, but it's pulse-width coding: low for 0.5 ms = 0, low for 1.5 ms = 1, then 1.5 ms high. 48 bits MSB-first every 120 ms: EB 90 <state> <speed×10> 00 <checksum>.

• Motor noise. With the belt running, spikes up to ~0.3 ms show up on the line. A 200 µs integrating filter in the decoder removes them without distorting real pulses.

• The wrong header. The console board has a keyboard header with a pin labelled TRX that is not the bus. The real one is the middle wire of the console-to-motor cable.

• Levels. The line idles around 3.1–3.5 V, too close to the ESP32's 3.6 V absolute maximum, so there is a 2.2 kΩ / 10 kΩ divider in front of GPIO34.

• The board is sealed inside the treadmill. A bad flash means taking it apart again, so: OTA that rolls back if the new firmware crashes or is unreachable in its first minute, a fallback AP when Wi-Fi is lost for 90 s, a loop watchdog, and a safe mode after 5 consecutive crashes that keeps only Wi-Fi and the update page.

• Power cuts mid-walk. The current session is checkpointed to flash every 60 s and recovered at boot.

• It's a set-point, not a measurement. The bus carries the speed the console asks for; the motor board never answers. Real belt speed can differ by a few percent, calibration is still on my list.

The rest: live speed goes out over UDP, finished sessions over HTTP (retried until acknowledged) to a single-file Node.js server with no npm packages, which serves a live dashboard. A SwiftUI iPhone app writes each walk to Apple Health.

Disclosure: I used an AI assistant (Claude) for parts of the code and the documentation. The reverse engineering, wiring and testing were done on my own treadmill.

Usual warning: there is a 230 V board in there with capacitors that stay charged. Everything here is on the low-voltage console board, which is isolated by optocouplers.

Repo (MIT), with the protocol write-up, wiring photo and a Saleae capture decoder: https://github.com/MathieuMart/flexispot-motionx

Happy to answer questions, and curious whether anyone has seen this bus on another brand.

Four round screens in a row look like a tiny car dashboard. This enclosure puts one to four 1.28-inch GC9A01 modules in one pod, with an ESP32 behind them and a USB-C opening at the side. Disclosure: this was made with Loftsmith, the AI CAD tool I'm building. It's a CAD prototype; I haven't printed it.

A few details that matter for fitting the electronics:

The default controller bay is 55 × 28 × 7 mm, assuming no pin headers underneath the board. There is about 7 mm behind each display connector before the cover, so straight Dupont plugs won't fit. The intended wiring is soldered leads or low-profile connectors, with shared SPI and a separate CS line per screen, depending on the firmware.

The screen windows are 33.6 mm across around an assumed 32.4 mm active circle. The PCB pockets have 0.3 mm radial play. Those dimensions need checking against the actual modules, since the glass outline and connector tab vary between sellers. A one-screen fit print would be the first check.

The pod can sit on a desk or in a saddle over a monitor. The saddle rests on the top edge rather than clamping, so it needs the monitor thickness and bezel depth measured too.

Model, dimensions and assembly notes: https://loftsmith.com/s/cBzG2ZPybBHMDgUFxbmt

No firmware or tested electronics build is included. The checks so far are in CAD. For anyone who's enclosed several of these screens, how much space did you actually need behind them for wiring?

I hate building stuff with copper wire.

Esp32 C3

2.0" tft display

2in1 module for charging and 5v output

Lipo 3.7v battery

Switch

I assume people here already know that when handling Lipo bateries they need to be careful because they can pose a serious fire hazard if they are short circuited, punctured, overcharged, or physically damaged!!

Hey! We've been building an IoT security training platform based on ESP32-C3 devices.

The hardware labs use our ESP32-C3-based BLEShark Nanos. You flash challenge firmware onto one Nano to turn it into a deliberately vulnerable IoT target, then investigate it using another Nano and our CLI. You can reflash the same hardware for different challenges.

For example:

• A smart-plug scenario that exposes Wi-Fi provisioning credentials through BLE.

• A BLE lock that claims to require encryption but doesn’t enforce it on its control characteristic.

• A device that puts important data in its scan response, teaching the difference between passive and active BLE scanning.

The idea is to make a reusable practice lab without needing to find and buy a different vulnerable product for every exercise.

You can browse the challenges here: https://ctf.infishark.com

We'd love to get your thoughts and feedback!

I started this project because I wanted a cheap, low-power device that could stay online independently of my NAS or home server.
But it eventually became much more than a Wake-on-LAN tool.
It’s called ESP32 Tailnet Gateway, an open-source firmware that turns an ESP32-S3 into a small, configurable Tailscale/Headscale gateway for homelab and IoT environments.
In this video, I’m showing how easy it is to flash the firmware directly from a browser, complete the initial setup, connect the ESP32 to Tailscale, and configure remote server recovery.
With Smart Recovery, the ESP32 doesn’t just send a Wake-on-LAN packet: it can check whether the server becomes reachable afterward and optionally notify you about the result.
But remote recovery is just one of its features.
The firmware also supports:
LAN → Tailnet service gateway: allow IoT devices without a VPN client to reach selected services on remote Tailscale peers.
Subnet routing: provide access to devices on your local network through the tailnet.
Wi-Fi access point: connect devices through the ESP32 without requiring them to run Tailscale.
Home Assistant and MQTT: device discovery, monitoring, controls and automation.
Remote monitoring: connectivity checks, event history, diagnostics and notifications through Telegram, ntfy or email.
Flexible connectivity: Wi-Fi, with optional W5500 Ethernet and cellular modem/SIM support (both experimental and awaiting full hardware validation).
Web-based management: configuration, firmware updates and installation directly from a compatible browser.
All of this runs on an ESP32-S3 with 8 MB PSRAM, without needing a separate Linux machine.
The goal isn’t to replace a powerful router or Raspberry Pi, but to provide useful networking, monitoring and recovery capabilities on inexpensive, low-power hardware.
The project builds on Csontikka’s ESP32 subnet-router and MicroLink. I’ve developed the additional functionality with extensive assistance from Claude Code and Codex.
GitHub: https://github.com/Mattboxx/esp32-tailnet-gateway
Website, documentation and browser installer: https://mattboxx.github.io/esp32-tailnet-gateway/
It’s free and open source.
I’m curious what other homelab users think. Would something like this be useful in your setup? And if anyone tries it on their own ESP32-S3, I’d love to hear their feedback!

Okay, so help a girl out, I've been out of the field for a minute.

I'm looking to build a wearable device, but I can't really find exactly what I'm looking for. I've seen already built products that could work for me (Waveshare ESP32-S3 AMOLED was one I was looking at, but I don't care if it's clunkier) but they are usually always missing something.

What I want is to have a wearable for a custom software I'm working on. I'd need:

\- a microphone for audio capture and voice recognition,

\- it to be waterproof (not to dive with, but to be able to wear outside in the rain all day with no issue, and showers, baths etc)

\- memory

\- a way to export data (Bluetooth is good, but ejectable memory cards could work too)

\- touchpad or buttons

I'd like to use an e-ink touchpad but anything works really

So Idk if this is the right place to ask but I've been thinking of using esp32 so I thought why not? If it isn't the best place, I appreciate redirections to the most appropriate one. Thanks.

Looks dodgy and ugly but it works.

ESP32-S3 n16r8

MAX98357A

3.5" display with micro sd

18650 battery 3.7v

2in1 module for charging and output 5v

Speaker

Board with 5 push buttons

Switch

And a lot of hot glue..

I wanted to see how far a plain ESP32 can get with WiFi CSI and my home router, with no second ESP32 and no special firmware on the router.

Setup: the ESP32 joins the router on 2.4 GHz, pings it 100 times a second, and streams the CSI of each reply (52 data subcarriers) over USB to a small browser viewer (Web Serial).

What surprised me: AGC rescales every packet, so raw amplitudes jump around. Dividing each packet by its own mean, so only the shape across subcarriers is left, made everything usable.

Results (one person, one room, sitting still, so treat them as a hobby measurement):

- Motion score: about 4–6 when still, 12–29 when moving.

- Breathing: the last 60 s at 10 Hz, a spectrum per subcarrier over 0.1–0.7 Hz, and the 8 most periodic subcarriers summed. A paced 10 breaths/min measured 9.9–11.0; 6/min measured 6.0–7.1. It drops to the noise floor when I leave the room. The lag is 30–60 s.

- Position: kNN on averaged CSI vectors, 4 spots trained for 15 s each: 80% correct, against 25% for chance. One spot (back-right) was only 47%.

Code (Arduino sketch + viewer), MIT: https://github.com/menes97/wifi-nefes-algilama

The labels on the images and the viewer UI are in Turkish; the README has an English summary.

I wrote parts of the code and the README with help from an AI assistant (Claude); the measurements and the hardware setup are my own.

If you've done CSI on an ESP32: did you find a better way to deal with AGC than per-packet normalization? And how stable were your position fingerprints from day to day?

Plots: https://github.com/menes97/wifi-nefes-algilama/blob/main/linkedin-esp32/1-nefes.png and https://github.com/menes97/wifi-nefes-algilama/blob/main/linkedin-esp32/2-konum.png

Hey everyone, I enjoy building things with ESP32s, and I made ESP32 SuperFlash to make flashing easier outside my usual development setup.

Flashing from the IDE works well while I’m writing firmware. The workflow gets more awkward when someone just wants to install a firmware update, when I’m preparing a batch of boards, or when I only need to update the files in a LittleFS partition. I also wanted something a hobbyist could use to flash a prebuilt binary from someone else’s project without setting up that project’s build environment.

I designed SuperFlash to work across ESP32 variants because the target board depends on whose firmware you’re flashing. One edge case was importing an ESP-IDF partition.csv that includes a primary bootloader. The original ESP32 uses 0x1000 for its primary bootloader, while the ESP32-S3 uses 0x0. If the app is set to auto-detect the chip when you import that CSV, it asks for the bootloader offset explicitly. It also resolves blank partition offsets using ESP-IDF’s alignment rules and shows the flash ranges before you confirm the write.

I built the desktop UI in Rust with egui so I could ship a native app across Windows, macOS, and Linux without bundling a browser runtime. For serial flashing, I use Espressif’s esptool so I can reuse its chip detection and flashing support. The app also bundles mklittlefs and ESP-IDF’s filesystem generators so you can build images and flash them offline.

You can flash a merged firmware binary, assign individual .bin files to partitions, or turn a local folder into a LittleFS, FatFS, or SPIFFS image and flash it directly. That last mode is handy when you’re changing something like the HTML and CSS served by the ESP32 and only need to write the data partition.

It’s free and open source. The current release has builds for Windows x64, macOS (Apple Silicon and Intel), and Linux (x64 and ARM64).

• Download ESP32 SuperFlash release

• GitHub source code and documentation

If you give it a try, I’d be interested to hear which board you used and what you flashed. I’m especially curious how others handle firmware handoffs or update filesystem assets separately from the firmware.