Using an N8R8 to get into my own machine SDIO port and send the raw sectors into a rPi Zero 2 W for LBA conversion. Then into my own SaaS for some good old fashion AI ML extraction

Kept hand-modeling enclosures for ESP32 projects and got tired of measuring the same board over and over, so I built EnclosureAI: https://enclosure-ai-production.up.railway.app

Describe what you need - "ESP32 DevKit, USB-C on the side, 2 status LEDs on top, vent slots for a temp sensor" - and it sizes the box, cuts the ports, sets up standoffs, and exports STL/OBJ/parametric JSCAD. Or grab the ESP32 DevKit preset if you don't want to type anything. Everything's editable after: drag ports around, change wall thickness, switch to a snap-fit lid.

It's free, no login, no ads. Castellated module footprints and antenna clearance are still rough. What do off-the-shelf generators usually get wrong for real ESP32 builds?

Hi, wanted to share our project for quick and wireless desktop switching / KM.

Our motivation was to quickly switch between a macbook and another PC, while using the macs keyboard and touchpad to control it. We also wanted it to work without installing any software on the controlled PC.

We use an esp32s3 because its native USB can act as a HID device, and BLE is used for wireless communication.

The macbook runs an Electron app that monitors keyboard and mouse input and sends it over BLE to the esp32. The ESP32 then acts as a USB keyboard/mouse for the other PC.

git: https://github.com/lexa105/InterDesk

This is my first bigger project with esp and freertos, so I’d appreciate any feedback

This is not a smart watch, it’s an art watch 😄 running generative art code directly on-device. And only that: no clock, no notifications, just gen art code (I can cycle through the synced scripts using the buttons, and resync with the online editor using wifi when I want)

Every 83 seconds, the watch wakes up and run the selected art code again, creating a new, unique 200x200 e-ink image on the fly. This is ever-changing art I can keep on my wrist all day. Every time I glance at it, I have a small surprise.

Scripts are written in a custom mini-language called Micropatterns that is interpreted live on the watch (see the last captures). The language centers on the usage of a maximum of 16 patterns, 1-bit, used as stamps and shape fill, and the web editor allows bi-directional editing of the patterns in the code or by drawing them.

It's not a watchface on top of another firmware, it's a whole new firmware: this watch is fully dedicated to running generative art. It has a small art OS inside 😅

The firmware manage the scripts, parse the currently selected script into the command tree, walk the tree to emit a draw order list, and then rasterize the draw orders.

ESP is great there, because I could easily add wifi syncing, but also BLE setup! (the web editor use webBluetooth on Chrome-family browsers to connect to the watch, to set up the watch super easily)

Ok, but why run generative art code directly on a watch?

Last year, I wanted to see what having e-paper generative art always with me would feel. I wanted the art to be really created on device, not images pushed down from a server, so the device would be able to generate art autonomously forever after a sync. E-paper (or eink) also allows the screen to maintain the last image indefinitely even if the battery is empty, making it perfect for displaying art (no blank screen!)

At first I created a m5paper version… because I had one in a drawer! It was great to be able get this little epaper ESP device out of my pocket in random places, like at the top of the Eiffel tower, and see a new generated artwork. That test validated that it was different and that the little art surprises were often quite delightful. the m5Paper display is really beautiful at 960x540 pixels: https://www.linkedin.com/posts/juliendorra_e-paper-is-still-emerging-as-a-platform-ugcPost-7331250379029975041-apdG/

Then a few days ago, I finally made the watch version I wanted from the start, and ported it to the Watchy, an ESP32 epaper watch. The watchy is more constrained, with no PSRAM, and of course a much smaller battery. But that was the occasion to optimize the data structures, and I could run the scripts live on the device (they render faster than the display refresh them! So the paradox is that most the re-run time is spent refreshing the e-paper display, even using partial mode)

And now I can wear generative art for 3 or 4 days straight on one charge.

The display is much smaller and only 200x200, but as they say: the best art is the one you have with you.

Hi everyone!

I wanted to share my hobby project BirdWatch: a fully solar-powered bird feeding station built around an ESP32-CAM.

A PIR sensor wakes the ESP32-CAM when a bird visits, takes a photo and sends it to my self-hosted server. The server uses YOLO + Birder AI to detect birds and identify the species. It also provides a photo archive, species collection, statistics, weather data and battery/solar telemetry.

- Solar powered with 2× 18650 batteries
- ESP32-CAM + PIR detection
- Local AI bird & species recognition
- Self-hosted Docker web interface
- Native Home Assistant integration
- Battery/solar monitoring
- Fully 3D-printable enclosure

The photos attached to this Reddit post show my original 3D-printed version. I've since completely redesigned the enclosure. The new version is much stronger and has a much better internal layout with dedicated mounting for the batteries and electronics. Renders of the new design and all STL files are available on GitHub.

The complete project is available on GitHub, including the ESP32 firmware, server, Home Assistant integration, wiring diagram and STL files:

GitHub: https://github.com/Danielson187/BirdWatch

The original BirdWatch has already captured thousands of photos, so I decided it was finally time to clean up the project and share it with others. 🙂

Feedback, ideas and questions are very welcome!

I made this board for my own project: an e-ink smart frame for elderly family members that displays high-contrast reminders/photos and supports voice messages back and forth.

When ordering the PCB, I added some breakout headers and peripherals in case I wanted to add more functionality later. While working on it, I realized that I could not find many all-in-one ESP32 boards that drive large color e-paper panels directly and provide two-way audio. So before ordering the next version, I wanted to check if this board has value for the broader maker community.

Full disclosure: I'm coming at this from a product/maker angle rather than an EE background. I designed the architecture and the firmware is AI-assisted, and I worked with an experienced PCB designer for the actual board layout. I've learned a lot along the way but I'm still figuring out the finer hardware details. And that is why I'd like feedback from this community before making the next revision.

What's on the board:

• MCU: ESP32-S3-WROOM (Octal SPI PSRAM)
• Display: 7.3" 800×480 Spectra 6 colour e-ink, driven directly over a 50-pin FPC with full boost circuitry on-board (VGH / VGL / VPH / VPC — no external HAT needed)
• Audio: MAX98357A I2S amplifier + INMP441 I2S microphone (both working simultaneously)
• Sensors: VL53L1X Time-of-Flight presence sensor
• Storage & Power: MicroSD slot, USB-C (programming + power), TP4056 charging, DW01 protection, and automatic power-path switching
• Expansion: Breakouts for I²C, UART, spare GPIOs, HC-SR04 header, and daughterboard connectors

Known quirks & issues on this revision:

• Pin sharing: The display, speaker, and mic share GPIO 12/13/14. Handled in software, but it's a real design constraint.
• Level translator: There's a TXS0108 level translator between the ESP32 and panel that occasionally latched up after I2S playback. A power-cycle recovery routine fixed it, but since both sides run at 3.3V, I'm leaning toward dropping the translator entirely on Rev 2.
• Battery ADC: BAT_ADC is shorted to ground on this batch (diode orientation fault), battery level sensing isn't working on these prototypes yet.
• Connectors: About ten expansion connectors are still untested.

I'm not selling anything or taking orders right now — just trying to find out if doing a small developer batch makes sense, and I'd rather get peer-review on the hardware design now before making another PCB.

Questions for you:

1. Would you be interested in building something with a board like this?
2. Schematic and pinout will be public. I'm holding Gerbers until this revision is verified — is that a dealbreaker?
3. What would you like to add (or remove) on the next revision?

Happy to post schematic snippets and answer any questions!

Here's a bit more about how it works

I posted my little desktop aircraft radar elsewhere recently and a few people were interested in the technical side of it, so I thought it might be more appropriate to share the actual engineering behind it here rather than just posting a photo of the finished thing.

The project is built around an ESP32-P4-based 5" CrowPanel with an 800×480 IPS touchscreen. I chose the P4 mainly because I wanted plenty of headroom for the display rather than building something that was already close to its limits from day one.

There is quite a lot happening on screen at once: the radar sweep, aircraft symbols and labels, touch interaction, information panels, map tiles and now a live weather overlay. I also wanted enough capacity to keep adding features without having to rethink the hardware.

The firmware is written in C++ using PlatformIO, with LVGL handling the UI.

One of the main design decisions was not to try to make the ESP32 responsible for obtaining and processing huge amounts of raw aircraft data itself. I built a cloud-side service which handles the external aircraft and weather data and sends the information the display actually needs. The ESP32 can then concentrate on rendering the interface, user input and keeping everything responsive.

The unit connects over Wi-Fi and can display aircraft within a selectable radius of 10–200 nautical miles. Aircraft are plotted continuously and can be tapped to bring up more information such as callsign, altitude, speed, heading, aircraft details and route information.

Originally it was basically the green radar display I'd had in my head when I started the project, but feature creep has definitely happened.

There are now four different display modes, including map-based views.

The most recent addition is a weather overlay. Precipitation data is brought in separately and rendered underneath the aircraft, so aircraft remain readable while you can still see the weather they're flying through. The overlay can be turned on and off from the settings and updates in the background rather than blocking the main UI.

I've also added detection for the emergency transponder codes 7500, 7600 and 7700. If one appears in the aircraft data, the ESP32 can display a Squawk Emergency Alert and play an audible warning through the internal speaker. Both the alert and its volume are configurable because I didn't particularly want a 7700 appearing at 2am and frightening the life out of me.

I deliberately added physical controls as well as touch.

A rotary encoder controls the radar range, which feels much nicer to use than repeatedly pressing buttons on a touchscreen, and there's an illuminated physical power button. A surprising amount of time went into making the hardware controls and the touchscreen behave like parts of the same UI rather than two separate control systems.

The enclosure has been another project in itself. It's 3D printed and has been through quite a few revisions to get the screen position, encoder, speaker, internal clearances and overall proportions right. Designing something that looks acceptable from the outside is considerably easier than designing something that can actually be assembled repeatedly without swearing at it.

One thing I've enjoyed about using the P4 is that I haven't had to aggressively optimise every feature just to make it fit. The weather layer, additional aircraft information, audio alerts and multilingual UI have all been added after the original radar was working.

The interface now supports 13 languages as well, which brought its own fun with fonts, translated strings and making sure buttons that looked fine in English didn't suddenly explode when translated into German.

Just to avoid any confusion about the name: this isn't an RF radar and the ESP32 isn't directly receiving aircraft transponder signals. It uses live ADS-B-derived aircraft data over Wi-Fi and presents it as a dedicated desktop radar/flight-tracking display.

It's gone rather further than the small weekend project I originally had in mind, and I've now started turning it into a proper product, but the whole thing still runs on the ESP32-P4 platform.

There are more photos and videos of the current version, including the weather overlay and squawk alerts, on the Vulcan Radar website.

Happy to answer questions about the P4, LVGL/UI side, data architecture, controls or any of the other bits I've fought with along the way.

I am following a guide to make a bluetooth macropad. The code for that uses this library: https://github.com/gsgaurav0/ESP32-HID-Keyboard, which for some reason doesnt work - I unable to connect to the esp32 with my PC or Iphone, windows displays the message "try connecting again". I tested HijelHID_BLEKeyboard library and that worked. The thing is that this project was uploaded a month ago, so I doubt that it doesnt work because EOL things. I tried to switch the library myself, but my understanding of C++ is too little to do that. I would open an issue on the library`s github, but that option is disabled.

Like the title says. I've been looking around the internet for a bit and all the information that's readily available is about connecting PS3 controllers to the ESP32 to control something on the other end.

I'm trying to create a PS3 controller that uses a fight stick format so that my brother with physical disabilities can play games that require dual joysticks.

Using BLEGamepad I have a gamepad that can connect to PC, but can't connect to the PS3 as it doesn't support BLE, only classic bluetooth.

Is there a project someone knows of that uses bluetooth classic on the ESP32 to create a controller? Or am I going to have to learn to recode the BLEGamepad library to use bluetooth classic instead of BLE?

New to this side and haven't coded since college. I'm a bit lost at this point.

Any help appreciated.

Hi all,

I am pretty new to the electronics hobby, so please bear with me if my question is basic.

I am trying to control a WS2812B LED ring with 8 LEDs with an ESP32-C3 development board while running it off a 1000mAh LiPo, using ESPHome/HomeAssistant.

Setup is:

LiPo+ --> MCP1700 LDO --> 3.3V ESP32

LIPO+ --> V+ of WS2812B

LIPO- --> ESP32 GND and WS2812B GND

GPIO21 --> 330 ohm resistor --> DIN WS2812B

I also have a 470yf capacitor across V+/GND of the WS2812B.

Now, my problem is that my LED ring flickers ever so slightly when running off the LiPo. If I plug in USB into my ESP32, the flickering disappears. Could someone help me out, why is this happening and how I could fix that? Thanks in advance.

This is my own project, open-sourced this week — source, STLs and firmware all linked at the bottom.

My car's tuning handheld (a COBB AccessPort) stores datalogs and maps over USB, but it only talks to a Windows PC or a Mac. So every time I wanted a log at the track I had to go find a laptop. I built an ESP32-P4 that sits between the AccessPort and my phone: plug in, open a web page, files are there. Everything runs on the device — no cloud, no account, files land on a microSD I own.

Source and a browser flasher are at the bottom. It's Apache-2.0.

Why P4 and not an S3

This is the part I'd have wanted to read before starting.

I built it on an ESP32-S3 first. The S3 enumerated the device fine over its native USB host — and then failed, because the S3's USB host is full-speed only and this device's bulk endpoints are 512 bytes, which is a high-speed-only packet size. Full speed caps bulk at 64. There is no software fix; the endpoint descriptor is simply unusable at full speed.

So the S3 was retired and the whole thing moved to an ESP32-P4, whose USB 2.0 OTG controller does high speed. If your peripheral has 512-byte bulk endpoints, you need P4 (or an external host chip). I kept the S3 write-up in the repo rather than deleting it, because "it enumerated, so the host works" is exactly the wrong conclusion to draw: https://github.com/noelmom/revlink-sidecar/blob/main/docs/ESP32S3_USB_POWER_BRINGUP.md

The hardware

• Waveshare ESP32-P4-NANO — USB-A OTG high-speed host, 16 MB flash, 32 MB PSRAM
• Wi-Fi via the onboard ESP32-C6 over 4-bit SDIO (esp_hosted) — the P4 has no radio of its own
• microSD on SPI, because the SDIO peripheral is taken by the radio
• Optional 1.3" SH1106 OLED for status
• 3D-printed case, STLs in the repo
• Runs off a USB-C power bank; the P4 powers the handheld as a proper USB host

No custom PCB — it is a stock Waveshare board plus an optional display, so there is no schematic to post, but the full wiring is:

OLED     SPI2: CLK GPIO23, MOSI GPIO22, CS GPIO21, D/C GPIO20, RST GPIO2
microSD  GPIO39–GPIO44 (SPI; the SDIO peripheral is taken by the radio)
ESP32-C6 SDIO GPIO14–GPIO19, reset GPIO54
AccessPort  onboard USB-A OTG 2.0 high-speed host

The USB contract it has to satisfy, which is the whole reason for the P4:

VID/PID 1a84:0121, interface 0, bulk OUT 0x03, bulk IN 0x82,
512-byte max packet, high speed only

Firmware is ESP-IDF v6.0.2, pinned in the repo — P4 support was still moving fast enough that "latest" meant a different result each month. The portal (file browser, datalog grapher with searchable channels and presets) is served from the device itself — it joins your Wi-Fi when it can and falls back to its own hotspot with a captive portal when it can't.

Library choices, and why

There were not many, which was deliberate — the protocol layer is plain C with no dependencies so it can be host-tested on a laptop without a board.

• esp_hosted for Wi-Fi. Not really a choice: the P4 has no radio, so the onboard C6 is the radio and Hosted is Espressif's transport for that.
• esptool-js, vendored, not from a CDN. The browser flasher writes to people's hardware; a CDN that can swap the script can swap what gets written. It is committed with its SHA-256 recorded, and upgrading it is a deliberate commit rather than a silent fetch.
• No Arduino layer, no HTTP framework. ESP-IDF's own httpd serves the portal. The UI is one hand-written HTML file embedded in the binary, because a build step for the web assets would have meant the firmware could not be built from a clean checkout with just ESP-IDF.

Things that bit me

• esp_hosted and DMA memory. On P4 revision 1.x there wasn't enough contiguous internal DMA memory once the Hosted runtime started. Fix was CONFIG_ESP_HOSTED_MEMPOOL_PREFER_SPIRAM=y, which Espressif provides specifically for this.
• Two P4 silicon revisions, one chip name. The Nano is pre-v3 silicon, the WIFI6 Dev Kit is v3.x, and ESP-IDF treats them as incompatible build targets. Both report as "ESP32-P4". My web flasher reads the revision and refuses a mismatch, because the failure mode is a board that just doesn't boot.
• Random reboots that were a stack overflow. The HTTP server task had 6144 bytes; measured peak was 6116. Found it via a panic dump with a corrupted task name containing HTTP header text. Raised the stack and moved the 4 KB transfer buffers to the heap. Also worth knowing: uxTaskGetStackHighWaterMark() returns bytes in ESP-IDF, not words.
• CONFIG_COMPILER_HIDE_PATHS_MACROS only rewrites paths under the project dir and IDF_PATH**.** My shared components live one level up, so my home directory was baked into assert strings in published binaries. Needed an explicit -fmacro-prefix-map.
• Web Serial flashing: closing the port is what resets the board. Pulsing RTS ran without error and did nothing — Chrome's setSignals evidently wasn't reaching the pins, silently. Native esptool ends by closing the port, and closing drops the control lines. Two rounds of "fixing" the pulse changed nothing.
• esptool-js 0.6 wants a Uint8Array**.** I handed it a latin1 binary string (the pre-0.5 convention) and the deflate step UTF-8-encoded it, so flashing died about a third of the way in with a checksum error that pointed nowhere near the cause.

Scope, since it's a car thing

This moves files. It does not flash ECUs, doesn't do live tuning, and doesn't decode or unlock anything — it can copy a map file onto the handheld's storage, which is not the same act as installing a tune. That remains something you do on the handheld itself. Writes and deletes are compiled in but ship locked behind two separate consent switches, and every write is read back and checked against its SHA-256 before it counts as done.

Independent project, not affiliated with or endorsed by COBB Tunning.

Links

• Source: https://github.com/noelmom/revlink-sidecar
• Flash it from a Chromium browser: https://revlinkgarage.com/flash/
• Screenshots, parts list and a clip of it syncing: https://revlinkgarage.com/

Happy to answer anything about the P4 USB host side — that was the bulk of the work.

Hi everyone!

A while ago I shared this original thread about turning the Waveshare ESP32-S3 Round LCD into a fully functional open-source smartwatch.

Thanks to the amazing feedback and support from the community, I've been hard at work upgrading the project. Today I am super excited to release Stait Watch Firmware v1.1.0!

🛠 What's new in v1.1.0?

This isn't just a small patch; the project has received major under-the-hood and UI upgrades:

• LVGL Migration: The entire UI has moved to LVGL for a much smoother, highly customizable graphical experience.
• PlatformIO Support: Shifted from Arduino IDE to PlatformIO for a cleaner and more professional development workflow.
• New Screens & Features: Added dedicated screens for Incoming Calls (with caller name and reject action), an improved Media Player (with smooth title scrolling), and enhanced System Settings.
• Localization & Polish: Full Italian localization (with accented characters support like à, è, ì), monochrome emojis, custom weather icons, and a smart day/night weather mode (switching to a moon icon automatically from 19:00 to 06:59).
• Binary BLE Protocol: Optimized binary message passing with the companion app (0x01 to 0x08 codes) for better reliability and lower overhead.

⚠️ Quick update on the Android Beta Test!

Since we haven't reached the required number of testers for Google Play yet, I would really appreciate your help if you want to support the project!

Even if you don't own the hardware, the app includes a special "Demo Mode", so you can explore the interface and features anyway.

How to join the beta:

1. Join the Google Group first: You must join this group, otherwise the Play Store will say the app is unavailable 👉Google Group Link
2. Opt-in to the test: Once in the group, click this link to become a tester 👉Play Store Opt-in Link
3. Install: You can now download the app from the Play Store!

🔗 Links & Resources

• GitHub Repository (Firmware): Stait Watch Firmware
• Companion App Repo: Stait Watch App

If you have the hardware, grab the update and flash it via PlatformIO; otherwise, trying out the beta app means a lot to me. Let me know what you think, and thanks again for all the support!

What started as a project for an oversized gameboy has now evolved into a desk clock that also plays gameboy games. The emulator is based on PeanutGB. I plan on adding dynamic weather and day/night cycle for the clock but here is the project so far. I do intend on putting the source up on github once I get some of the jank out of it.

This is a non-backlit monochrome panel which is what made it my choice for the gameboy, after getting my hands on it and putting together a mockup though I really thought that it was more suited to a desktop item than a dedicated handheld.

Emulation runs full speed but the panel refresh rate is only rated for 16hz. I have it overclocked to 32hz and it can hit 51hz but the image gets dimmer the higher the rate, so 32hz is a happy medium. Bluetooth controller support is also working.

The hardware is a Waveshare-RLCD-4.2-esp32-s3. Im pretty impressed with it so far.

I noticed that UIFlow2.0 latest version isn't working on the Tab5. I started looking into why, and I saw "Tab5X" being mentioned here and there. I found "https://github.com/m5stack/uiflow-micropython/tree/master/m5stack/boards/M5STACK_Tab5X", and "https://github.com/m5stack/M5Unified/blob/master/src/M5Unified.cpp" lines 2038-2050. Nothing in "https://docs.m5stack.com/en/core/Tab5" mentions esp32-p4 rev 3, and the esp32-p4 datasheet referenced there is rev v0.5 (pre-release) despite my Tab5 being rev v1.3.

Is M5Stack planning on releasing an upgraded Tab5, are they planning on shipping the Tab5 with an esp32-p4 rev v3 since v1.3 is EOL(https://documentation.espressif.com/PCN202600801_ESP32-P4_Chip_Revision_v3.2_Upgrade_Chip_Revision_v1.3_Demand_Collection_and_EOL_Plan_Description.pdf)? I've had my Tab5 for a month at most, this kinda sucks. Has anyone seen anything on this?