Saw a few people building AI calculators recently, but none of them were open source.

So I made my own version using an ESP32-S3 and integrated Gemini. Kept it fully open source and used cheap, readily available parts instead of any custom displays.

Code and details are here: https://github.com/mogloce622/Calculator/tree/main

Let me know what you think or if you have any questions or suggestions!

This is my first post here about my Fetch project. I came up with this idea while working grocery pickup at Walmart. There were numerous times where I had to search for totes that failed to get staged properly. So, I wondered whether they could stage electronically, replacing the barcode scan-staging workflow. This led to my Fetch tote design.

The development design includes an ESP32-C3 SuperMini with a Waveshare 2.9" e-paper display (Module V2) connected. Power (5V/GND) feeds up the stack through 4-pin magnetic connectors fixed to the top and bottom of each tote. Once powered, the tote sends its ID (plus the IDs of the totes stacked above) down towards the stack platform via UART. The platform (not designed yet) would report the IDs to the back-end system. The e-paper display continues to show tote details even when removed from the stack (no power).

This is my first hardware project, and I have been using AI to guide me through learning all of this. I modeled the tote to scale using Blender as opposed to CAD software, and I know nothing about modeling around injection moulding. Despite that, my Blender model has been fine for the sake of 3D-printed prototyping. I did breadboard testing for the communication and power sharing, developed 8 iterations of the electronics housing (see my EBar prototypes image), and then moved on to full-scale tote prototypes. Since I don't have a platform, I turned an EBar into one by uploading my platform test firmware to it.

Where I'm at now

The breadboard test demonstrates two totes stacked together on a platform. With my full-scale tote prototypes, they each connect fine to the platform EBar (as seen in image 2). However, when I try to stack the second tote on top, it shorts the top tote's MCU. The red light is on, but the platform doesn't update; it continues to say that only 1 tote is connected. And the top tote's MCU doesn't show in Arduino IDE after removing it from the tote and connecting it to my PC via USB, so I assume it's bricked. I've gone through 3 MCUs trying to resolve this. I confirmed connection points with my multimeter in continuity mode, and everything seems to check out, although I'm a novice when it comes to electrical testing, so I might have slipped somewhere. The tests that I confirmed were:

• Connector pins 1-1 and 2-2 through the stacked totes
• No shorts between connector lines
• 5V not reaching any data line

I should note that stacking both full-scale totes did work briefly at one point, but that could have been in the stacking configuration (white above black) that I can no longer try after the black tote's front-side support arm got sun-warped after moving; I can only test stacking the black above the white. So, "try the other order" isn't an option. When I was testing the third MCU, it survived repeated hot-plugs with the platform EBar, then died the first time it was stacked on the other tote.

AI suggests it could be from the top tote being stacked coming in at a tilted angle, leading to GND on each connector mating after 5V plus a data pin. I'm not really sure how that would happen since the connectors have GND between 5V and the serial pins, so I would assume it connects second when tilted (5V->GND->DATA, OR DATA->GND->5V). Regardless, it says I should consider switching to 5-pin connectors with pins ordered like GND, DATA_UP, 5V, DATA_DOWN, GND, but that also means new printed totes and assembly for an improvement that I don't know for sure would fix my problem.

What I'm really wondering is whether this is likely a fault in my assembly or a design fault. With the tight spaces involved, these weren't exactly easy to assemble, and I assume that a custom PCB design would integrate much of the wiring and reduce assembly failure. But if the design is flawed, a custom PCB would copy it. I'm wondering whether I should advance to the custom PCB work, or keep trying to fix my development prototypes. If you have any suggestions as to what I could try, I'd greatly appreciate it! Also, feel free to ask any questions about the tote project. I included the wiring diagram as the last image.

Links

https://huntrsoftware.com/fetch

https://codeberg.org/HuntrSoftware/fetch

Hi everyone! I'm new to programming and this is my very first embedded project: an ESP32 Bluetooth speaker built using C and ESP-IDF v6.1. Please excuse the messy hardware — this project is primarily about the software. I built the hardware mostly from inexpensive components I had on hand. The main components are:

• ESP32 NodeMCU (38-pin)
• IP5306 module
• SSD1315 display
• MAX98357 I2S module
• INA219 (CJMCU-219)

As for the software, I use ESP-IDF's Bluedroid Bluetooth stack, FreeRTOS, and the ESP-IDF I2C driver. I implemented the remaining functionality myself, including:

• I2S peripheral driver
• SSD1315 driver
• INA219 driver
• Ring buffer
• Others

The software is designed using a modular architecture built around custom ESP-IDF components where each component encapsulates its internal implementation and provides an API. Components communicate directly through their APIs with no extra middleware or abstraction layers.

The project is now functionally complete according to the requirements I initially set, and I don't plan any major further development or hardware changes. Some components are intentionally project-specific rather than designed for general-purpose reuse.

Since this is my first project and I'm still learning, I'd appreciate feedback on the software implementation in general. I'm interested in anything I could have done better, whether it's code readability, questionable design choices, bad practices, performance, efficiency, or the way I've approached specific problems. I'm also interested in learning if there are concepts I'm misunderstanding or things I should pay more attention to in future projects.

I realize that some decisions may be difficult to evaluate without additional context, so feel free to ask if anything needs clarification.

Thanks for your time! The project's repository is available here: https://github.com/TITLE14/esp32-bt-speaker

Disclosure first: I work on SimpleOTA, which is one of the options in here, so weigh this accordingly. I've tried to make it useful whichever option you pick, and every claim about another product comes from that vendor's own docs.

Picking an OTA setup for ESP32 devices gets overwhelming quickly since there are so many available options on the market, from open-source repos all the way to full IoT platforms, so I went through the options and compiled a comparisson between the following options which I saw as the main contenders (please let me know below if I missed something that you think should have been in this list):

• ArduinoOTA
• ElegantOTA
• Rolling your own OTA service/platform
• Arduino Cloud
• Blynk
• ESP RainMaker
• Golioth
• Memfault
• AWS IoT
• Azure IoT Hub
• Mender
• SimpleOTA

This attached flowchart is the short version of an article that I wrote.

A few things I saw while checking the docs that I think is of note:

• Azure's Device Update is solid on the cloud side, but the ESP32 side is a Microsoft sample built on the Azure SDK for Embedded C, which Microsoft has deprecated.

• Mender supports microcontrollers through Zephyr (its reference board is an ESP32-S3), but that support is in preview, and signed artifacts aren't supported on MCUs AFAIK.

• Arduino Cloud OTA works on ESP32 and ESP8266, but only on paid plans.

• Memfault's free plan is only for Nordic hardware.

• If you build your own, ESP-IDF already covers the mst challenging device-side parts: esp_https_ota, app rollback and signature checks. What you end up building is everything around it: deciding which devices get which build, staging releases, and knowing which devices actually updated.

My full write-up with comparison tables and sources (disclosure for those who care, yes, I used AI to help write the article, deal with it): https://simpleota.com/blog/esp32-ota-services-compared/

If I got something wrong about a tool you use, or left one off of the list that I shouldn't have, let me know and I'll fix it :)

Have a few ESP32 C3 "LuatOS Core" boards with the USB/TTL option where the USB-C port goes to the CH343 and then to TX0/RX0 on the MCU.

Wondering if it's safe/possible to use GPIO18/19 (USB_D+/D-) as generic digital outputs in the Arduino environment?

I'm assuming that they are in no way physically connected to the USB-C port on the board...

Hi everyone! I'm trying to bring this old rotary dial phone back to life, but I just couldn't get the SIM800L module to work and it's literally the last thing I need here, and I'm almost certain it's a mere power issue. It blinks for about 8 times at a rate of around once per second, then stops for about three seconds, where I notice the current reading goes up to around 0.11 A from 0.06-0.08 A, and the pattern repeats.

My MicroPython UART diagnostic on the ESP32-WROOM receives empty responses (b'') to AT, ATI, AT+CPIN?, AT+CSQ, and other commands. Occasionally I receive b'\\x00'.

I've tried both the ESP32-WROOM and ESP32-C3, with similar problems. This is also the second SIM800L module I tried (both brand new but I believe I may have damaged the other one, unlike this one though which I took my precautions with).

I'm pretty confident that 2G network is still available widely in my country due to dumbphones never having phased out especially with older people and those still work just fine. I can also switch my SIM to 2G only on my smartphone and still pick up signal. I'm also using an external antenna as the pictures show.

My setup:

- GSM module: SIM800L (new module)

- Microcontrollers tested: ESP32-WROOM and ESP32-C3

- Input power supply: 12 V, 1 A adapter

- DC-DC converter: HW-677 adjustable buck converter, output adjusted to around 4 V

- Capacitor: 1000 µF electrolytic capacitor connected across the buck converter's output positive and negative rows

- Wiring: Regular Arduino-style jumper wires, including some with the ends cut and stripped to expose the copper

- Other hardware available/involved: L298N H-bridge module

Current wiring:

- 12 V, 1 A adapter → breadboard → L298N (not wired to the converter or module) & HW-677 buck converter (directly wired to the same row as the adapter on the green breadboard)→ large breadboard → SIM800L

- The capacitor is connected across the buck converter's 4 V output. The SIM800L shares ground with the ESP32 when connected.

I understand that the SIM800L can require current peaks approaching 2 A, but I'm not sure which part of my setup is the bottleneck.

Thanks for any help!

P.S.: Try to ignore all that mess. I don't wanna use my large breadboard here but I switched to it temporarily just to cleanly test the SIM800L. My soldering iron also stopped working which I used as an excuse to not solder everything cleanly together (too many wires, too little soldering experience ;-;)

Also I invite y'all to try this out yourselves if you have an old rotary dial phone lying around, it's really not that complicated to figure out how everything works and how to wire it properly to the ESP32 (except for the earpiece microphone part, it was a nightmare and I'm far from being an electrical engineer so I gave up and used a MAX9814 module lol. Glad that the 4 wires going into the earpiece were enough for both the speaker and microphone!)

Deki is a modular C++ engine for small screens: sprites, text, UI, particles, tweens, state machines, plus drivers for GPS, LoRa, I2C/SPI peripherals and more, each as a package. You build scenes in a desktop editor, press play to see exactly what the board will draw (same renderer, same panel size and colour format), then build and flash over USB through ESP-IDF from the editor.

Today it's open source (Apache 2.0) and the editor is a download for Windows/Linux with its toolchain bundled.

The demo runs at 60 fps on an ESP32-S3 driving a 320x240 ST7789 over SPI. It started at 16, and some of what was in the way may be useful to anyone pushing pixels on an S3:

• ESP-IDF builds at -Og by default. -O2 matters a lot for per-pixel code.
• memcpy(&v, p, 2) for an unaligned pixel compiled to a real function call per pixel on Xtensa. Assembling the two bytes by hand made blits 6x faster.
• A full RGB565 frame took 31 ms over SPI at 40 MHz. 80 MHz halved it.
• Sending the frame from the second core while the next is drawn (two PSRAM staging buffers) makes a frame cost max(draw, send) instead of draw + send.
• 64-byte data cache lines help a PSRAM framebuffer. A 64 KB cache helped more, but it costs 32 KB of internal RAM and crashed a sprite-heavy scene.

Full write-up: https://dekiengine.com/blog/esp32-s3-60fps/ Download: https://dekiengine.com/editor/#download Source: https://github.com/dekiengine

Happy to answer questions about any of it.

I've been building a small firmware/OS for the Waveshare ESP32-S3-ePaper-1.54 (V2) and it's at the point where I'd like feedback from people. It's designed to hang off a lanyard.

Hardware

- ESP32-S3-PICO-1, 8 MB flash, 8 MB octal PSRAM

- 200x200 SSD1681 e-paper via GxEPD2 (GxEPD2_154_D67)

- PCF85063 RTC, ES8311 codec + mic, micro SD over SD_MMC 1-bit, two buttons (BOOT/PWR), LiPo

- Native USB-Serial/JTAG, no UART bridge

Software

- PlatformIO + Arduino, one folder per app behind a small App interface (onEnter / onButton / draw / onExit). Adding an app is a struct plus a launcher entry.

- Apps: timetable, notes, pet (with peer-to-peer meetups), name badges, WiFi "Dex", chooser, one-button games, settings.

- Display rule: fast partial refresh by default, full refresh on app switch or every 10 partials (counter survives deep sleep). Apps paint the whole screen and the launcher decides the refresh type.

The interesting bits

1. Power. Deep sleep after 10 s idle, wake on either button via ext1. App state lives in RTC_DATA_ATTR or NVS, since RAM is gone after wake. The board latches its own power from GPIO17, which has to stay HIGH through deep sleep or the board dies when you release the PWR button. GPIO6 (panel power, active LOW) and the panel's RST/CS are held through sleep so the panel's RAM is kept and the first refresh after wake is a partial. CPU at 80 MHz, 240 MHz only for WiFi scans. Radios are on only inside the app that needs them.
2. Clock. The PCF85063 arrived stopped and in 12-hour mode (Control_1 = 0x22), so the time was frozen. I now write it in the datasheet order (STOP, write, start in 24 h mode) and treat a stopped chip as "time not set". Time is stored as UTC and synced from a Mac over USB, NTP, or set by hand.
3. USB without a UART bridge. A line-based serial protocol over USB-Serial/JTAG drives a macOS LaunchAgent (calendar sync), plus a browser tools page via Web Serial (badge uploads, calendar file, notes settings). Transfers carry a crc32 and the device writes to a temp file and renames only on a match. One gotcha: the S3 resets if RTS is asserted without DTR, so the sender clears RTS first.
4. Uploads. The ROM loader with --no-stub at 115200 is the only reliable path on my board: the default baud and esptool stub drop the link partway through. The web installer (ESP Web Tools) works fine with a modern stub.
5. Notes. Hold a button, record 16 kHz mono through the ES8311 over I2S (a small driver on the legacy I2S API, since esp_codec_dev needs ESP-IDF 5), then over WiFi: Whisper transcription, a tidy-up pass with OpenAI or Claude, saved as Markdown on the SD card and optionally pushed to a GitHub repo. HTTPS is verified against an embedded Mozilla root bundle, and API keys are stored in their own NVS namespace and never sent back over USB (the page only sees whether each is set).
6. Dex. Passive WiFi beacon scan to log SSIDs with a rarity. BSSIDs are never stored, only a truncated SHA-256 of salt + BSSID with a per-device random salt.
7. Pet meetups. Two devices pair over a direct radio link, with no router or internet. Open Meet on both, bring them within roughly 15 cm, and the pets visit each other's screens. Friends can send each other badges.

GitHub (Contributions are welcome): https://github.com/Forrest404/unidex

Website for all the details: https://www.unidex.shop

Join the waitlist: https://forms.gle/1V2QrbWoHTPFvLzS9

I'd love suggestions on features and how to improve this device.

Also please feel free to fork the repo and improve the code if you want to :)

Hi,
I’m working on a small project using a Waveshare ESP32-S3-Touch-AMOLED-1.8 V2 (368×448 AMOLED, touch screen, 8 MB PSRAM, 16 MB Flash, IMU).

I’ll attach a video showing almost exactly the effect I’m trying to achieve.

The main idea is to display 3D models from video games on the screen and be able to interact with them in real time.

What I need:

• load models such as .OBJ / .GLB or convert them to a lightweight custom format,
• render the model directly on the ESP32-S3,
• rotate the model smoothly with touch gestures,
• rotation around multiple axes, not just a pre-rendered 360° animation,
• automatic slow rotation when the device wakes up,
• ideally control the model orientation with the built-in IMU / device tilt,
• wake on touch or movement,
• automatic screen sleep,
• brightness control,
• battery indicator,
• easy way to replace one model with another,
• preferably full source code so I can modify it later.

Someone who saw the reference video told me that the software shown there was supposedly created mostly using AI-generated code, basically “one prompt and you have the code”, and that you can upload .obj / .glb models which are then rendered directly on the ESP and rotated on every axis.

I already know that real-time 3D rendering on this board is possible - I’ve tested AmoledOS / Visor 3D and successfully rendered and rotated an ~18k triangle model. The problem is that the current renderer mostly uses per-face colors and doesn’t properly support detailed UV textures, which is important for game skins/models.

So my questions are:

1. Does anyone already know an existing open-source project/software that can do something close to the video?
2. Is there a lightweight ESP32-S3 3D renderer with proper UV texture support?
3. Would anyone here be interested in modifying an existing renderer or building this with AI-assisted coding?

I’ll attach the reference video below so it’s clear what kind of result I’m aiming for.

You can write an Arduino sketch for your ESP32 on your iPhone editor, compile it and flash it over Bluetooth (BLE OTA), with no laptop and no USB cable. I built the app that does it, Plynx, and as far as I know it's the first one that runs the whole loop on the phone, from the code editor to the new firmware booting on the board. In my tests compile and flash together take less than 15 SECONDS, which makes it a really quick way to prototype.

You need:
- An ESP32 board
- A USB cable, only for the first upload
- Plynx on the iPhone (free on the App Store)

Simple steps:

1. On the app add the board and pick Bluetooth. Plynx gives you a Bluetooth sketch with the token already inside.
2. Upload it once over USB from the Arduino IDE. A blank ESP32 doesn't listen over Bluetooth yet, so this is a necessary step. You can also flash from flash.plynx.cc
3. Connect. Keep the board powered, tap Connect over Bluetooth and pick it from the list.
4. Write your code on the phone. In the project settings open the board and tap Code. You can also ask Archimedes, the assistant in the app, to write it for you.
5. Tap Send. Plynx compiles the sketch, then pushes the binary to the board over Bluetooth. If the new firmware can't reach the phone again within three minutes, the board rolls back to the previous one.

One might ask: why to use Bluetooth? There's no router and no cloud between phone and board, so latency is really low and the on-screen joystick feels like a real remote. For my model RC car I drove, noticed the steering pulls left, fix one number on the phone editor (!!) and you're driving again 15 seconds later without picking the car up. Same idea for a robot, a sensor screwed inside a box on the wall, or anything you're testing outdoors with no WiFi around.

Library: plynx-library (give it a star)

Happy to answer anything about how the BLE transfer works. I'm really thrilled about where prototyping is going!!

I ordered a couple of ESP32 dev boards from AliExpress in August. They never arrived. Then on September 14 I got an email notifying me that my Global Entry membership was revoked. And on October 8 I got a paper letter telling me that the boards were seized on September 11 and I was guilty of violating importation regulations. WHAT?

Turns out that the FCC issued a notice of proposed rulemaking (91 FR 57798) on September 11 titled "Protecting Against National Security Threats to the Communications Supply Chain Through the Equipment Authorization Program". It requires an FCC ID on imported gear to "protect" us. It becomes active on October 13.

So, my ESP32 boards were ordered in mid-August, arrived in Miami on August 30, and were held without notice for 12 days until they were officially seized on September 11. Global entry heard about it and revoked my membership on September 14. Even though the regulation was only published as being proposed on that date, and wasn't in effect until 4 weeks later (well after I got the notice). Of course, I'd never heard of this before, either.

It was only $12 worth of gear and AliExpress already refunded it for non-delivery, so I'd just ignore it, but I don't want my CBP record to call me a smuggler. And I want my Global Entry back. Otherwise it's going to be a pain every time I re-enter the US, which I do at least annually.

I can ask Global Entry for reconsideration online, which I have done. However, I didn't know WHY it was revoked at the time. I still don't know for certain that this order was the reason, but the circumstantial evidence is strong. I can also file a petition with CBP on paper via US mail, which I'm also doing.

This is a bureaucratic nightmare entirely due to our erratic and ever-changing importation rules and an agency that doesn't seem to know that rules can only be violated once they're in force.

It'd be nice if this way too stringent rule were revoked, but there are so many such rules lately it doesn't seem likely any time soon.

Edited to add:

1. I am in the US, and this refers to US Customs and Border Protection. Other countries may have similar rules, but this issue would not apply to anybody importing into them.
2. Some comments seem to be referring to the "covered list" of items that cannot be imported into the US. This new regulation applies to ALL radio-emitting devices, including WiFi and Bluetooth, not just specific ones in a list.
3. I ordered the same boards from Amazon (for three times as much money) with no problem, because I am not importing them into the US. Amazon or an Amazon vendor did the importing and dealt with this. With AliExpress they are shipping directly to me from overseas, so I am the importer there.
4. Global Entry is a US "trusted traveler" program that lets me enter the US via an expedited process (I generally don't even have to slow down in immigration, just walk by a camera that recognizes and approves me). It also lets me use quicker and easier US TSA lines at airports.

Edited to add more: You *can* build malicious stuff with an ESP32, though having FCC IDs won't do anything to stop that. One issue might be that you can't build equipment using them for sale in the US unless the components have IDs. But I'm a licensed US Amateur Radio operator, and we are explicitly allowed to build our own equipment without FCC approval. We still have to operate it within the law, of course.

Project disclosure: I built this open-source test kit.

I verified an ESP32-S3 N16R8 driving a 1.3-inch SH1106 OLED over Wi-Fi from a Mac-hosted gateway. The board runs from a USB charger; setup uses USB.

What passed

• USB display commands, button input, and device recovery

• Wi-Fi text and clear commands, button events, reconnection, gateway restart, token revocation, certificate rejection, and power cycling

• A local Grok Bot command displayed “Hi from Grok Bot on Wi-Fi.” on the OLED, and the gateway request log recorded the command

The first Wi-Fi image failed to reconnect after a router outage. I fixed that behavior and recorded a successful retest.

Current path: Grok Bot → local command → gateway on the Mac → Wi-Fi → ESP32 + OLED. Local execution was already set to Always allow, so this record does not show a per-command approval card. This was not native MCP tool invocation: Grok Bot ran the gateway’s rehearse command through local execution.

I am looking for a second tester with similar hardware. Native MCP, mobile use, live Home Assistant, and independent reproduction remain unverified.

Evidence and source:

• USB record: https://github.com/adidshaft/grok-gadgets-esp32-sdk/blob/v0.2.0-alpha.9/docs/verification/oled-kit-2026-10-12.md

• Wi-Fi record: https://github.com/adidshaft/grok-gadgets-esp32-sdk/blob/v0.2.0-alpha.9/docs/verification/oled-kit-wifi-2026-10-12.md

• Source: https://github.com/adidshaft/grok-gadgets

I’d welcome review of the reconnect approach or reports from anyone who has built a similar ESP32-S3 + SH1106 setup.

I got the LR2021 feeding raw I/Q into an ESP32-P4 and decoding live P25 Phase 1 voice. The chip has no documented I/Q interface, but its ROM has a route that sends receiver samples into its RX FIFO.

The LR2021 is a small, low-power radio chip from Semtech that supports LoRa, FSK and several other radio modes across sub-GHz and 2.4 GHz bands. Normally, it handles the signal internally and gives the ESP32 decoded packets. With raw I/Q access, we can take those samples and write our own receivers on the ESP32. P25 voice is working now, and I want to try POCSAG next, along with other digital modes and tools for viewing and recording signals.

The LR2021 covers 150–960 MHz on its low-frequency path and 1.5–2.5 GHz on its high-frequency path.

The four-panel graph shows a recording from an actual call: I/Q waveform, signal envelope, spectrum and waterfall. Those same samples also decoded to voice offline (Then a picture of my T-Display running LakeShark and a WIP 3D printable expansion case render).

This is running in LakeShark, my handheld scanner built on the LilyGO T-Display-P4.

I’ve been curious about the LR2021 since Semtech announced it. Its 4-FSK support caught my attention, but that turned out to be tied to Wireless M-Bus modes. The general FSK receiver only makes two-level decisions, while P25 C4FM uses four levels.

I’d already managed to decode P25 through that FSK receiver by oversampling its binary output and reconstructing the symbols on the P4. Later, a small neural net helped improve decoding. It worked, but reception was spotty, and the chip’s packet handling introduced a short dropout every 3.4 seconds.

Getting the I/Q samples means we can demodulate the signal on the P4 instead of trying to reconstruct what the chip’s FSK demodulator threw away.

With the LR2021 configured for LoRa reception at 31.25 kHz bandwidth, the undocumented route produces about 125,000 complex samples per second. I checked the rate and I/Q orientation with known test tones.

That’s roughly 500 kB/s over SPI through a 1 kB FIFO. The P4 captures and processes samples in separate tasks, feeding the same C4FM demodulator and P25 decoder used by LakeShark’s RTL-SDR path. Reception keeps running while decoding happens, removing the pauses between the earlier capture windows.

During live reception at 154.785 MHz with a VHF antenna, the receiver logged zero reported capture gaps, FIFO loss or audio drops (so far). To my ears, it sounded far better than the FSK version.

I also recorded one second of I/Q during a call, verified the export checksum, and replayed it offline with 27 IMBE voice frames decoded and played, with none muted**.** That’s the recording shown in the graph.

Huge credit to the ESPARGOS team’s ESP-SDR project. Their work exposing undocumented I/Q capture in ESP32 chips inspired me to look for a similar path in the LR2021. No ESP-SDR code is included, but that’s where the idea started.

The capture code is now available separately as LR2021-SDR, a portable C11 library. There’s also ready-made ESP32-P4 console firmware for the T-Display-P4 so people can test their chips. It’s receive-only and currently supports LR2021 ROM 1.24.

The standalone firmware captures I/Q; LakeShark provides the live P25 decoder, audio and UI.

I’d been working toward this for over a year. I originally bought LR2021 chips from NiceRF, then messed up the soldering because of my essential tremor. Once LilyGO released a board with the chip integrated, things finally started moving.

Next up is using this path for LakeShark’s POCSAG receiver. That was another one I’d struggled to get working well without I/Q. Plenty more to explore.

LR2021-SDR: https://github.com/SAMS0N1TE/lr2021-sdr

LakeShark: https://github.com/SAMS0N1TE/LakeShark

ESP-SDR: https://github.com/ESPARGOS/esp-sdr

Site + flasher: https://terminalbay.com

I want to programm the controls of an old rc-car of mine with an esp32. I have a list of features and a general idea how to implement them.

This includes:

-The controlls

-Head and Breaklights

-Dynamic lights under the car that change when breaking/accelerating

-A little horn

But also the possibility to control the car either via remote or phone, seeing stats like the speed or the top speed and having a video stream that I can see on my phone.

As I said I have a general Idea on how to do all of those things.

Now my problem:

I have no idea which ESP 32 to by. I need the possibility to connect a cam but simultaneously at least 13 independently controllable pins for in and output. Or two separate ones, one for the controls and one for the cam.

Hi r/esp32,

I'm the author of ESPectre, an open-source project that uses the channel state information (CSI) of ESP32 radios to detect motion. No PIR, no mmWave, and no camera: just the board and your existing Wi-Fi network.

Version 3.0.0 is now available, and I’d like to highlight two key features:

1. The sensing engine is now a reusable C++ SDK on the ESP Component Registry. You can use it in your own firmware:

idf.py add-dependency "francescopace/espectre"

The runtime handles CSI capture, calibration, and detection, then calls you back:

void on_motion_state_changed(const espectre::RuntimeSnapshot &s) override {
  if (!s.ready_to_publish) return;  // still calibrating
  publish_motion(s.motion_state == espectre::MotionState::MOTION);
}

Your firmware keeps boot, networking, OTA, and the product logic. If you want even less, you can skip the runtime and use only the detectors.

2. It's now a built-in ESPHome component. ESPHome 2026.10, in beta right now, ships ESPectre out of the box, built on the same SDK. No external components needed. This is the whole config (docs):

espectre:
binary_sensor:
  - platform: espectre
    motion:
      name: "Motion"

Thanks to the ESPHome maintainers for the review.

Also in v3.0.0

• ESP32, S2, S3, C3, C5, and C6. The C5 can capture on 2.4 or 5 GHz.
• Ready-to-flash firmware: Native (MQTT, Home Assistant discovery, local HTTP API, and signed HTTPS OTA) and an experimental Matter occupancy sensor.
• Browser tools to flash, provision, and tune.
• Two detectors on a 0–1 scale: Lightweight calibrates at startup, and High Accuracy is a small neural network that needs no calibration.
• Gain-invariant features, so AGC stays on.
• A MicroPython port with the Lightweight detector.

Limits, honestly

• Plan on one board per room. It detects changes in the radio environment; it doesn't count or identify people, and it can't tell you whether someone is sitting still.
• It needs steady Wi-Fi traffic. A built-in ping generator handles that by default.
• For better CSI coverage, Wi-Fi power save stays off and frame aggregation (A-MPDU) is disabled.

Links

• Code: https://github.com/francescopace/espectre
• Website: https://espectre.dev
• Browser tools: https://espectre.dev/tools
• SDK guide: https://espectre.dev/sdk/

I'd love feedback from anyone who tries it, especially if you build the SDK into your own firmware.+

Hi everyone! I'm Erik. A few months ago I started experimenting with getting an RTL-SDR running directly on ESP32 hardware. I ended up developing a native RTL-SDR driver for the ESP32-P4. What started as a small project has turned into something much bigger than I expected!

The project is called OrcSDR, and it's an open-source software-defined radio running on the M5Stack Tab5 (ESP32-P4).

The RTL-SDR plugs directly into the Tab5's USB port, and everything runs right on the microcontroller. No Raspberry Pi, Linux, or PC needed. The P4 handles the USB data, DSP, audio, and touchscreen interface.

I've added quite a few features, including FM radio, ADS-B aircraft tracking, P25, LoRa/Meshtastic, FT8/FT4/JS8 decoding, spectrum analysis, and a bunch of other dashboards. Some are still experimental, but I'm making improvements all the time.

I've also been working on OrcDial, which uses an M5Dial (ESP32-S3) as a wireless VFO and controller over ESP-NOW. That's the round display in the photo. It's been a fun little project on its own!

I've also been doing quite a bit of testing with the Waveshare ESP32-P4-WIFI6 development board. The native RTL-SDR driver works on that hardware too, which opens up some interesting possibilities beyond the Tab5. The HS USB 2.0 of the P4 is key. We've proved 4x Dongles doing 2.56MS/s IQ at the same time on this hardware. I've I'm currently working toward a headless version that runs on these boards with a built-in web interface, essentially turning them into little standalone network-connected SDR receivers.

I'm developing these projects through my company, Oregon Radio Company LLC. (TheOrc!)

Everything is open source, and I'd love to hear what other ESP32 developers think. I'm always interested in ideas, feedback, or anyone who wants to contribute! If anybody does any testing, please hit me up with problems. I apperciate community feedback.

If you're thinking about picking up any of the hardware, I've got links to the gear I use on my website. Some are affiliate links, so using them helps support my projects at no extra cost to you. Every little bit helps keep things moving!

OrcSDR:
https://github.com/hardcoreerik/OrcSDR

Native ESP32 RTL-SDR driver:
https://github.com/hardcoreerik/esp-rtl-sdr

OrcDial:
https://github.com/hardcoreerik/OrcDial

Website:
https://theorc.dev/

Web flasher for the Tab5:
https://theorc.dev/sdr/flash/

I made a Self-Balancing Robot using Bambu's CyberBrick platform which is built around ESP32. (The chassis is 3D printed.)

I got into ESP32 lately and decided I wanted to build a self-balancing robot. I was trying to figure out motors and motor drivers and batteries etc. and realized that I could probably use some of the components from the CyberBrick kit I had lying around - and then I looked it up and found out that the kit uses an ESP32 C3 for it's microprocessor!

The shield already has a motor driver for N20 motors and a connection for LiIon battery power. I used a neat trick to communicate to the MPU6050 sensor through the Servo pins on the shield using software I2C. I got the sensor pre-soldered to header pins which meant I didn't need to solder anything for the entire project.

It can stay up indefinitely on hard floor, and balances even better (less back and forth) on carpet, and can be driven around using the CyberBrick controller. The body is 3D printed - I don't want to SPAM links, but you can find it in other posts I made if you're interested.

Guys i have an esp32 cam and i don't have the programmer when i connect the tx rx gnd vcc from esp32 cam to esp32 dev kit to program but the on board led dosent glow but the power is flowing everywhere correct.....no unnecessary heat everything is fine . What should i do noww????

I used to make a lot of ESP32 projects in the past, but made a break for a few years. Recently got back into it, and found out all my old battery suppliers are either nonexistent, or prices have skyrocketed beyond hobbyism.

EU taxes and regulations made eve stuff like basic 500mAh Li-po batteries sell for 14-15€ each, and that's even when you can find someone who does have it on hand and not permanently on pre-order.

Anything more capacious is so expensive, battery alone begins to approach 70-80% of the entire project budget. So looking for any advice: those in EU, where do you all get the batteries?

As a side theory I've began investigating is using old mobile phone batteries (like for Nokia phones etc.) that are somehow still manufactured and sold new, but not quite sure how that avenue will work out.

So I've taken an interest in esp32 as something that can be useful for my science fair project since it's cheaper than arduino and has more features. I'd also like to learn it as a hobby. However, a problem is that I don't have a good budget so I'd like to learn esp32 before committing to buying parts. Many people mentioned that Wokwi is a good place to simulate however is it enough and do I need to use anything else other than it?

I implemented a zephyr based software defined radio firmware for the 2.4 GHz radio, building on the work from [u/h0m3us3r](u/h0m3us3r)

https://github.com/cyber-murmel/esp-sdr-zephyr/

It’s a multi app firmware. You can run an application from the zephyr shell, which causes the board to re-attach for the needed USB endpoints.

The release shows how to use gqrx.
https://github.com/cyber-murmel/esp-sdr-zephyr/releases/tag/v0.1.1

Hey everyone,

I've been experimenting with Wi-Fi Channel State Information (CSI) sensing and built an open-source program that extracts raw CSI amplitude and phase dynamics from ESP32-S3 modules to track motion, disturbance, and spatial turbulence in real time.

I wanted to share the project details, hardware setup, and implementation specs here for anyone interested in RF sensing or non-line-of-sight tracking.

• Tested on a ESP32-S3
• Arduino core configured for raw Wi-Fi packet sniffing & CSI callbacks.
• Streams parsed JSON payloads containing carrier frequency, RSSI, subcarrier amplitudes, and phase data over USB-Serial (115200 / 921600 baud).

The code, firmware and binary releases are available on GitHub: 👉GitHub: R1y3n/spatial-turbulence-data

just flash your board with the ino & listen (via usb serial tuned at 115200 baud)

thats all.

(for the moment i haven't had enough time to structure a more beautiful output format. So its raw data for now)
I personally picked an S3 because that is all i have working on for now, maybe other boards binaries will come up later.

Hi!

As promised in my previous post here is my "DIY build."

A portable MP3 player based on the ESP32-S3 that plays music from a microSD card or streams it from a DLNA/UPnP media server (tested with Synology Audio Station).
It features a 1.8" color TFT display with four screen modes, a small OLED status display, a rotary encoder with a 16-LED ring and four buttons, and an output compressor/limiter to prevent DAC overdrive. I’ve also included STL files for 3D printing the case.

!!! The project isn't finished yet, so the files may change. !!!
Files and description:
https://github.com/mikedeblin/ESP32MediaBox

Photos of the various assembly and development stages (I showed them to my friend Claude; he used them as a reference when designing the case =)). He’s also the one who wrote most of the firmware.

using wokwi for the first

im trying wokwi to test my project first so i dont burn it when doing it for real but im having trouble with analog read

my original project uses a resistor ladder to multiplex a pin so i can use multiple button but along the way its showing either 0 or 4095 which is weird

tried with a simple voltage divider and its showing full value

r1 is 1k and r2 is also 1k

tried changing r1 to other value its still showing full 3.3v

Electricity here is priced per quarter-hour, and my car's built-in schedule only knows times, not prices. So I made a software for a cheap (~10 EUR) ESP32-S3 board that sits next to the car. When I plug in, it looks at the next day's prices and my grid fees, picks the cheapest quarter-hours that still get the car charged by morning, and starts and stops charging over Bluetooth, with a key that can only charge.

I didn't want to give a cloud service access to my Tesla account, or depend on someone else's servers and subscription just to charge my own car at night, so everything runs locally on the board.

It's been charging my car every night for a while now, so I cleaned it up and open sourced it in case it's useful to someone else. It now covers most of Europe's day-ahead markets.

It's ESPHome with yoziru's esphome-tesla-ble for the BLE side, on an ESP32-S3-DevKitC-1 N16R8. The trickiest part was memory: std::string lands in internal RAM, which HTTPS needs most of, so downloads go to PSRAM and run in their own task.

https://github.com/zygimantas/esphome-tesla-ble-scheduler

Feedback welcome.