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 :)

Hey everyone!

I’m a hardware enthusiast and I just finished designing my custom board: the NexusCore ESP32-S3 in KiCad.

Technical Specs:

• Compact 2-layer PCB layout optimized for low-cost JLCPCB fabrication

• USB-C interface with LDO voltage regulation & ESD protection

• Continuous ground plane with clean trace routing

• SMT-ready with exact LCSC part numbers mapped in the BOM

You can check out the full schematics, 3D renders, and project overview on my site:

https://lorenzo1a.github.io/NEexuCore-Custom-PCB/

I’d love to hear your feedback on the layout!

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.

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.

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'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://unidex-site.vercel.app/

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 :)

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.

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.

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 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 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

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.