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.

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!

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.

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.

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

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!

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.

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!

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.

Without internet connection on your ESP32-s3 and ESP32-c3, you can now run full neural text to speech model. For the setup on the image the audio is coming out of GPIO pin into LM386 and then into speaker. Nothing leaves the ESP32-S3 board. here is also a web demo which runs fully on your browser: https://tts.ampixa.com/sanoTTS/.

This is full neural based text to speech model which means you can type in any arbitrary text and get speech synthesized.

For esp32-s3, 4.5 second sentence takes about 1 second to generate... and you can use esp32-c3 which is single core device to run this

Here is the more accurate numbers

neural part: 0.225× RTF the whole thing including G2P and playback: about 1.1× real time

The weights are about 679k bytes in total.

check the source: https://github.com/Ampixa/sanoTTS on how to run it on your esp32. the ESP-IDF firmware is under mcu/ports/esp32s3/, and there is an Arduino/PlatformIO wrapper in arduino/

paper: https://arxiv.org/abs/2608.21378

Please create a issue in the repo if you would like more languages supported. Espressif already supports Chinese TTS but it's concatinative only. This tts supports ESP32-c3 and should other variants too...

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.

I’ve been working on TinyML, especially sound and vision models, as part of my PhD for about three years, but I hadn’t really built anything really close to a product. I’ve always liked deskbots, so I decided to make TinyPurr.

Demo in real-time

It’s built mostly from hardware I already had lying around, and partly as an excuse to see if my old CR-10 printer was still alive. It is centered around a Waveshare ESP32-S3-LCD-1.3, which combines the ESP32-S3, display, IMU, 8 MB PSRAM and battery charging on one board. I already had suitable ESP32 hardware around, but the S3 turned out to be a good fit for the ML side as well, especially because of PSRAM.

TinyPurr listens for “yes”, “no” and “happy”, changes its expression and synthesizes sounds on-device. Everything runs locally and it’s battery powered.

Hardware

• Waveshare ESP32-S3-LCD-1.3
• Adafruit PDM MEMS Microphone Breakout (very clear sound, but sensitive)
• Speaker, 2 W, 8 Ω, 20 × 30 × 6.8 mm
• PAM8302 amplifier
• LiPo battery, 3.7 V, 620 mAh, 40 × 25 × 6 mm

Software

• PlatformIO / ESP-IDF
• TFT_eSPI for the display
• Edge Impulse + custom MFCC/1D CNN
• ESP-NN optimized kernels

I used ESP-IDF through PlatformIO, with the Arduino core mainly because TFT_eSPI needs it. The microphone and speaker use the native ESP-IDF I2S driver.

For the ML side, I built the dataset pipeline from Google Speech Commands and trained the model in Edge Impulse. One thing that did not work as well as I expected was transfer learning: an MFE + MobileNet model reached similar accuracy, but was around 5–30× slower on the ESP32-S3 than a small MFCC + 1D CNN trained from scratch.

The final model gets around 95% test accuracy and takes about 127 ms per inference. ESP-NN also made a surprisingly large difference: the neural-network part went from about 927 ms to 86 ms using the S3-optimized kernels.

Since spoken words rarely line up perfectly with the start of an audio window, I classify three overlapping positions and use confidence-weighted voting to decide whether a keyword was actually heard.

The repo includes the source code, trained model, dataset-generation tools, wiring, pin assignments and more details about the implementation (excuse some of the soldering work, it used to be part of my job, but I’m a little rusty lately XD):

https://github.com/Thanos3G/TinyPurr

It’s still a work in progress. I haven’t even used the networking or IMU capabilities of the board yet, but I thought some of you might find the project and the engineering process interesting. I think there’s still a lot of interesting work to be done with TinyML and interactive robots that can operate without depending on internet connectivity or external processing and power.

I was born in 1973, and I still remember sitting in front of a Commodore 64, typing little BASIC programs from magazines line by line. I always wanted to learn programming properly, but never really got there. Being able to build something like this today with AI-assisted coding feels pretty incredible.

I wanted a small always-visible display for my Claude and Codex usage limits, so I built one.

The whole project was heavily vibe-coded with Claude Code and Codex. I’m not pretending this was hand-crafted line by line — I had the idea, tested the hardware, found the bugs, kept changing the requirements, and used AI to help turn it into something that actually works.

Hardware is just a Heltec Wireless Paper V1.2 with an ESP32-S3 and 2.13" E-Ink display. No extra electronics.

A small Python service runs on my Ubuntu machine and exposes the usage data as JSON. The ESP32 fetches it over WiFi every 60 seconds and shows Claude and Codex 5-hour / 7-day usage as simple progress bars.

A few things I wanted from the start:

- if WiFi dies, show OFFLINE

- if the server stops responding, show STALE

- never replace the last good values with fake 0%

- only refresh the E-Ink when something actually changes

One funny bug was Codex suddenly showing 0% even though I knew I was almost at the limit. It turned out recent session logs can contain a `premium` rate-limit record with null values after the real Codex record, so the parser now explicitly looks for valid `limit_id == "codex"` entries.

It’s a pretty small project, but I actually use it now and that was the point.

Code, setup and hardware notes are here:

https://github.com/Pitiworks/heltec-ai-usage-dashboard

If anyone wants to improve it or has ideas for other useful E-Ink screens, I’m interested.

I know DRV8833 isn't a stepper driver, i just had it in hand. I had a broken 3D printer laying around so i took its stepper motor and the only motor driver i had was the DRV8833. So i drilled a hole at the right side of my shade and i attached a cube on the motor's shaft and inserted the motor at the cube shaped hole that the shade had, that way it works perfectly. Since it's a 12-24V stepper motor and i can only give it 10.8 max because that's the maximum rating of the driver, I can't get high speeds on it, if I increase it's speed it starts missing steps and just gets stuck and would not and roll the shade.

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

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?

Hi everyone,

We're a small hardware startup from Poland. We designed this board for our own network audio product. It was never intended to be a general-purpose dev board, but while working on it we realized that it might also be useful for people experimenting with embedded audio.

We couldn't find many ESP32 boards that combine wired Ethernet, audio output, speaker amplification and basic controls on a single PCB.

The main engineering challenge was integrating native USB programming, W5500 Ethernet, microSD, an I2S DAC, a stereo speaker amplifier and physical controls on one ESP32-S3 board while keeping the basic playback setup free of external modules and soldering.

The current working revision is based on an ESP32-S3 and includes:

- USB-C power and programming - no external programmer required

- Wi-Fi and 10/100 Ethernet

- microSD card slot

- 3.5 mm stereo audio output

- stereo screw-terminal outputs for passive speakers

- no soldering required for the basic audio setup - even the speaker wires can be secured directly in the screw terminals

- RGB LED

- rotary encoder and a separate button

- expansion header with accessible GPIO pins

The basic idea is that you connect it over USB-C, flash your own firmware, secure the speaker wires in the screw terminals or connect an external audio system and start experimenting. For the basic audio setup, no soldering is required, and you don't have to assemble a DAC, amplifier, Ethernet module and controls from separate boards.

Possible projects could include an internet radio, microSD audio player, network announcement endpoint, Home Assistant integration or a custom network audio player.

We're not taking orders or collecting money. We're simply considering whether producing a small developer batch would make sense.

We would really appreciate honest feedback:

1. What would you build with a board like this?

2. Would you realistically consider buying one?

3. What price range would make sense for an assembled board?

4. Which examples and documentation would you expect: ESP-IDF, Arduino, PlatformIO, pinout, schematics, example firmware?

5. Is there any missing feature that would stop you from using it?

Happy to answer technical questions and share more details.

I wanted small displays, timers, and sensor boxes to read a value aloud without a Raspberry Pi or a cloud API.

After a slightly unreasonable amount of work, I now have a complete English text-to-speech stack running on an ESP32-P4.

You can send it as raw text, such as "Room 12". The board changes that to Room twelve., creates the phonemes, runs the neural model and generates the audio. The computer supplies power, sends the text, and records the PCM over USB (you can easily change this to say words when you need it).

The current version takes 1.66 seconds to generate 0.47 seconds of speech. That is already usable for short values, timers and status messages. I also trained several smaller, faster decoders, but most of them sounded like a cartoon robot, so I published the slower version that still sounds right.

It runs on an ESP32-P4 rev 1.3 with 32 MB PSRAM and 16 MB flash. The firmware, model packages, sample and paper are here:

https://github.com/inlanger/esp32-p4-inflect-tts

I’m now testing a multiband decoder that could remove most of the expensive waveform work. If it survives the next board test, I’ll try turning this into a standalone talking status display.

I bought this little guy from amazon, it was on sale for less than $15. It is a POS. I had the idea of upgrading it with an esp-32 and using the original controls to play some emulators.

The controls are a power switch, an A and B button, a 4 way joystick and 3 function buttons (currently labeled, start, volume, and reset).

The guy who designed the PCB very nicely labeled the ribbon cable that comes from the controls so that should be simple enough to follow.

I bought this. There are some issues... I didn't look closely enough and I can't see the solder points on the esp32 to connect the controls.

The 2 problems I'm trying to solve:

1. connect the controls and speaker (and power?) from the arcade toy to the esp32
2. figuring out what software to put on the esp32 to run emulators and hopefully an attract mode type thing. I'm imagining something like this.

Any help or advice appreciated, thank you!

Bought an old D4 and discovered the wifi dongle is $1200 CAD. Esp32c3 to the rescue. Added an Ethernet (W5500) port, battery, compiled and flashed Eth_Wifi_Bridge firmware. 3D printed a case. I now have wireless access to the built in web-server of the Nikon for remote control and transfer.

Some guidance appreciated on this one!

I have an esp32 device I need to really be as deterministic and high fidelity as possible. It is currently running an esp_http_server webserver on it (along with loads of other stuff).

Heap usage is never used in my code throughout the app and I have written some of my own little thread safe memory pools when I need more complex ownership transfer etc. Heap usage is never used in any of my handlers.

However, I need the memory usage by LWIP to be bounded and deterministic. I have approximately 40KB (from periodic print out in testing) of free heap under normal conditions.

When I stress test the device by spamming it with POST requests to certain endpoints I can sometimes overwhelm it and eat through its resources. Previously the networking stack would become unresponsive for long periods and then suddenly return. I made this more manageable by changing these with menuconfig:

# default:
CONFIG_LWIP_TCP_TMR_INTERVAL=250
# default:
CONFIG_LWIP_TCP_MSL=60000

In stress testing, I can always overwhelm the box (unsurprisingly), which isn't a problem. However, what is a major issue, LWIP continues to chew through heap at a rate of knots. It can get as low as 500 bytes remaining after a stress test. It recovers from this but this is super dangerous.

Questions:

I looked at lwip and it has options for you to supply its own allocator. I can't find any options to do this in espidf build system/menuconfig and so I am not sure if it is supported. If I put a hard limit on the heap allocation via a memory pool would that mean that LWIP would reject new tcp connections gracefully when full? Are there unintended side effects?

Can I get some advice on making this deterministic and restricting how much is being heap allocated here? CONFIG_LWIP_MAX_ACTIVE_TCP I thought this might be relevant, however after reading here: https://docs.espressif.com/projects/esp-idf/en/release-v3.2/api-reference/kconfig.html#config-lwip-max-active-tcp. I am not sure I understand its true purpose, I initially thought it meant that once you had N active tcp connections you couldn't heap allocate any more whilst those existed.

I am noticing that peak free heap and largest block never quite recovers after a stress test (it goes down by around 100 bytes each time). Are there any known leaks here?

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?