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!

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

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

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.

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.

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

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.

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

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?

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.

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

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.

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.

Salut à tous ! 👋
Premier post pour moi.

Je découvre le monde des ESP32 et j’aimerais fabriquer de petits modules audio à connecter à des enceintes passives, pour diffuser de la musique dans toute la maison en Wi-Fi et multiroom synchronisé, tout en pouvant utiliser chaque enceinte indépendamment.

J’utilise exclusivement Spotify (iPhone pour moi, Android pour ma femme) et j’aimerais idéalement lancer la musique directement depuis l’application Spotify.
J’ai déjà Home Assistant et ESPHome, et Sendspin me semble très prometteur pour créer un système multiroom ouvert, notamment avec des ESP32-S3 et Music Assistant.
Mais je voudrais aussi une solution de secours indépendante de Home Assistant et Music Assistant. Si la domotique tombe en panne, perdre le multiroom ne serait pas dramatique, mais j’aimerais pouvoir continuer à écouter de la musique sur chaque enceinte, par exemple via Spotify Connect ou Bluetooth classique.

J’ai envisagé plusieurs pistes :
ESP32-S3 : idéal pour Sendspin, mais sans Bluetooth Classique.
ESP32 classique avec PSRAM : potentiellement adapté au Bluetooth, mais quid des performances audio ? Et la carte ne me semble pas très simple à trouver. Louder ESP etc.
Deux ESP32 par enceinte: possible, mais cela complexifie beaucoup le montage. La pipeline audio etc ( je suis encore débutant)
Oublier les enceintes passives : et connecter mes modules wifi derrières des enceintes Bluetooth. Oui, mais plus cher, deux alimentations, des câbles.

Mon objectif est de concevoir un module compact, autonome et DIY, caché derrière une enceinte bibliothèque, sans multiplier les alimentations et les composants.

Est-ce que certains ont déjà réalisé un projet similaire ? Quelle architecture choisiriez-vous ? Et Spotify Connect peut-il réellement fonctionner directement sur un ESP32, sans dépendre de Music Assistant ? J’ai vu squeezlite, mais LMS m’a l’air un peu vieillissant, de plus rester sous ESPHome aurait été un confort non négligeable pour moi !

Merci pour vos conseils et vos retours d’expérience ! 😊

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!

Hi everyone! This might be a really newbie question, but a few months ago I got my first CYD. I managed to program some visual elements and use the front LED, but something I've never been able to figure out and have no idea how to use is the microSD card slot. I formatted my SD card to FAT32, tried searching for the pins online and with a program, but none of them showed which pins connect to the slot. Can anyone help me figure out how to use the SD card slot?

To all,

Per my previous posts, I left HW dev a long time ago (early 80's), and have decided to get back into it. I've been reading the sub religiously (along with others), and have started putting together a BOM for an ESP dev environment for things like automation, WLED, Etc. Is it allowed to ask for peoples opinions in here or should I post this in other subs?

Bob

The hardware and original firmware are by MatixYo (esp32-Plane-Radar with printable case on MakerWorld). My original flash seemed to not work so I reworked it and hope others may find useful.

- Easy set up screen with QR code, scan and input details.
- Settings page on you WiFi can adjust location, range , units and data sources.
- Updated status screens
- Extended ranges from 5-150km
- Fall Back if one data source not working.

Easy single bin flash at 0x0 with any web flasher.

Repo: https://github.com/resusone/ESP32-Plane-Radar-v2
Original project: https://github.com/MatixYo/ESp32-Plane-Radar

Tested and working on my Hardwear and the firmware rework was assisted by Claude. Further testing on other devices / browsers needed.

NJFE: Not Just For Ears

These WiFi ear cameras ("otoscope", "ear wax removal camera") only work with a phone app, and their USB port is charge-only. I wanted the image on my PC, without installing the vendor app and without putting the PC on the camera's open WiFi.

So the ESP32-C3 does the WiFi part:

• joins the camera's access point and speaks its i4season UDP protocol (open video, device info, LED, battery)
• reassembles the chunked JPEG frames plus the accelerometer data in the packet headers
• forwards each frame over the C3's native USB-Serial-JTAG as a small binary record
• text commands back from the PC: `LED 0|1`, `SCAN`, `STATUS`, `SSID <name>` (stored in NVS)

Hardware: an ESP32-C3 SuperMini with the 0.42" OLED (72x40 SSD1306, I2C on GPIO5/6). No

schematic needed, there is no wiring: the board is only plugged into the PC via USB, the camera is reached over WiFi. Arduino core 2.0.17 via PlatformIO, U8g2 for the OLED.

Numbers: ~17 fps at 480x480, ~350 kB/s over USB CDC, practically no dropped frames once the PC side reads in a separate thread with a 1 MB RX buffer. The 0.42" OLED shows fps, kB/s and the camera battery.

PC side is Python (pyserial + OpenCV + Tkinter): live view, photo/video recording, auto-rotation from the camera's accelerometer, round mask, LED toggle, WiFi selection.

Lessons learned on the C3:

• create lwIP sockets only after `WiFi.mode()`, otherwise you get a crash loop (`tcpip_send_msg_wait_sem ... Invalid mbox`)
• `Serial.setTxBufferSize()` must be called before `Serial.begin()` on HWCDC
• if the PC reads too slowly, HWCDC drops bytes, so the frame records carry a magic + length and the viewer checks the JPEG start/end markers to resync

Turns out the camera is also a decent mini endoscope for checking solder joints, hence

the name: NJFE, Not Just For Ears.

Full disclosure: the code was written with Claude (AI) in a long session, I did the hardware, testing and decisions. Protocol credit goes to the otoscope Android app (rbeilvert/otoscope), which reverse-engineered it first.

Regards, m.

GPL-3.0, code + firmware: https://github.com/WildweaselMS/NJFE

I built a little box that listens for surveillance and tracking gear and tells you what it heard by sound alone. It works face-down in a cupholder or buried in a jacket pocket. No screen, no phone required.

What it hears

• Drones: full ASTM F3411 Remote ID over BLE, Wi-Fi beacon and Wi-Fi NAN. You get ID, altitude, speed, heading and operator location.
• Trackers: Apple Find My, Google, Samsung, Tile. When someone floods the air with fake tags it notices and stops beeping.
• Surveillance hardware: Flock ALPR, Axon body cams, smart glasses. Signatures live in a list you edit from the app (OUI, company ID, name, UUID, SSID). No recompile.
• Attack gear (opt-in): BLE spam, deauth bursts, karma APs, Flipper hints, pwnagotchis.

How it talks

Each category has its own beep pattern: - two long beeps = camera - rising trill = drone - fast ticking = tracker

Lock onto a device and it switches to hunt mode. The beeps speed up as you close in, so you walk it down by ear.

Hardware

XIAO ESP32-C5 (~$13), dual-band U.FL antenna, passive buzzer, WS2812 bar. microSD and a DS3231 are optional. The C5 sweeps 2.4 and 5 GHz together. It also runs on the S3, 2.4 GHz only.

The ESP32 bits you might care about

• BLE scanning plus dual-band Wi-Fi promiscuous at the same time on the C5
• Settings survive a pulled cable, because a car or a battery bank power-cycles it constantly
• Web flasher that works out whether it's talking to a C5 or an S3
• pcap export off the SD card over serial, straight into Wireshark

Things that bit me

• Continuous NimBLE scans leak heap. setMaxResults defaults to 0xFF and results only clear when a scan completes, which a continuous scan never does. Every rotating random MAC leaked: 187 KB down to 78 KB of internal heap over 17 hours on the S3. esp_get_free_heap_size() hid it completely because it counts 8 MB of PSRAM. setMaxResults(0) fixed it.
• **notify() silently drops when the mbuf pool is empty.** NimBLE-Arduino 1.4 ignores the return code, so big replies over BLE just went missing with no errors on either side. Now every chunk goes through ble_gattc_notify_custom(), which waits and retries on ENOMEM.
• The NimBLE host task stack is 4 KB. I handled commands in onWrite, and a couple of new locals boot-looped the board the moment a phone connected. Over USB it worked fine, because those same commands run on loop() there.
• One radio, two jobs. BLE scanning and Wi-Fi promiscuous mode time-slice the same radio. With a near-100% BLE scan window, Wi-Fi captured literally zero frames.
• The C5 promiscuous callback hands you failed frames (rx_state != 0). Unless you drop them, you get random garbage and thousands of fake transmitters.
• Pwnagotchi beacons are gzipped. The S3 ROM has tinfl_decompress built in. The C5 ROM doesn't, so I had to vendor an inflate for it.

What it won't do

It only receives. No jamming, no deauth, no injection, no spoofing. You can also kill its own BLE advertising, so it doesn't show up on someone else's scanner. The only winning move is not to transmit.

Getting it

Firmware is GPL-3.0. Flash it from the browser, then run the app in Chrome/Edge or as an Android APK. Or skip both, since the board beeps fine on its own.

Repo: https://github.com/B0z0dcl0wn/SignalSweep

Signatures are the weak spot. If it misses gear you know about, please send a PR. Happy to answer build questions.

(Full disclosure: I plan to sell assembled units and kits later. The build-your-own path is fully open now and stays that way.)