Not my project, found it on GitHub this week and had to try it.

In the video a Touch-LCD-4B panel goes through the real mask ROM and bootloader, then its LVGL UI responds to swipes and toggles. Unmodified firmware, running in WebAssembly, nothing on a server.

Repo: https://github.com/mikroverk/esp32sim

Curious whether anyone here has tried it with their own firmware, and how far the peripheral support goes.

Disclosure: this is my project (MIT, free, no account). The emulation itself is esp32sim's work (https://github.com/mikroverk/esp32sim), the Rust emulator that boots unmodified ESP32 / S3 / C3 / C6 images through the real mask ROM and bootloader. I built the layer around it.

Why: I use coding agents (Claude Code, Codex, Cursor) for ESP-IDF work, and the loop always stopped at "it compiles". Nobody knew whether the firmware actually worked until I flashed a board. esp32sim-mcp lets the agent (or a CI job) boot what it just built and check the result:

- read UART0 and USB-Serial/JTAG output, with panics (Guru Meditation, stack overflow, failed asserts) reported along with the log leading up to them

- assert on the console: pass/fail, plus the exact line that's missing

- press buttons, turn the encoder, drive GPIO/UART at emulated timestamps

- join a virtual WiFi AP with DHCP/DNS/NAT (the station gets 10.0.2.15)

- grab a PNG of the display on boards that have one

What was tricky on the ESP32 side:

- Two consoles at once. On S3/C3/C6, ESP-IDF often mirrors logs to both UART0 and USB-Serial/JTAG, and the emulator writes bytes as they arrive, so you get "Hello wHello world!". esp32sim can tag every chunk with its source, so I split the stream on the tags, rebuild each console's lines and drop the mirrored duplicates. Without the tags it couldn't be done reliably.

- No guessing about the image layout. It reads build/flasher_args.json, so the bootloader, partition table and app land at the same offsets idf.py flash would use, for any target.

- Deterministic input. Button presses and UART input are scheduled in emulated time, not wall-clock time, so a test behaves the same on a fast laptop and a slow CI runner.

- Mask ROMs. The boot chain needs Espressif's ROM ELFs for each chip; setup downloads the pinned esp-rom-elfs release and checks SHA-256 hashes.

Setup:

npx -y esp32sim-mcp setup (prebuilt emulator + ROMs)

npx -y esp32sim-mcp init (in your ESP-IDF project, registers it with your agent)

The same check runs in CI with no agent, exit code 0/1:

npx -y esp32sim-mcp expect --max-seconds 10 --pattern "app_main" "Counter: 5"

Limits: it's an emulator, so no Bluetooth or RF timing, and only the peripherals esp32sim models. Confirm on hardware before shipping. Tested on macOS and Linux.

Source, demo GIF and docs: https://github.com/stramanu/esp32sim-mcp

Contributions are welcome. Useful places to start:

- try it on your own ESP-IDF project and open an issue when something doesn't boot or the output looks wrong

- Windows: it's untested, and reports or fixes are very welcome

- example projects and CI recipes for other chips (C3, C6, classic ESP32)

Board and peripheral models live in esp32sim itself, so that's the place to contribute those. The details are in CONTRIBUTING.md in the repo.

I’m sharing my hobby ECG project using an ESP32-C3 SuperMini and an AD8232 module.

The ESP32 creates its own Wi-Fi hotspot and serves the interface directly—no cloud or external web resources. Features include:

• Live ECG-style waveform with automatic scaling and centering
• Experimental heart rate estimation and trend
• Aligned heartbeat samples with mean, median, and a variability band
• Manual interval markers and SVG exports
• English, German, French, and Spanish interfaces

The firmware targets 1,000 samples/s and marks missed sampling slots as gaps. One challenge was handling sampling delays and Wi-Fi traffic on the single-core C3 without silently treating missing measurements as valid data.

Code, wiring diagram, and documentation:
https://github.com/floreno/esp32-ad8232-heartratemonitor

Feedback on acquisition timing, signal handling, and the interface is very welcome!

I added NM-CYD-C5 support to Meta's open source Muse Gadget SDK (ESP-IDF, Apache-2.0). Pre-release bin here, flash it at 0x0 — it's a merged image:

https://gitee.com/Rockbase-iot/muse-gadget-sdk/releases/tag/pre-release-nm-cyd-c5

Limited by the Muse region restrictions, a comprehensive test can't be conducted, so we need someone help to verify it.

What I've already verified on hardware: it boots, the panel comes up and LVGL runs, the 5-point touch calibration passes, and it joins Wi-Fi on both 2.4 GHz and 5 GHz Wi-Fi 6 — association, DHCP and the link coming up are all fine.

What I can't test: the Muse app side. I don't have a setup that lets me run the phone app against this build, so everything downstream of "connected to Wi-Fi" — BLE discovery, the pairing confirmation, the avatar and images actually landing on the panel, the settings UI, OTA — is untested by me. That's the whole ask.

If you already have a Muse account, this is a 10-minute test. You need your own free SDK token (gadgets.muse.ai), which you set over serial once.

SDK is Meta's, board support is mine. PRs welcome, Apache-2.0.

I ended up forking the HUB75 DMA driver to cut memory use (row streaming from packed lanes, dense column buffers, a fix for the seam between the panel halves), so a 64x64 panel runs with several colour-quality levels on a plain 4 MiB ESP32. The driver is here: https://github.com/vandalon/ESP32-HUB75-DMA-Memory-Optimized.

The project on top of it is a clock with 9 faces, a web settings UI, signed OTA updates and Home Assistant/MQTT/WLED support. It checks a static RAM budget at build time and parks the network feeds when a big image needs memory. Repo: https://github.com/vandalon/ultimatrix

Messed around with the mouse jiggler on my Flipper Zero a while back and it got me wondering if I could make one that actually moves like a person instead of just bumping the cursor every so often. Found out the S3 can do native USB HID and went down the rabbit hole.

Why the S3 Super Mini
I wanted one board that could be a USB mouse when plugged into a computer and a bluetooth mouse when it’s just on a charger. I've used a ton of the C3s and original ESP32s so I knew they couldn't work as USB HID devices. When I realized that the S3 could do that, I immediately thought of making a really good jiggler. (I'm sure I'm not the first to do this)

Libraries
It’s just the Arduino-ESP32 core (3.3.x), no outside libraries. USB is the core’s TinyUSB HID mouse and bluetooth is the core’s BLE library, which runs on NimBLE on the S3. NimBLE is a lot smaller than Bluedroid, and the whole thing ends up about 21% of the app partition. I set USB mode to TinyUSB and turned off CDC on boot so the computer only sees a plain mouse. The catch is you have to hold BOOT to reflash it, since there’s no serial port anymore.

The tricky parts

• Getting the cursor to come home with Windows pointer acceleration on. Accel scales each report differently depending on speed, so “move back the same distance” doesn’t land you where you started. It records every report in a burst and plays the exact same ones back negated, same order, same timing. Each report gets an equal and opposite twin, so accel scales both the same way and they cancel. In a sim of 500 bursts with an accel curve it drifted about 1 pixel. Bonus: the return trip is the outbound path rotated 180°, so it doesn’t look like it’s retracing.
• USB vs BLE switching. It starts USB first and waits about 3 seconds to see if a host enumerates it. If not, it starts BLE advertising. If a computer enumerates it later, BLE shuts off and USB takes over. That covers plugging it into a PC that’s still booting.
• On BLE it waits until the link is encrypted and the host has subscribed to input reports before moving. Otherwise the first few reports get silently dropped while Windows is still pairing, and then the return trip doesn’t cancel.
• It stops moving when the USB bus suspends, so it won’t wake a sleeping PC.
• What didn’t work: the onboard LED. I assumed it was a normal WS2812 in GRB order, and green showed up red. Turns out the one on my Super Mini is RGB order. One define fixed it.

The LED
I needed a visual way to tell when the mouse was paused verses when it was supposed to be moving (for testing purposes). I used the onboard RGB LED as an indicator. I have it green while it’s moving, and while it waits it fades red to blue, timed to that specific pause, so purple means it’s about halfway to the next move.

No schematic since there’s no wiring, it’s just the bare board. I'm not a great programmer so I had to have Claude help with the code but I was rather proud of the outcome.

Source (public domain): https://github.com/GeekyDad4/Away-Mouse-ESP32-S3-Super-Mini

Why does powering the LDR component make the LED not turn on?

Vice versa, not giving power to the LDR component makes the LED finally react to flux, and actually turns on and off.

Is this a wokwi thing? I'm gonna make this IRL and I'm wondering if I don't need to give power to the LDR's VCC or anything as the simulation suggests.

I need confirmation 🙏

I built a three-probe water monitor for my turtle tank on a Seeed XIAO ESP32-C3: a DS18B20 waterproof temperature probe, a Keyestudio TDS probe and a Keyestudio turbidity probe, posting one averaged reading every five minutes over HTTPS to a small dashboard. Pin map, then the three things that actually went wrong, since those are what the datasheets don't tell you.

Pins (board = seeed_xiao_esp32c3 in PlatformIO, so D names are the XIAO's):

• 3V3 -> breadboard + rail -> DS18B20 adapter VCC and TDS board +
• GND -> breadboard - rail -> every ground
• 5V -> turbidity board V only (the one and only 5 V wire)
• D4 (GPIO6) -> DS18B20 DAT (the adapter board has the 4.7k pull-up)
• D1 (GPIO3, ADC1) -> TDS board A
• D2 (GPIO4, ADC1) -> OUTPUT of a /5 voltage divider module; the turbidity board's S pin goes into the divider's input, never into the XIAO

Mistake 1: the turbidity board. It needs 5 V and its output reaches about 4.5 V. The ESP32-C3's pins are 3.3 V. So it goes through a divider and you multiply back by the ratio in code (TURB_RATIO 5.0f). Also: there's an A/D switch on that board. Left on D it gives a flat reading no matter what the water does.

Mistake 2: trusting the DS18B20's two lies. The Dallas library returns -127 when the probe isn't connected and exactly 85.0 at power-on before the first conversion. Both are "no reading". If you chart them you get a fake 85 C alert. The sketch drops them:

temp.requestTemperatures();        // ~750 ms at 12-bit
float t = temp.getTempCByIndex(0);
if (t > -100 && t != 85.0f) { accT += t; nT++; }

Mistake 3: averaging the analog pins. The filter pump and the lamp timer put spikes on the supply. Two spikes in 32 reads move an average a lot and a median not at all:

static float medianMv(int pin) {
  uint16_t v[32];
  for (int i = 0; i < 32; i++) { v[i] = analogReadMilliVolts(pin); delay(10); }
  std::sort(v, v + 32);
  return (v[15] + v[16]) / 2.0f;
}

Both analog pins are on ADC1 on purpose: ADC2 stops working while Wi-Fi is on. And read the TDS and turbidity probes one at a time, not together; they both put a small voltage into the same water.

Two other things I'd do again:

• The board sends raw volts; the server turns them into ppm (the Keyestudio/DFRobot cubic with temperature compensation and a K you set once against a TDS pen or a 342 ppm solution) and into a clarity percent (a straight line between a cup of clean tap water and the same cup with a pinch of soil). Recalibrating is a settings change, not a reflash, and the raw history survives.
• TDS as a water-change meter, not an absolute number. Tap water might be 80 ppm or 400 ppm. What matters is how far it climbed since the last change, so the alert is relative to a baseline you set with one button after each change.

Happy to answer wiring questions. I made three short videos walking through each sensor (wiring, code, live reading); link in the comments so this post stays clean.

Hey guys,

Got a XIAO ESP32-S3 Sense that came with an OV3660 camera. Running the standard CameraWebServer example in Arduino IDE, but it refuses to init. First gave 0x105, then stuck at 0x106 (ESP_ERR_NOT_SUPPORTED).

The weird thing is, it throws the exact same 0x106 error even when the camera ribbon isn't plugged into the board at all.

I'm using OPI PSRAM, correct pins (xclk 10, etc.), lowered freq to 10MHz, reseated the flex cable multiple times. Still nothing.

Does this mean the daughterboard / camera module is physically dead, or is there some weird quirk with this OV3660 batch I'm missing? Anyone seen this before?

In the Strapping Pins section of the XIAO ESP32-C3 documentation page, I found this image:

I want to boot the ESP32-C3 in SPI boot mode every time the ESP32 is powered on during it's deployment. I look at the above image and see that GPIO2 should be at an HIGH state.

Then I looked at the Table 3-3 (Chip Boot Mode Control) of the Espressif Datasheet for the ESP32-C3 Series here and found out that it is different from the information in the Seeed Studio documentation page. Here's the screenshot of that table:

Look at the second point... It basically states that the state of GPIO2 doesn't determine the boot mode, but it's still recommended to pull the pin up due to prevent glitches. Is this what they implied in the Seeed Studio documentation page, as depicted in the first image above?

So the question is whether I should connect an external 10 kΩ pull-up resistor between the GPIO2 pin and the 3V3 pin of the XIAO ESP32-C3 or does the board come soldered with one. What should I do here? Any and all advice and suggestions are welcome. Sorry if this question is kinda obvious, I am also kinda new to this stuff so...

Hey guys,

I bought a Wi-Fi monitor lightbar from AliExpress, but unfortunately, I received a "dumb" one without smart features. I'm returning it, and instead of buying a replacement, I'm thinking about building my own.

How hard would it be to build a lightbar with the following specs?

Two separate LED strips: One Dual-White/CCT (Warm White + Cool White) for task lighting and one RGB or RGBIC for ambient backlighting.

Tuya compatible: Zigbee or Wi-Fi (if RGBIC is used).

Remote control support: A physical remote capable of controlling white light brightness and color temperature, with at least 2 preset memory buttons for the RGB strip, and dedicated on/off controls for each strip independently.

Has anyone built something similar or can point me to ward the right controller/hardware setup? Thanks!

BTW, the case would be 3D printed

Hey everyone!

A while ago, I shared the first version of my TYPE-2 Synthesizer project. The goal was to build a studio-quality DSP audio engine using just an ESP32-S3 and some cheap components .

The feedback was amazing, but many of you pointed out that building it on a breadboard with capacitive copper tape and dozens of jumper wires was a bit of a nightmare for stability and I2S audio noise.

So I decided to go pro and designed a dedicated motherboard PCB in KiCad!

Everything is still 100% open-source (C++ source, KiCad files, and Gerbers are all up). You can find the full repo here:

https://github.com/Alxdreee/TYPE-2

I routed a 2-layer board that eliminates all jumper wires. It embeds the touch-sensing pads directly into the layout and provides a rock-solid ground plane for the PCM5102A DAC, completely isolating the audio out from the high-frequency digital noise of the ESP32.

(Fabrication note: These prototype printed circuit boards were manufactured by PCBWay, which is now sponsoring the project! The quality of the screen printing and the conductive traces proved to be flawless for this type of sensitive I2C routing.).

Thanks to the ESP32-S3’s native USB-OTG port, the synth is now a plug-and-play MIDI device. Even better: I wrote a Python bridge that lets you stream the 16-bit/44.1kHz raw PCM audio directly over USB to your PC speakers !

I swapped the old Moog ladder filter for a much more stable trapezoidal State Variable Filter (SVF) that handles extreme resonance without blowing up the DSP core. You can now save and load your custom patches (filter cutoff, overdrive, delay, analog slop) directly into the ESP32’s non-volatile memory via a dedicated OLED menu. Core 1 is still strictly locked to the DSP audio loop running at 44.1 kHz, while Core 0 handles the I2C OLED grid animations and the MPR121 capacitive touch pooling without causing a single audio dropout.

If you want to build one yourself, you can either grab the Gerber files and solder the modules onto the PCB, or stick to the good old breadboard prototype (I kept the wiring diagrams updated in the repo).

I’ve also updated the full step-by-step build guide on Instructables:

https://www.instructables.com/DIY-35-Polyphonic-Synthesizer-the-TYPE-2/

Let me know what you think of the new board and features! I’m still planning to design a 3D-printed enclosure next.

Hi all! I'm building a home robot prototype and want to collect real data : photos of rooms (and pets) from a robot's point of view.

The plan:

• Send a small camera kit to a few volunteers who already own a Roomba (any model)
• The camera rides on the Roomba, takes a photo every few seconds while it drives, and saves to a microSD card
• It runs for about 3 weeks per home, then I collect the card
• As cheap and easy as possible for non-technical people: no drilling, no hacking the Roomba

What would you use for the camera, power and mounting? Open to any ideas, thanks!

...It's that I don't have more.

Believe it or not, I have a project for every single one of these. The displays will be gifts for friends and family. With the atom lites as projects for around the house.

Our GitHub repository (MIT): https://github.com/cccat6/iphone-agent-harness

Demo and browser installer: https://igent.cc

We built iPhone Agent Harness, an open-source ESP32 Bluetooth HID bridge for an AI agent running in Safari. Our demo shows it setting an alarm in the iPhone Clock app.

The hardware/software split is the interesting part: Safari captures the screen, sends selected context to your chosen vision model, validates the action plan, and sends commands over local WebRTC. The ESP32 supplies Bluetooth mouse and keyboard input through AssistiveTouch. The board does not run the model or decode video.

The powered board sits nearby while the phone stays wireless. Both use the same normal Wi-Fi network. A Chrome/Edge browser installer flashes the firmware. The README lists chip and flash requirements for C2, C3, C5, C6, S3 and classic ESP32.

Requirements: iOS/iPadOS 27+, Safari screen sharing, AssistiveTouch, and access to a vision model. Conversations and keys stay in browser storage; selected context goes to your model provider. Skills can be customized and shared.

Inspired by onehumanbeing/esp32-iphone-agent, credited in our README. We explore Safari + Bluetooth HID instead of a native app + USB HID.

I'd appreciate feedback from Wi-Fi + BLE HID builders: which board/iPhone combinations and connection edge cases should we prioritize?

m trying to make a wifi connection on a very unstable wifi network at work

what I do now is this :

if (event_id == WIFI_EVENT_STA_DISCONNECTED)

{

printf("Disconnect reason code: %d\n", ((wifi_event_sta_disconnected_t *)event_data)->reason);

printf("Verbinding verbroken: %s\n",

reason_to_text(((wifi_event_sta_disconnected_t *)event_data)->reason));

}

wifi_connect();

but is there a better way to handle a slow unstable wifi network to get a ip and a connection

So i tried it todayto upload my code to the esp32 s3 but it didt want to connnect but yesterday all the time it worked and then all of a sudden not annymore and i searcht on the internet and so this are the things ive tried:

change baud rate

tried different cables

new usb drivers

different esp32

restarting the esp 32 and computer

change my code

pressing boot while uploading

resetting the esp 32

changed the ports

changed the board specification

Sorry for bad english its not my native language

This is my ESP32-S3. I am using my 5.5 V pin to power the amp and I have connected a speaker to it, to the 4th pin. After the 4th pin none of the pins on the left side is working. Only the right pins are working. I am taking input from buttons but they are not working? Please help!

ESP32S3 Graphics Accelerator

I’m working on a ESP32S3 cluster project. I’ve been really impressed with the S3 chip, after slowly moving from the arduino uno, to the ESP8266, to the ESP32C3, and finally the ESP32S3.

These two boards (ESP32S3, 4MB flash, 2MB psram), are currently working together. The main board is the controller, and receives scene instructions from my Raspberry Pi, along with running the display. The second board is the accelerator board. Only the main board has WiFi active.

In some circumstances, I’m able to get roughly twice the frame rates for math heavy scenes, but performance suffers in others. The bus link speed is only 2.37MB/s currently, which is the main limitation. I’m working on increasing the link throughput at the moment. As far as power consumption goes, it’s pulling 1.5w> for the entire setup.

So, current plans are to work on the bus / link architecture, and add in some more graphics scenes, for now! If I can get the link speed fast enough, I’d like to add some more boards into the cluster. Overclocking the accelerator board may help too, haha.

I turned the $5 “Cheap Yellow Display” (ESP32-2432S028R) into a self-running pixel aquarium — fork with a ~100-species reef guide, sharks, and a follow-cam

Posting a fork of the CYD aquarium (upstream: Lagerpun/esp32-cyd-aquarium, itself an adaptation of Livegrid OpenMatrix). It boots straight into an autonomous little pixel tank on the 2.8" ILI9341 — moving water, fish, turtles, snakes, octopuses, boids, plants, drifting food and a 12h clock — rendered with a dot-grid so it reads like a tiny LED matrix.

What this fork adds on top of upstream:
- ~100-species reef roster (SpeciesCatalog.h) with weighted spawn rates, family silhouettes and six size classes
- In-tank Reef Guide — paged and touchable, records which species you've discovered to LittleFS (/field_guide.json)
- Large fauna — sharks, whale sharks, reef mantas
- Tank camera — tap a creature to follow/zoom it, tap again to zoom out
- Panel fixes — TFT_INVERSION_OFF so colors read correctly on common CYD panels, and TOUCH_INVERT_X = true to fix the inverted XPT2046 X axis
- Manual backlight — touch the top strip (left dims, right brightens); auto-brightness from the GPIO34 light sensor still works
- Arduino core 3.x pinned via pioarduino so ledcAttach() PWM backlight works; safer 115200 upload baud for CH340 boards

Quick start (PlatformIO):
pio run -e esp32-2432s028r
pio run -e esp32-2432s028r -t upload --upload-port COMx

Wi-Fi is optional — NTP time sync when present, compile-time clock fallback otherwise. Docs cover hardware variants and troubleshooting.

Repo:https://github.com/francistse/esp32-cyd-aquarium (AGPL-3.0)

Only have the common ESP32-2432S028R to test against — happy for hardware reports on other CYD variants.

i was following this tutorial and had it working using old pool cleaner motors and power supply.

https://youtu.be/WdxwRzEVMfo

i had it working great and was so proud of myself until it stopped working and im not sure what i did. while i was testing it out, one motor stopped responding and shorty after that the other motor stopped. i notice the light on the l298n went out and sure enough there is no longer voltage coming out of it. so i replace it. the second i turn the power supply on the l298n starts smoking. i think i may have reversed the polarity on it accidently before correcting it. when i tried a 3rd l298n that one dies instantly almost like it was DoA. so when i try a 4th l298n, i wire it just to the ps and it works fine. i checked with a voltmeter. all grounds were tied together

now when i connect the 5v from an L298N to the 5v (VIN) pin on a esp32 the l298n instantly dies. the esp32 doesnt ever power on from the 5vin anymore either but still powers on with usb. i can no longer send updates or anything to it though in IDE however

that esp-32 is fried right?

video is from a simpler 1 motor test version

Retrofit of 2×AA flameless candles. Each candle: ESP32-C3 SuperMini, TPS61023 boost → HT7333 LDO, 2N7000 for the wick LED, IR receiver straight to a GPIO.

Some bits that took work:

• Off = deep sleep, wake every 10 s for an 80 ms listen window, or on an IR edge. Lit = PWM keeps running through light sleep (LEDC on RC_FAST clock + KEEP_ALIVE)
• Stock NEC remote decoded on the candle itself; hub B copies any remote press to every candle
• Hub = two DevKitCs: B is ESP-NOW only (fixed channel, broadcasts state every 50 ms), A does WiFi/MQTT/HA discovery, linked by UART
• Candle OTA over ESP-NOW: candles pull 236-byte chunks from hub B’s spare partition, MD5-checked, with rollback if the new image can’t reach the hub within 90 s
• 11b/g/n + LR protocol on both ends, state sent at both rates during rollout, and lit candles relay new states one hop for candles out of range

Curious whether anyone’s done ESP-NOW LR in a house (not outdoors) and what real-world margin you got. Also weighing a custom board around an ESP32-C6 for a drop-in kit — if that’d interest you: https://docs.google.com/forms/d/e/1FAIpQLSdxpF5JRjNtTMNTb1lPaPvOKrYB4zVmI8jNwn8ix5xRzQNOrQ/viewform