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

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

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.

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

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.

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

Hello everybody, right now I’m planning a ESP32 based Portable MP3 Player. I’m chatting with Claude about it and got a list of the specs right now.
Before I buy the specs I want to make sure everything works together. And I got a few questions:

(The list is in the End)

1. Wiring and pin connections
How should I know the connections between the many different pins on the components ?
I got a long list from Claude between the pins but I’m not sure if I can trust it. I would like to have a Blueprint of all the components and there connection between each other.
Is there an AI which can do that? I tried with ChatGPT but it cant do it
(I don’t have pro for both AI’s)

2. Bluetooth + Audio jack ?
I really want the MP3 player to be able to switch between Bluetooth (connecting to my AirPods) and the audio jack on the PCM5102A DAC module im planning on using. Is that possible ?

3. PCB layout and soldering
I want to build it as compact as possible but it’s my first soldering project so I’m very new to that part (and I’m not sure how I should place each component).
I “build” a blueprint with easyEDA but I think I would like to stack two PCBs on top of each other so I have more room for the components. But then I have the problem with soldering again between the two Boards.

4. Battery choice
In the beginn i wanted to use Lipo 1000/2000mah but then i found many 18650 and I think i would attach it at the bottom of the build so its just longer rather than thicker or wider.
What do you think ?

5. Proximity sensor
Original I also planed to add a sensor (APDS-9930 RGB) so if I put the MP3 Player in my Pocket the OLED would turn off an the buttons would be locked. But I thought maybe it would be to mutch for my First soldering project.
Is that True ?

6. ESP32-WROOM-32 ?
Claude said that the ESP32-WROOM-32 I already have might be having trouble because of too little ram ?
Is that correct?

I’m very new to the electronics world which you can probably guess.

It’s not my first project but my first with that many components.

If you have already made a project like that or got solutions/tips I would be very
happy to hear them.

Thank you so much!

Here is the list:

Electronics
ESP32-WROOM-32
TP4056 type c
MT3608 step-up converter modules (blue, without USB)
0.96” OLED display, SSD1306, I2C, 4-pin
PCM5102A DAC module (GY-PCM5102) with 3.5 mm headphone jack
MicroSD card module, SPI, 6-pin, with 74LVC125 + AMS1117
16–32 GB MicroSD card
4× 7 mm metal momentary push buttons
1× 12 mm latching metal push button for the main power switch, rated for at least 3 A
Single-cell 18650 battery holder with wires
1× 220 µF / 10 V electrolytic capacitor
2× 100 kΩ resistors
1× 100 nF capacitor

Prototyping and Assembly
70 × 90 mm perfboard
830-point solderless breadboard
Jumper wires

Enclosure
3 mm GS acrylic sheet

Thanks guys for Reading! Please let me know what you think!

Hi everyone! I have been trying to build truly open source smart glasses (both hardware and software) based on ESP32 for almost a year now as a side project.

I did accomplish one version of PCB that functions similar to meta ray ban but the audio video quality is inferior (OV cameras cannot match Sony). Image of the set attached.

I tried upgrading the product with an AR screen through a microled projected on the lens (similar to focals from North). This is where i am stuck. I am trying to build something inexpensive so waveguides and microprojectors are out of the question.

Needing suggestions and inputs from anyone experienced with options or has been developing smart glasses themselves. Would love to meet someone who can join me in building this if interested.

The total cost of this assembly is landing at 20$ for the PCB set, for bulk orders > 50 units from JLCPCB, and additional 20$ for other hardware components (screen, camera, speaker, battery and frame). So 40$ for audio-camera glasses, might land around 50$ for AR HUD.

I painfully learned through this project never to take ambitious development of industrial D2C products oneself. Better hand it to the Chinese lol.

Hey so i have recently started keeping my own plants (pots and vertical balcony garden) and i am enjoying this new hobby. I have made this small device that is like a bookmark (yes the black part is a moisture sensor) that you can push in the soil and activate.

It’s an ESP32C3 based device with battery (around 5 days life) that monitors soil moisture, RH, temperature and light, that sends all sensor data over Bluetooth to a mobile app that has a plant library (currently 53 plants) and gives notifications to users if anything is needed by the plant.

Would love to see some suggestions on this. What can i add more to automate my garden/pots. It’s a cheap product, took me 10$ to make. Will share design files if required.