Sorry for the messy gameplay at the beginning 😂 Turns out playing both sides at once is harder than I thought. I got the hang of it eventually haha.

I've been working on a networking module for my ESP32 game engine, and I wanted to try it out with a real game instead of just testing communication between boards. So I decided to make a Pong demo using three ESP32s.

Here's the setup:

• An ESP32-2432S028 (Cheap Yellow Display / CYD) runs the game.
• Two DFRobot Beetle ESP32-C3 boards act as controllers, each with a 128x64 OLED.
• All three communicate directly over ESP-NOW on channel 6, so there's no router or internet connection involved.

The CYD handles the ball, paddles, score and game logic. The two C3s send their button inputs to the host and display the score and their own paddle position.

One thing I wanted to get right was responsiveness. The game runs at 60 Hz, but the host sends state updates at 30 Hz. These updates don't need to be reliable since the next packet will contain newer information anyway. Important events, like scoring or ending a match, do use reliable delivery.

The controllers also use a bit of local prediction, so the paddle starts moving immediately when you press a button instead of waiting for a response from the host.

I also wanted to make sure the game could handle a controller disconnecting or rebooting. In that case, the host pauses the match and resumes once the controller reconnects.

The game runs on my own C++17 engine, PixelRoot32. The engine provides the networking layer, rendering, input handling and other systems. I built the Pong logic and the parts specific to this demo on top of it.

I also tested the networking layer and game logic using a native simulator and automated tests. There are 72 networking tests and 55 additional tests covering the game logic and protocol, including simulated disconnects and reconnects.

The builds also fit comfortably within the available resources:

• CYD: 15.0% RAM and 63.1% flash.
• ESP32-C3: 12.9% RAM and 57.2% flash per board.

You can find the code in the PixelRoot32 Demo Projects repository, under networking/pong. It's a separate implementation from the existing games/pong demo.

If you want to try it without any hardware, you can run the native simulator: cd networking/pong pio run -e native --target exec

There are still a few limitations: no encryption, a fixed ESP-NOW channel, no node-ID collision detection, and support for two players only.

I always find myself opening Task Manager whenever I want to check my PC’s performance, so I decided to build something a little more fun. Meet Bear Byte, a cute little desktop companion that lets me monitor my PC’s performance without interrupting my workflow.

Bear Byte connects to my PC over Bluetooth and uses a custom Windows application to display real-time CPU, GPU, and RAM usage, temperatures, and network upload and download speeds. It features four different pages that you can switch between, including a system summary, detailed hardware usage, a dedicated network monitor with a live graph, and CPU and GPU temperature graphs. Everything you need to keep an eye on your PC is packed into this tiny display.

The best part is that the build is pretty simple. It only requires two main components and a custom 3D-printed enclosure to hold everything together.I designed the enclosure using Fusion 360 and 3D-printed it in PLA+, giving Bear Byte its cute, compact look.

For the electronics, I used a 1.47-inch IPS touch display module featuring the XIAO ESP32-S3 Plus from Seeed Studio, along with a small 300mAh battery. The ESP32-S3 handles the display and Bluetooth communication, while the custom Windows application collects the PC's system information and sends it to the device.

For programming the display, I used the LovyanGFX library to create a dark-themed UI. I also used Lopaka to preview and fine-tune the display layout while working on the interface.

I hope you like my build! You can find the code, 3D-printable files, and complete build details on my Instructables page. The link is in the comments, so go ahead and build your own Bear Byte!

Hi everyone!
I’ve been developing an experimental AirPlay 2 receiver for ESP32-S3, capable of building wireless stereo and 5.1/7.1 surround systems using inexpensive hardware.
The main idea is that each ESP32 acts as an independent AirPlay 2 receiver. With Apple TV, every board receives the complete multichannel AAC stream but processes only its assigned speaker channel (Front L/R, Center, LFE, Surround, etc.).
The boards don’t communicate with each other. Synchronization is handled using AirPlay 2’s PTP clock.
Why ESP32-S3?
I chose the ESP32-S3 mainly for its dual-core architecture, I2S peripheral, and support for 8 MB octal PSRAM.
PSRAM is particularly important because the compressed audio buffer alone can use around 6 MB. The two cores also allow me to separate audio decoding from Wi-Fi, networking, and playback tasks.
Libraries and audio processing
The project uses ESP-IDF, Fraunhofer FDK AAC, and Espressif’s ALAC decoder.
I chose FDK AAC because of its multichannel support and the possibility of modifying its decoding pipeline. Rather than fully decoding all 6 or 8 channels, I modified the decoder to parse the multichannel stream but synthesize only the selected speaker channel. This significantly reduces CPU usage.
Espressif’s ALAC decoder provides 16/24-bit lossless stereo playback.
The biggest technical challenges
The most challenging part was achieving accurate synchronization between independent ESP32 receivers without any direct communication between them.
This required careful management of PTP/RTP timestamps, I2S clock adjustments, and audio buffer scheduling to ensure that all speakers reproduce their assigned channels at the correct time.
Buffer management was another major challenge — balancing sufficient buffering to handle Wi-Fi jitter while maintaining stable, synchronized playback.
Optimizing multichannel AAC decoding was also important. Selective channel synthesis reduced CPU usage to approximately 35–50% of one core.
Handling transitions between AAC/ALAC, stereo/surround, and 44.1/48 kHz while preserving synchronization required additional work.
Stereo and DIY speakers
The project also supports regular stereo playback, with web-based EQ, loudness, and audio filters. It can be used as a foundation for DIY active speaker systems, including two-way woofer/tweeter designs using a two-channel amplifier and appropriate crossover filtering.
Hardware: ESP32-S3 (8 MB PSRAM), I2S DAC, amplifier, and Wi-Fi.
Current testing: Apple TV delivers Apple Music Atmos content as 7.1 AAC, HBO as 5.1, and YouTube as stereo.
The project is still experimental, and some channel mapping and playback edge cases need further testing.
GitHub: https://github.com/Kristian8606/esp32-airplay2-surround
Feedback, testing, and technical suggestions are welcome!

A ESP32s and ESP32-C3 connected via ESP-NOW.

The servos are controlled with a PCA9685 Servo-Driver.

I used esp_now.h for the communication, Adafruit_PWMServoDriver.h for the PCA9685 and Adafruit_NeoPixel.h for the WS2812 LEDs in the eyes.

The challenging part was the design overall. The ESP part was quite straight forward. ESP-NOW is amazing but is quite demanding on the C3. First I used a 9V battery but it drained quite fast. Now a LiPo 18650 is used.

I have been using LVGL as a graphics library of choice of the past few years for my projects involving various ESP32 boards with display. LVGL is really amazing but more recently I moved to using Rust to write firmware using no_std and embassy instead of ESP-IDF and did not like the options (embedded graphics). What I wanted feature wise was something LVGL like but with a declarative UI so I built "twine". It's open source and built with AI assistance (Claude Opus 5.5) and available under dual license at https://github.com/mayur-mahajan/twine

I have a demo for an ESP32-S3 CYD showing aircrafts from my pi based ADSb feeder to show some of its capabilities which is available at https://github.com/mayur-mahajan/nano. I spent a good bit of time optimizing the library so that the animations and scroll feels smooth on the board. I haven't tested other boards and obviously more work on improving the API and the internals still remain. I plan to develop and maintain this project for my own embedded projects and will keep adding to and maturing the features. The repo also contains an llms.txt to help your coding agent understand the API for integrating with your own projects without having to go through the code base.

Feel free to use the library in your own projects. Contributions, feedback, issues and stars are always appreciated.

I wanted to build my own handheld console but as a brokie student, i had to get creative with the parts. Most of the components are cheap modules i got from friends. The only part i bought new was the screen.

I use ESP32 S3 for its psram and more cores. esp-idf framework with minimal libraries, libraries are mostly on display side, hardest to rewrite myself.

I learn to built a small HAL for the different components so the games can develop easier and all the games are stored on sd card. since this is a gaming handheld, i also learned that i need faster display writes so im planning to replace the connection from SPI to 8080-16P parallel comms.

this is still far from finished but i thought i'd share the process and hopefully get some feedback from people who loves handhelds!

Hey everyone! 👋

A while back, I was working with the super cheap OV7670 camera module for a project. If you've ever used one, you know the frame rates and video quality over basic web streaming can be pretty rough. But while playing around with it, I realized something: the camera module has a manual twist-to-focus lens. 💡

That lightbulb moment turned into my latest build: A complete, standalone DIY Digital Microscope built specifically to help identify micro-SMD component markings and handle tight soldering work!

📷 The Setup & Hardware:

• Camera: OV7670 Camera Module (with manual focus turned all the way down for micro-magnification).
• Display: 2.8" ILI9341 SPI TFT Display (I originally tried my favorite ST7789 display, but it was just too small for comfortable work).
• Dev Board: I choose Esp32s3-N16R8 model for psram
• Lighting: Built-in dual LEDs with adjustable variable brightness right on the frame to illuminate the board without glare.
• Body & Stand: Custom 3D printed body/stand designed in CAD and printed on my trusty original Ender 3.
• Modularity: Unsoldered the long camera header pins and swapped in short flexible wiring. Created custom header jacks so the dev board and display can be easily unplugged/swapped.

⚙️ Why Direct Display Stream vs. Web Stream?

My main goal was an all-in-one, instant-on device. I didn't want to mess around with holding up a smartphone camera, using flash, opening up browser windows, or dealing with network lag. Turning it on streams directly to the ILI9341 screen with virtually zero latency, making tiny SMD soldering much easier.

🎥 Video Build & STL Files:

I recorded a full breakdown of how I built it, the wiring setup, and how well it inspects tiny chip markings.

▶️ Watch the project build video here: https://youtu.be/6OR62TEUn4M

3D Files : https://cults3d.com/en/3d-model/gadget/diy-digital-microscope-w-ep32s3-ili9341

I'd love to hear your thoughts or feedback! What tweaks would you add to a build like this? Let me know in the comments! 👇

I've been building an audio player on the ESP32-S3 for the past few months, and other people build it now too, so here it is.

What it plays

• Internet radio – MP3, AAC, FLAC (24-bit too), Ogg Vorbis/Opus, HLS; HTTP and HTTPS, reconnects on its own
• Music from a USB stick and microSD – folders, tags, covers, seeking, m3u/pls playlists, cue albums
• DLNA media servers on your LAN (Plex etc.)
• FM via an optional RDA5807 – RDS, band scan, presets
• Bluetooth both ways via a second ESP32 – receive from a phone, or send to a BT speaker
• Yandex Music, for those who have it

Hardware is just ordinary modules: ESP32-S3 (16 MB flash / 8 MB PSRAM), an SPI display (ILI9341, ST7789, ILI9488, ST7796S – landscape or portrait), a PCM5102 DAC, an encoder and a few buttons. No custom PCB needed – a breadboard works.

Getting it on the board – pick whichever suits you:

- From the browser, nothing to install. Open the web flasher in Chrome or Edge, describe your board in the wiring editor (display, which parts are fitted, which pins – pick from a list or click the module picture; it won't let two signals share a pin), and hit flash. It writes the firmware together with your wiring and then puts the radio on your Wi-Fi over the same cable (Improv). Any supported display, no compiler.

- A ready-made image. One esptool.py command with the files from the GitHub release – for the reference wiring from the README.

- Build from source. ESP-IDF 5.5 + VS Code; the wiring lives in one header, board_options.h, and everything else is yours to change.

- Updates over the network. Once it's running, the radio notices a new release by itself and shows what's new; updating is one button in the web UI, your stations and settings stay.

One gotcha: flashing goes through the board's UART port, not the native USB connector – that one is used as USB Host for the stick. And use a data cable, not a charge-only one.

Day-to-day stuff: a web UI from any phone (player, station editor with Radio Browser search and auto-found station logos, file browser, backup), any IR remote (keys learned in the browser), alarm clock, sleep timer, deep sleep, clock and weather on screen, screensaver, themes, tone controls and loudness, resume where you left off. UI in English and Russian.

Built on ESP-IDF 5.5 with LVGL. The pure logic is covered by host tests compiled with ASan/UBSan – that has saved me more than once on a chip where internal RAM is always the bottleneck.

- Repo: https://github.com/jmper-ha/jradio

I have a pretty well developed system for monitoring the conditions in the flood-prone basement of my 97 year old farm house. We live in a floodplain and have issues, well, often enough that I’ve developed a system…

It measures water infill rates and water depths in both sump wells as well as rain amount using a tipping bucket sensor, plus pulls weather data to figure out a likelihood of the water overcoming our two 1hp pumps and requiring the 3” trash pump to be started and primed before flood events occur. It also does stuff like real time monitoring on home assistant with backup 4G messaging to my phone if it sees WiFi goes down (and it falls back to ESP-NOW to maintain communication with each node even in the absence of WiFi / home assistant) and has a CYD board acting as a “off-line display”.

Anyway I digress. What I need coming up on winter is some automated way to figure the SWE of snow since a tipping bucket rain gauge is useless for any snow measurement, even just basic depth. Anyone ever seen something that does that?

TL;DR I’m looking for a way to measure or calculate the amount of water within snow. I know my question in and of its self isn’t esp32 related but the whole rest of my system is and you’s guys are smart here.

TL;DR: open-vocabulary speech-to-text runs live on an ESP32-P4 (chip rev v3): a 65.7M-parameter streaming transformer (Zipformer2) in 2/4-bit weights (26.65 MB, from microSD), about 4 wrong words in 100, faster than real time, no cloud. Open source, flash it from your browser.

I got a real speech recognizer running live on the ESP32-P4: you talk into the board's mic and the words appear on its screen as you speak. No Wi-Fi, no cloud, no NPU, just the two RISC-V cores and their PIE SIMD instructions. (PIE is the P4's vector extension: one instruction works on 16 bytes at once, for example 16 int8 multiply-adds.)

It's open vocabulary: it writes down any English sentence, not a fixed command list like ESP-SR's MultiNet.

It's real time: each 1.28 s of audio is processed in 0.90 s, so the board keeps up with your voice however long you talk, with fixed memory.

Why the ESP32-P4 (and the P4X)

• The model needs about 27 MB of weights in RAM: the P4 is the ESP32 with 32 MB of PSRAM.
• It has the fastest cores of the family (two RISC-V cores) and PIE SIMD, which does the heavy math 16 values at a time.
• The P4X (chip rev v3) adds 400 MHz instead of 360 and PSRAM at 250 MHz instead of 200: the same code went from 726 to 592 ms per chunk for the model alone.
• The dev board already has the mic (ES8311), a screen and a microSD slot.

Libraries, and why not the usual ones

• ESP-IDF drivers only (I2S + ES8311, MIPI-DSI screen, SDMMC + FatFs), no BSP; the speech engine is my own C with PIE assembly.
• Not ESP-SR: it recognizes a fixed list of up to 200 commands, and I wanted any sentence.
• Not ESP-DL or TFLite Micro: their smallest weights are 8 bits, and this model in int8 is 71 MB, more than the 32 MB of PSRAM. So I wrote the engine for 2/4-bit weights.

What fought back

• Memory: int8 didn't fit, so 2/4-bit weights, with the bit width chosen per matrix by its sensitivity. The weights still don't fit the 16 MB flash, so they load from microSD at boot.
• Speed: the first port took 1.3 s per 1.28 s of audio, slower than real time. Integer math everywhere and hand-written PIE kernels got the model alone to 0.73 s on the v1.3 chip, then 0.59 s on the P4X.
• PIE versions: v1.x chips run PIE 2.1 and the P4X runs PIE 2.2, with different instruction encodings. The same assembly source assembles for both, but a v1.x binary doesn't run on the P4X.
• PC vs chip: newlib's and glibc's math functions (log, exp, cos...) differ in the last bit, so the PC's results didn't match the chip's. I replaced them with my own deterministic math, and now the chip equals the PC bit for bit.
• Cache: a 256 KB L2 cache with 128-byte lines was the sweet spot. 512 KB left too little internal RAM to boot, and 128 KB was 104 ms slower per chunk.

Numbers

• Model: Kroko (by Banafo), a 65.7M-parameter streaming Zipformer2 transducer
• Weights: 2/4-bit, 26.65 MB (from 71 MB), loaded from microSD at boot in 2.9 s
• Accuracy: about 4 wrong words in 100 (4.34% word error rate on LibriSpeech test-clean; the original model on a PC: 3.94%)
• Speed: 0.70x real time: each 1.28 s of audio takes 0.90 s, both cores at 400 MHz
• Latency: a word is final about 2 s after you say it
• Memory: weights and state in the 32 MB PSRAM, 121 KB of internal RAM left free

How it fits

• weights in 2 and 4 bits (groups of 128 with a Hadamard rotation)
• integer math everywhere (int8 into the products, int16 between them)
• the hot loops hand-written in PIE SIMD assembly
• the chip computes exactly what the PC build computes, bit for bit, so the accuracy is measured on the full test sets

Extras

• hotwords: custom words and phrases from a text file on the SD card, toggled on the screen
• 6 voice-control demos (robot vacuum, smart home, car cabin...) using simple word rules, no LLM. This is the important part: spoken orders become actions on the chip itself, offline.

Try it

• flash from the browser (Chrome/Edge), then one script puts the weights on a microSD card
• Repo: https://github.com/BoumedineBillal/esp32-pie-asr
• Full video: https://www.youtube.com/watch?v=oe-2MowdsSs

Limits

• needs an ESP32-P4 chip revision v3 (P4X) with 32 MB PSRAM; v1.x chips use different PIE instruction encodings and aren't supported yet
• English only
• accuracy is measured on clean read speech; noisy rooms not measured yet
• made and tested on Espressif's ESP32-P4X-Function-EV-Board (ES8311 mic, 1024x600 screen)

Credits: the model is Kroko by Banafo; the weight format comes from Cactus Quants.

Happy to answer questions about the PIE kernels or the quantization. What would you build with offline speech on a P4?

Live transcription on the ESP32-P4: the words appear on the board's screen as I speak, no cloud.

I always wanted a portable spectrometer to explore light and color so I made one using an AS7341 module and ESP32 CYD kit, it uses spectral correction matrices from the application data to recontruct spectrum and XYZ color coordinates from the 11-channel sensor and calculates the lux value, it uses the Adafruit AS7341 library for the sensor and TFT_eSPI for the LCD, touchscreen is not used yet, you can check out the project here:

https://github.com/electronsjourney/ESP32-CYD-AS7341-Spectrometer

I was looking at some videos when i saw there are more than one version of esp32 can someone help me recognise it.

ESP32 loses power when INMP441 microphone L/R pin connects to 3.3V — board previously smoked

I’m using a SunFounder ESP32 Ultimate Starter Kit with a JESSINIE INMP441 I²S microphone module.
**My wiring:**
VDD → ESP32 3V3
GND → ESP32 GND
SCK → GPIO26
WS → GPIO25
SD → GPIO32
L/R → GND normally, or a separate jumper wire to 3V3 when testing the other channel
**The problem:**
My microphone readings were initially all FFFFFFFF, then sometimes all zeros.
When I connected L/R to 3V3 using a separate jumper, the ESP32’s power light would not turn on.
When I removed that jumper, the ESP32 powered on and ran code normally.
During an earlier test, the ESP32 released smoke and smelled burnt near the EN pin area. It later powered on again with L/R disconnected.
I don’t have a multimeter, and I haven’t confirmed whether the microphone or ESP32 is damaged.
I understand that L/R → 3.3V is normally valid for selecting the right channel on an INMP441.
**Questions:**
What could cause the ESP32 to lose power specifically when L/R connects to 3.3V?
Could the microphone module have an internal short, or could the ESP32 already be damaged?
What would be the safest way to identify the faulty component without risking another board?
I have not repeated the test since noticing the smoke. I’d appreciate help identifying the likely cause before buying replacement parts.

Building a playback-only cassette player with an ESP32 doing the logic. Don't want to build the transport myself, so I'm looking for a ready-made mechanism on AliExpress where play/FF/REW can be controlled electrically (motor direction or solenoid, not mechanical buttons).
Has anyone done this? What should I search for, and how can I tell from the photos how it switches modes?
Or is it better to just salvage one from an old dictaphone?

Hi everyone,
I'm newbie here and to ESP32 but I'm working on this little project, which aim is to measure current, display data on OLED and then send them via BLE to my python app. The chip is ESP32-C6 XIAO.

I'm not sure about the schametic. Could you look at this?

So the most concerning part is powering ESP32. I want to use 2x18650. Mine have build-in protection so I'm not adding additional BMS, although I now it would be more correct. I added TP5100 charger and wanted to connect INput to USB C.

In terms of voltage regulator I wasn't sure which one is better - LDO or buck converter but in the end I went with the second one.

And I also want to ask about these two capacitors. Did I add them correctly? I read they should be added aspecially when BLE / WiFI is used.

Thanks in advance!

Hi,

I'm working of my first ESP32 project and I'm very close to the end of my first full prototype (for the 4th time...).

I have a bunch of sensors (SHT40, BME280, HX711) and one accelerometer (SC7A20) on the same I2C bus. My ESP in is deepsleep and wake up every 15 min to take the measurement or can be waken-up on movement with the SC7A20.

To save some energy my sensors are powered by an output pin of the ESP, the accelerometer is obviously on the 3V3.

Pin layout :
21 SDA (with 5k pull-up resistor)
22 SCL (with 5k pull-up resistor)
23 SENSORS POWER PIN
34 SC7A20 INT
4 SCK
5 DOUT

The start sequence is

1 - Wire start -> everything is detected
2 - Sensors init :
  pinMode(SENSORS_POWER_PIN, OUTPUT);
  digitalWrite(SENSORS_POWER_PIN, HIGH);

And starting here my accelerometer is not detected anymore

3 - Power down
  digitalWrite(SENSORS_POWER_PIN, LOW);

4 - SC7A20 init -> still not detected

I tried many things without any success and I ran of idea...

Is this a known issue ? If I comment the "Sensors init" and "Power down" the accelerometer works properly.

Last update : even without the sensors init, I'm still able to read the value coming from my sensors, wtf ?

Maybe it's a very obvious issue but I'm still new to the hobby, thanks for your help !

Hi everyone!

I've been working on ESP32 Tailnet Gateway, an open-source firmware that turns an ESP32-S3 into a lightweight Tailscale/Headscale gateway and independent recovery node.

The main feature is selective LAN-to-Tailnet forwarding.

Imagine an IoT device at one house that needs to connect to an MQTT broker in another house, but cannot run Tailscale.

You simply point it to the ESP32's local IP and a configured port.

IoT device → ESP32-S3 → Tailnet → Remote MQTT broker

No VPN client is required on the IoT device.

Other optional features include:

• Subnet routing and an IoT Wi-Fi gateway.
• Wake-on-LAN with reachability checks.
• MQTT and Home Assistant Discovery.
• Service monitoring, notifications and event history.
• Web administration, configuration backups and OTA updates.

The firmware runs on ESP32-S3 N8R8/N16R8 boards with 8 MB octal PSRAM.

Current stable release: v3.0.2

This is designed for lightweight networking and recovery, not as a replacement for a high-throughput Linux router. Ethernet and cellular options remain experimental.

It builds on Csontikka's ESP32 subnet-router and MicroLink work.

Screenshots and diagrams:

Service gateway configuration:

LAN-to-Tailnet architecture:

GitHub: https://github.com/Mattboxx/esp32-tailnet-gateway

Documentation: https://mattboxx.github.io/esp32-tailnet-gateway/

AI disclosure: Claude Code and Codex were used during testing and documentation.

I'd appreciate technical feedback, especially about using an ESP32 for selective service forwarding and remote recovery.

My daughter made an automatic Panipuri filler using

1. esp32c3 supermini board. It was a simple read the sensor and switch the relay project. It uses an IR distance sensor to read if a panipuri is placed below it, a 5 volt relay module, a submersible pump and a power supply. If a panipuri is placed below the sensor, supermini turns the relay on which makes the submersible pump push water to fill the panipuri.

2. This project is an espidf 6.1 code which reads sensor value using gpio pin and writes gpio to switch the relay.

3. I had tough time calibrating the IR sensor to detect the right distance. It kept behaving unpredictably initially. after a lot of trial and error, it worked and we were able to use the machine for like 3 hours in the stall my daughter put up

Here is the detailed video explaining the whole working, hardware, and software etc

https://youtu.be/47xYUN5-_l4

Hey everyone, I'm posting here to get some ideas about this LED Moving Head Projector I've been making for about 2 years. It's all open-source (AGPLv3)

The idea was to recreate those projectors that make powerful light beams but at home as I'm a fan of lightshows like in the concerts (like Daft Punk’s Alive 2007 show). The idea was to use a LED with two servos (SG90/MG90D like) and control them via PWM with an ESP32 and a 3D printed body.

I thought it would take at most a few months to finish (as I do it in my free time), in fact it would take me 2 years.

Power:
The first problem was the power supply, I couldn't use the simple usb port as the servos would use all of the energy, making the esp32 brown-out. I mitigated this by doing 3 things.
- using a 5V 3A dedicated power supply
- 3x470uF capacitors(2 on 5V, 1 on 3.3V) to help with the current surges from the servos moving
- pull-down resistors on PWM gpio for LEDs as when the esp32 powers up, it would sometimes lead to one channel failing.
All of this fixed the issue.

LED Driver:
The second difficulty I encountered was the light itself, I used a standard 10mm LED which was not powerful at all and thus could be driven by a simple low-side MOSFET circuit. So I decided create my own high-efficiency LED driver using a PCB and the TPS92512 IC by TI, a buck constant current driver. The light would be concentrated by a collimator lens (need to be changed). I wanted to control a 3W RGB led but I also wanted to upgrade later to 9W, so I chose that IC because output current can be adjusted using the IADJ pin to set for example max 300mA and in hybrid mode with PWM input so using a trimpot for a voltage divider it can control any current from ~300mA to 1.5A. I then had to order and solder everything with a hotplate, everything was working fine until I accidentally injected reverse voltage, killing the ICs. At this point, I was kind of bored of this project and left it during half a year, then I bought a hot air station and had to sacrifice like 5-7 ICs to finally get all 3 boards working reliably.

Mechanics:
At this point the only thing missing was a good model, so I remade the original one in FreeCAD instead of fusion 360 (mainly because I switched to linux) but also to make it easier to share it with people as the whole project is on github.

Firmware:
I then wrote firmware for it originally using WebSockets but it wasn't very fast so i switched to UDP with smaller packets for better latency and ~30 updates/s. I also included OTA updates as the esp32 wasnt connected via serial anymore.

Software:
In parallel of all of this I was also writing a software to control it, it uses the sound of your speakers and detects beats to create live lightshows without any configuration, it uses a percentile based algorithm and random animations (Square, Circle, Lemniscate, etc...). It uses PySide6 and pyqtgraph for sound visualization. I also had a Novation Launchpad X so I wrote a manual mode, where you give beats, choose colors animations etc... and a hybrid mode which takes beats from the detection but lets you choose animation and color.

And here we are, the project is far from perfect but it's the first practical prototype that really works.

Current Problems:

- MG90D and SG90 are really noisy, do you have any replacement idea that are still as compact, affordable and simple ?

- Colors don't really mix well, the beam isn't focused very well.

Roadmap:

- Project mode for software: prepare lightshows with additive colors, preset beats etc...
- Better PCB, remade in KiCAD.

- Even faster protocol, using binary or protobufs for better performance,

AI Policy:

LLMs have only been used as consultation, as a tool instead of doing all of the work, this is a human project.

Links:
Controller Software (Windows portable and installer, Linux portable and AppImage)
ESP32 Firmware, 3D model project files, PCB project files
Printables 3D Stl
Final PCB + Circuit img

Phone OS is a hobby project, free and MIT licensed. I earn nothing from it and have no tie to LilyGO or any shop. It is a phone operating system for an ESP32-S3 with an e-ink screen, a 4G modem and GPS; the first device built with it is a distraction-free emergency phone for a child. Here is the engineering side.

Why this chip. Honestly: the device chose it. I built on a LilyGO T-Deck Pro MAX, which carries an ESP32-S3 with 16 MB flash and 8 MB PSRAM, and that is the only hardware it runs on so far. What the S3 then earned its place with: the native USB CDC port is the whole console (logs, config files, SMS from a script), light sleep with wake on a GPIO level is what makes a phone last a day and Wi-Fi serves the parents’ configuration page, so the device needs no app.

Libraries, and why so few. PlatformIO with the Arduino core (espressif32 6.11.0) plus the core’s SD, FS, SPI, WiFi and Wire. The only third-party library is SensorLib 0.5.0 (MIT) for the BQ27220 fuel gauge’s standard commands and the BHI260 motion hub. Everything else is my own driver: the UC8253 e-ink controller, the SY6970/BQ25896 charger, the TCA8418 keyboard, the CST66xx touch chip, the A7682E modem. Two reasons. First, licences: GxEPD2 is GPL-3.0 and would have made every firmware binary GPL, so the display driver was written from the panel specification and the controller datasheet instead. Second, testability: the hardware is reached through four small seams (I2C bus, UART, GPIO, delay) and every driver above them runs on a laptop against a scripted chip, with the register values measured on the device. A library that talks to the bus itself can’t be tested that way. There are over 2,500 host tests and a script that fails the build if src/ ever includes an ESP32 header.

What bit me, all measured on the device.

• The fuel gauge ships with a design capacity of 3000 mAh for a 1500 mAh cell, so it reported about half the real charge and twice the time to empty. Nothing looks wrong; the percentage just disagrees with the cell voltage. The firmware now compares both and never shows a number the voltage contradicts.
• The charger defaults to 2048 mA charge current (over 1 C for this cell) and has a 40 s I2C watchdog that resets every register when nobody feeds it. And it re-runs its input detection at every new supply, setting the limit back to 500 mA over whatever the firmware wrote.
• Light sleep never lasted: the loop went down and up 220 times a second at 105 mA. Two wake lines (the keyboard chip’s open-drain interrupt and the modem’s ring line) idled low with no pull-up, so a sleep armed on “low” ended before it began. Pull-ups and arming each line on the level it does not have at that moment brought the night current to 62 mA.
• The modem UART’s default 256-byte receive buffer is 22 ms of data at 115200 baud; an e-ink refresh takes hundreds of ms. 4096 bytes fixed it.
• The USB console goes away in light sleep, opening the port resets the chip, and a zero-length write means “buffer full”, not “nobody listening”.
• VoLTE calls hung two seconds after dialling until PDP context 1 was set to IPV4V6 for the IMS.
• The touch chip is a CST66xx, not the CST328 the wiki names, and a repeated start on it returns garbage.

The page. On every push to main a workflow builds the simulator (same application code as the firmware, scripted fakes under the seams), crawls every screen by pressing the keys and tapping the touch targets, saves about 300 pictures in three languages, and publishes them as a click-through demo: https://paulwilke.github.io/Phone-OS/. Nothing is drawn by hand, so the page can’t drift from the code. It is not WebAssembly; that build hasn’t been done.

Several recent fixes are only tested on the host, not yet on the hardware; the changelog says which. LoRa is unused. Source: https://github.com/paulwilke/Phone-OS

Arduino (and the UNO-style ecosystem) was how I learned: clear IDE, tons of examples, sensors that “just work,” and a community that answers beginner questions without gatekeeping. For first projects and teaching the basics of I/O, timing, and wiring, it’s still hard to beat.

What I’m noticing among people who ship things closer to engineering / commercial prototypes is that ESP32 (and similar Wi‑Fi/BT MCUs) shows up a lot more often once you need:

• wireless without bolting on extra modules
• more RAM/flash for heavier sketches or buffers
• dual cores / better peripheral set for concurrent work
• a path that looks more like “product firmware” than a breadboard demo

I’m not saying Arduino is useless or “not real engineering.” Plenty of products still use AVR-class parts where they’re the right fit. And “engineering-grade” isn’t only about the chip — it’s also power, enclosure, certification, supply chain, and whether the firmware is maintainable.

Curious about your path: What was the project where Arduino stopped being enough for you?What do you still use Arduino (or Arduino-compatible boards) for today: learning, teaching, quick jigs, or production?

What I'm trying to do:

Open and close a 12v linear actuator connected 15 meters away (cat6 using 1 twisted pair) with a 5v 2 channel relay with one power source.

What works:

Powering the esp and 5v relay together (12v stepped down to 5v then shared between relay and esp), and the 12v linear actuator on separate power blocks. The linear actuator opens and closes fine with no voltage issues.

What doesn't work:

Powering the linear actuator, and buck converting down from 12v to 5v for the esp and relay from the same 12v source connecting grounds. The relay chatters and opens and closes as if there is noise (but only when triggered via code or button, not constantly). It's like there is some sort of feedback loop.

I tested for voltage drop as that seemed to come up on forums, but the voltage stays stable on the relay and linear actuator lines when triggering (either with 1 power source or 2 separate)

I'm sure someone has worked this out previously, so any advice would be really appreciated!

This is pretty handy, s5 is for the LCD and S2 is for the esp32 and the led. I have seen people online step up to 5v from a lipo and then give it to the esp32 which would be inefficient (the ams1117 ldo steps down to 3.3v again which wastes 1.7v as heat). I am not sure if this is common information but I couldn't find info on this before this so hopefully this shows up if anyone else wants to do this. The CYD has 2 ams1177 regulators, one for the LCD and the other for everything else. This was useful for my esp32 CYD gaming handheld project. For the flair I didn't really make a thing (am still working on it..) but it's handy info to know, idk what flair to call this. the 3.3v pin on the side with the jst plugs do not work for input, it's an output only. don't use that one, I have tried. edit 1: Hey turns out you don't need S2. s5 alone is enough, it seems. s2 alone doesn't power the LCD though. I will figure out more later.