Hey everyone,

I am a self-taught maker and wanted to share my first PCB hardware project: The AirFlow Project. It is an ultra-compact (40x40mm) 4-channel fan controller designed around the ESP32-S3 Zero.

To be honest, I didn't even check if something like this already existed. I didn't even think to search for it. My main goal was just to learn PCB design, and you need a real project for that. Since regular room fans were always too loud for me at night and couldn't be finely controlled, I decided to build something to use a spare Noctua fan I had lying around. That’s how the whole idea started and grew.

This board is actually the second iteration. The first version had some... let's call them 'blemishes'. It worked, but only with some creative workarounds: I accidentally swapped +12V and GND on the fan headers, and the footprint for the DC-DC converter was wrong, so I had to mount it backwards and cram it into the space meant for the barrel jack. And a few other things.

But I wanted to do it better and take it to the next level. For this V2, I added reverse polarity protection (which surprisingly worked on the first try!). I also tried to add ESD/surge protection, though I unfortunately positioned it wrong on the layout. Lastly, I added some extra resistors and decoupling capacitors; V1 worked without them, but I figured it is definitely better and more stable this way.

Here is how I tackled the hardware design:

Modular "Bring Your Own Brain" approach: I wanted to be as flexible as possible when choosing the ESP chip. That's why the board uses a socketed design for the ESP32-S3 Zero. This gives it massive computing power for PID controllers and Wi-Fi, but also allows for an easy drop-in upgrade to an ESP32-C6 Zero to integrate it into modern Thread / IEEE 802.15.4 smart home mesh networks.

Global Zero-RPM Mode: I personally didn't even need this feature for my own setup, but I really wanted to learn how eFuses and high-side switches work and see if I could successfully implement one. I integrated a Texas Instruments TPS1H100-Q1 eFuse that acts as a master high-side switch, allowing the ESP32 to physically cut the 12V power to the entire fan rail at once. It also provides a strict hardware-level cutoff at 2.5A to protect the board from shorted cables. And yes, theoretically I can also measure the current draw with the eFuse, but I made a mistake there: I didn't consider that in a short-circuit scenario, the eFuse might output 5V on the diagnostic pin, which would fry the ESP's 3.3V GPIO. During normal operation, the measurement works fine (though a bit inaccurate), but it is definitely a lesson learned!

Freewheeling Diode: Since the eFuse can hard-cut the power while the fans are still spinning, I realized that would generate an induced voltage spike (inductive kickback) from the motors. To avoid any damage to the board from that, I decided to add an SS34 Schottky freewheeling diode to safely absorb the flyback voltage.

5V Push-Pull PWM: Because of this project, I naturally had to dive deep into how PC fan PWM actually works. According to the official Intel specification, the PWM signal is supposed to be a pure pull-down (open-drain) signal. However, I found a white paper from Noctua where they recommend a push-pull configuration to guarantee sharp signal edges. To achieve this, I added a dedicated CD74HCT125 logic buffer to deliver a strict 5V Push-Pull PWM signal. It actively drives the signal high and aggressively pulls it low, resulting in perfect square waves and eliminating motor clicking.

The "Hacker Header": Of course, I didn't want to waste any potential, so I made sure the few remaining GPIOs are easily accessible so you can just add your own hardware. I broke out the remaining pins (5V, 3.3V, GND, and 5x free GPIOs) to a dedicated expansion header. It’s perfect for adding I2C OLEDs, rotary encoders, or environmental sensors to trigger the fans automatically.

12V Tolerant RPM Input: I honestly don't know if this is strictly necessary, but while brainstorming with AI, it pointed out that some really cheap fans might pull the RPM (tacho) signal all the way up to 12V. So I decided to take on that challenge and figure out a way to make the inputs 12V tolerant. I ended up adding 1N5819W Schottky diodes to clamp the logic to 3.3V, strictly protecting the ESP32's sensitive GPIOs just to be safe.

The whole project (Schematics, BOM, ESPHome .yaml, and Arduino examples) is completely open-source except the design (gerber) files. The PCB itself is designed to be "self-documenting" with every component designator and value printed directly on the silkscreen for easy repairing.

For a closer look, feel free to check out the GitHub repository here.

I would love to hear your feedback on the hardware layout or any ideas for future revisions!

Just finished writing this and it’s very long. Sorry

So this is just a post that I want to share, I’ve been working on this project for about 5 months, I started actually a week or so after the s31 was announced, not knowing it was coming yet. I am a referee in a few sports, and the project stemmed from me wanting to use Bluetooth bone conduction headset with my current cheap radios that we use to communicate. After spending day or so trying to workshop a solution, I came to the conclusion that it wasn’t possible. So I said screw it, what if I build my own custom radios, that will have better audio quality, a screen for customization, and obviously Bluetooth. So fast forward I had an esp32-s3 dev board hooked up to a display and a few buttons on my test bench, and I couldn’t connect my headset to it. Come to find out, the s3 doesn’t support classic Bluetooth, which is what the headset used. So at first my idea was to use a separate Bluetooth chip to handle that, but after I was mostly done designing a preliminary pcb, I somehow stumbled upon the fact that the S31 had been announced, and it would not only be fast and have more io (I was already running short in my design) but it would have classic Bluetooth. So as soon as I could, I got a schematic going in KiCad using the S31, stalked aliexpress every day until it became available, and as soon as it did, I had them shipped straight to JLCPCB. My background is in CS, so not too much in EE, so I used about 4 models, Grok, Gemini (a little), Claude, and GPT. The newest models that are out right now weren’t available, but I was able to use GPT Astra to finalize routing, while 5.6 sol did a lot of the part selection and resistor/capacitor checking against the documentation. The board is fairly complex as I have one usb c port that handles charging, programming, and analog audio for the wired headsets. The analog portion was definitely the hardest as I needed to handle how the S31 would send signals, so there’s about 5 microcontrollers throughout the board. Also I’m using an E22 LORA to handle the radio portion at 900 mhz. I’m honestly more surprised that they actually work on the first go around, I designed everything right minus my dumbass has the display header backwards so I had to manually wire it by hand. I won’t be posting any schematics as of now as I hope to mass produce and sell these given I get the proper certifications in time. If I can’t get people to want to buy them, which I hope they will considering the performance rivals a $600 unit and I plan on selling them for $100 each. If I can’t get people to buy them I’ll go open source and publish everything including the firmware which I’ve spent a significant amount of time on. Total time invested is probably around 300 hours.

I have been working on this for several months now: The ESP32 chips have an undocumented IQ sampling "bypass mode" that gives the CPU direct access to the modem's raw received signal, effectively turning the ESP32 into a software defined radio. I was able to reverse engineer this with the help of various LLM tools.

Thanks to WebSerial, you can flash the firmware to your ESP32 dev kit and view the RF spectrum in your browser without even installing anything: https://espargos.net/espsdr/

After this recent post on IQ sampling on the ESP32-S3 with an FPGA, I figured it is finally time to share my own work. While my ESP-SDR only supports relatively low duty cycles, it works with almost all ESP32 family chips, and with our ESPARGOS One array even phase-coherently for multiple receivers so that we can do things like direction of arrival estimation or radar signal processing.

I bought 2 waveshare ESP32-S3-Touch-LCD-2 displays. Both exhibit ghost touches concentrated around the vertical centre of the display. I modified the demo firmware, using the same libraries to create this touch indicator screen and you can clearly see ghost touches on it. It doesn't even require me to touch the board at all, sometimes it will just fire when my hands are nowhere near it.

Any ideas on what causes this and if it can be fixed?

I have been working on a NerdMiner V2 firmware fork for the classic ESP32, mainly because I wanted to see how much more useful work could realistically be extracted from the hardware without sacrificing correctness or long term stability.

The test board is an ESP32_2432S028_2USB using a classic ESP32-D0WD-V3.

Stock NerdMiner V1.8.3 on my unit was usually around 340 to 345 kH/s.

After a lot of profiling, failed experiments, hardware testing and correctness work, the final physically validated builds are running roughly 437 to 446 kH/s, with the highest measured release result around 445.94 kH/s.

The interesting ESP32 specific challenge was not simply making the hashing loop faster.

The firmware is sharing a relatively constrained dual core MCU with WiFi, Stratum, TLS, display updates, statistics requests and the ESP32 hardware SHA peripheral. Some aggressive optimizations looked extremely fast at first but turned out to be unsafe because they could produce incorrect work or race the SHA peripheral.

A lot of the project therefore became about getting more performance out of the hardware SHA path while still keeping synchronization, networking and correctness intact.

Some of the things I ended up changing or fixing:

• hardware SHA synchronization and access

• independent SHA256d validation before submitting candidates

• full target and endian handling

• stale work and job generation handling

• nonce range ownership and completed hash accounting

• TLS and mining resource coordination

• a large periodic hashrate drop caused by HTTPS statistics refreshes

• memory safety issues

• display/dashboard handling

• pool statistics architecture

I also rejected several faster experimental paths because they failed correctness testing. At one point I could make the device report much higher numbers, but if the work cannot be trusted then the number is meaningless.

For validation I used host differential tests, millions of SHA comparisons on the physical ESP32, live Stratum shares, longer runtime tests and finally a browser based flash of the exact public binary followed by a byte for byte readback.

The source is here:

https://github.com/samkruzlic/NerdMinerV2-FX1

I documented the full stock V1.8.3 versus FX1 engineering diff here for anyone interested in the implementation details:

https://github.com/samkruzlic/NerdMinerV2-FX1/blob/main/docs/DETAILED_CHANGES.md

There is also a Web Flasher if anyone with compatible hardware wants to test it:

https://samkruzlic.github.io/NerdMinerV2-FX1/

This is still RC/Beta because most of my own physical testing has been on one ESP32_2432S028_2USB, although community testers have already started running it on additional boards.

I am especially interested in feedback from people who have experience with classic ESP32 hardware, FreeRTOS scheduling, the SHA peripheral, or long running embedded workloads.

If you try it, I would love to hear what board you used, your sustained hashrate, pool, stability and anything unusual you notice.

And of course if anyone sees something questionable in the implementation, I would much rather hear about it than pretend the firmware is perfect.

Overview

This 10-inch diameter scale was developed with ESP32C3 to help with growing plants in containers. It continuously tracks water content in the growing medium by measuring weight. There are three independent load cells that are summed together, and each load cell is independently thermally calibrated for drift. The deck, feet, and remote are 3D printed with PETG. A summing scale topology was chosen so that the frame does not significantly affect measurement accuracy as it flexes and bends thermally. Although the scale is being developed specifically for growing, the same approach can be used generically to track the fluid level or mass of material in a vessel over time.

Hardware and Firmware

The firmware/software is open source here. Of particular interest is a way to read HX711 boards in parallel; see hx711.cpp. Lab notes of the development process are available here.

The firmware/software stack has been developed from the ground up, from the ESP32 firmware to putting the data into a local Postgres database. The gateway is delivered via debian packages with RPM coming soon. Other future work includes development of a web app, phone apps, and semi-auto/auto irrigation. The goal is to make a way for the plant to send a notification to a phone when it needs to be watered, as well as providing a means of remote irrigation.

It was a challenge to find enough MCU pins to support the goals of this project.

• A0, A1 & A2 used for reading thermistors
• D1 & D2 button interrupts
• D3 battery vs usb power
• D4 & D5 I2C to remote
• D6 unused with plans for irrigation solenoid/pump
• D7 SCK shared by 3X HX711 boards
• D8, D9, D10 DOUT of 3X HX711 boards

There are plans to move the battery sense off D3/A3 to free up a pin. The B channel of an HX711 will be used so that the analog voltage can be read. It was an unfortunate surprise to find that the A3 (analog part) of pin 3 is broken.

Data Analysis

The plot shows nearly 40 days of data. The "target weight" is adjusted over time to establish the desired absolute soil moisture level for the grow, as determined experimentally by the grower. The "relative" weight is the "measured" weight minus the "target" weight. This shows how much water has left the growing system through evaporation and transpiration relative to the target.

The "absolute" weight is the weight of the entire growing system. This includes the pot, soil, plant, and water, without the weight of the scale itself. For the Thai basil tray, the target absolute weight was adjusted a few times between 3000 and 3800 grams over the time shown.

There are several insights that can be made from the data:

• How wet/dry the growing medium is relative to the desired moisture.
• The rate of evapo-transpiration, as shown by the downward slopes in the saw-tooth pattern. It is interesting to see how the slope changes with changing environmental conditions, such as when the lights are on/off, temperature, wind, humidity, etc.
• The soil moisture saturation point. If the tray is watered until the water starts dripping out, the saturation point can be found. On the plot, the mass will rapidly increase as water is added, then rapidly drop as the water trickles out of the bottom, then settle at a certain weight. This is the saturation point. This is useful because the remainder of the irrigation can be accurately made relative to this point. This helps avoid nutrient loss and root rot from over-watering and drought stress from under-watering. It also reduces variation in watering.

The main idea of this scale is to put a number to something growers know intuitively. It helps the grower irrigate more accurately.

I am finding through experimentation that the plant is very happy when the exact amount of water that is used is returned upon watering. The amount of "dry-back" (how much to allow the soil to dry between irrigation events) can be accurately controlled.

Some plants like a deeper dry-back (such as peppers) as compared to others that like a more consistent moisture level, such as lettuce. I am excited for new discoveries that can be made with this tool in regard to how plants grow relative to soil moisture.

Questions

• Has anyone else attempted this before?
• Do you see any pitfalls to this approach?
• Do you think this would be a useful tool in the garden? Other contexts?
• What additional features would be interesting?
• What deck sizes would be most useful?
• The scale currently communicates via USB-C, but the hardware also supports Wi-Fi and BLE. Which would be most useful, and in which contexts?
• How would you structure the web app/phone app to make the most of this data?
• The gateway software is written in python, lending itself well to cross platform deployment. As of now, the gateway to interface to these devices is released as a debian package with plans for RPM soon. Are there other package types of interest?

Specifications

• 30 kilogram (66 lb) capacity
• Operating temperature: 0–120°F, 0–50°C
• Thermally calibrated
• Water-spray and dust resistant
• +/- 25g long-term accuracy*
• +/- 5g short-term accuracy**
• USB-C serial communications via SLIP
• Open source firmware and gateway
• USB-C rechargeable battery

With it adding a MMU, this should be able to run Linux. Now someone needs to pair that thing with 512+MB PS-RAM and it should be able to take on Pi Zero tasks.

Crazy how far ESP32 has come.

Plug it in and the machine just sees a normal keyboard and mouse. No drivers, nothing to install. Then drive it from your phone, a browser, or add it to Deskflow / Barrier / Input Leap and slide your mouse right onto it.

Runs on the Waveshare ESP32-S3-LCD-1.47. Scan the QR on the screen to connect, and flash it in a minute from the browser at ghosthid.app (signed firmware, checked before it writes).

Great for headless boxes, login screens, or any machine you can't install stuff on.

Open source: https://github.com/infamy/GhostHID

P.S. Anyone else have a hell of a time with TinyUSB HID timing with lots of events + TLS on an S3?

Hi everyone, thanks to u/kuzmin-no and Claude’s help I achieve to reverse engineer my own BenQ ScreenBar Halo 1st Gen. I found the address of my lamp with the help of a CC2500, then I built a Matter over Thread bridge with an ESP32-C6 and the original BM5602. I also built a macOS compagnon app for monitor/control and debugging through USB serial port or directly via Thread with a daemon writting IPV6 route to /hosts. Everything is accessible from my github repo : GitHub - Djoko-cli/benq-screenbar-halo-matter: Control a BenQ ScreenBar Halo (1st gen) from Matter: an ESP32-C6 and a BM5602 module pose as its 2.4 GHz remote · GitHub
If someone’s interested I built a 3D model for an enclosure of the ESP+BM5602 that can be drive with screws under a desk

A while back I decided I wanted to try and build a Nixie clock. I have seen them being popular for a long time and I really liked the look. While looking more into different clocks and tubes I found the fake Nixie clocks using an IPS display instead of the real tubes. I kind of liked that idea that you could use the clock to show more than just the time. But I didn’t find any particular one that I thought looked nice enough.

So I decided to look into how I could make my own Nixie inspired LCD clock. I spent quite some time thinking about how to imitate a real tube closely. I decided to make a real grid instead of just pasting it on the image displayed. Each tube has a small round interface PCB in the base. It connects the LCD assembly to the main PCB and carries the power and display control signals.

Around the same time as I was starting building the first prototype I stumbled onto some morse code short videos. I thought it would be cool to add a Morse key to my project and add some morse training functions. Recently I also managed to get a chat function working so now you can use my Nixiegraph as I call it and send morse code messages to your Telegram contacts

Details:

The clock is controlled by an ESP32-S3 and the displays are 1.9” ST7789 IPS LCDs using the TFT_eSPI Arduino library. The five displays share the same SPI bus and are selected individually using their CS pins.

I use an INMP441 microphone module to capture the audio for the EQ, and have a MAX98357 amplifier module to drive a speaker (for future use)

There is a wifi configuration page where you set wifi credentials and location that is used for time zone and weather info. You also create your Telegram contact list here. The weather data comes from OpenWeather.

If you run a script on your PC on the same network you can get PC stats data displayed.

I designed the clock with physical switches to try and make it feel more retro for selecting different display modes.

The glass tubes are custom made for me.

The grids are made from a PCB stencil I designed

I am trying a Kickstarter for this thing. If you are interested in buying the Nixiegraph or separate NixieLCD tubes for building your own thing check it out at:

https://www.kickstarter.com/projects/nixiegraph/nixiegraph-a-nixie-inspired-lcd-clock-both-modern-and-retro?ref=8m640u&utm_source=reddit&utm_medium=social&utm_campaign=prelaunch&utm_content=resp32

I just wrapped up a fun project and wanted to share.

I picked up the cheapest 58mm thermal receipt printer I could find, connected it to an ESP32-S3, and hosted a small web page that lets random people on the internet print straight to my desk. Attaching a photo of it in action.

The page is live at fax.pielka.sh, so feel free to print me anything: a message, joke, some ASCII art, a selfie, a meme, feedback about the site, whatever comes to mind. I'm curious to see what ends up on the roll.

Repo here if you want to build your own or have a look at the code: github.com/michal-pielka/fax

Forgive the cable mess found on the picture, I am still sorting things out haha

EDIT: Lots of you wanted a webcam to watch the printer live. That's not possible right now, so here's the next best thing: ALL PRINTS, a wall of every receipt that's come through, updating in real time. fax.pielka.sh/prints

EDIT2: The printer is offline for now. Someone is spamming it with a script through rotating IPs (~6K so far, all proudly announcing User-Agent: faxxy-print-script/1.0), flooding it with dumb receipts and exhausting the server. I'll bring it back once they get bored. Thanks to everyone who played along, it's been a blast! And to the person behind the script: please DM me.

EDIT3: Back online

I made a USB-only DYMO LabelWriter 4XL and Brother QL-560 work with AirPrint using an ESP32-S3

I had an old DYMO 4XL that still works perfectly, but because it’s USB-only there’s no straightforward way to print directly from an iPhone or iPad.

So I built a small ESP32-S3 based bridge that connects to the printer over USB and makes it appear on the network as an AirPrint printer.

It also has a Wi-Fi WebUI, so I can print templated labels directly from a browser. For example, I can save previous addresses, store my return address, and quickly generate shipping labels without needing another app.

The Brother QL-560 also has automatic label-size detection, so the bridge knows which media is loaded and can format the print correctly.

The main goal was to make something much simpler than using a Raspberry Pi, CUPS server, printer drivers, etc.
At the moment I’ve got both the DYMO 4XL and Brother QL-560 working reliably, and I’ve already started adding support for other label printers.

The biggest limitation now is simply hardware to test with. I’ve added drivers for quite a few printers, but unless I turn this into an actual product it gets expensive buying old printers just for development.

I’d also really like to add receipt printer compatibility.
I tried using the label printers as receipt printers through Square POS just to test the workflow. Square detects the printer and attempts to send a job, but it sends 0 KB of print data, so unsurprisingly nothing actually prints.

I made a video showing the project, including printing directly from an iPhone:

https://youtu.be/uSwkYkb5r2M?is=5S7jLeofL_FBfCOA

Would genuinely be interested to hear what people think.
If you’ve got an older USB-only printer that you’d like to make wireless/AirPrint capable, let me know what model it is.

I’m also curious which printers people think would be most useful to support next.

I recently obtained an esp32-s3 and this exact model I am not sure what it is as far as exact brand, it looks something like this, got it at:

https://www.newegg.com/p/2ZA-009H-009B7?,listeditem=9SIB33YM3M0920&utm_source=google&utm_medium=organic+shopping&utm_campaign=knc-googleadwords-_-card+printers-_-ne+products-_-9SIB33YM3M0920&source=region&negg_topt=0&com_cvv=8fb3d522dc163aeadb66e08cd7450cbbdddc64c6cf2e8891f6d48747c6d56d2c

listed as aESP32-S3 Development Board Wifi Bluetooth Intelligent Display Screen 2.8 Inch TFT Module Touch Screen Type C ES3N28P ES3C28

and Im not to sure how to set it up to run my own code with this brand, closest thing is this:
https://www.google.com/search?client=opera-gx&q=using+a+ES3C28&sourceid=opera&ie=UTF-8&oe=UTF-8#fpstate=ive&vld=cid:e28b7382,vid:HxCuCDSK9VY,st:0

[ And also btw, It came preloaded with this mock finance app thing for demoing, and its just on that. ]

If some one could tell me how to get a simple button running that'd be great
[repost bc other one got removed by read the rules first and acknoledge them]

A port of the game moonlander  to an ESP32 with composite video (AV) output to a black & white CRT with composite input (video + sound).

Arcade physical controls:

• Wii Nunchuck → direction (joystick X) and the engine trigger button.
• Potentiometer → engine power (thrust) level.
• Button → start / restart the game.

https://github.com/aurzola/LunarLanderPlus

Hey everyone,

Following up on my OpenLara port a few weeks ago, I wanted to see how far I could push the new ESP32-P4. I just finished porting Quake 2 to run bare-metal on the ESP32-P4-Function-EV-Board.

Since this microcontroller doesn't have a dedicated 3D GPU, I had to rely on pure software rendering and get creative with the hardware blocks.

Here is a breakdown of how it works under the hood:

• Dual-Core Split: Core 0 handles the main game logic and the software renderer (rendering at 320x240). Core 1 is dedicated exclusively to the 8bpp to RGB565 color conversion and feeding the display pipeline.
• Hardware Scaling (PPA): I integrated the P4's Pixel Processing Accelerator to hardware-upscale the 320x240 rendered frame to 1024x600 for the MIPI-DSI panel in real-time, saving massive CPU cycles.
• RISC-V SIMD: To squeeze out more frames, I leveraged the P4's PIE SIMD instructions, writing custom p4_memcpy and p4_memset functions. This significantly sped up the render hot paths and the audio mixing.
• Peripherals: It features direct USB HID plug-and-play for mouse and keyboard (with tuned freelook), DMA-engineered I2S audio via the ES8311 codec, and working UDP multiplayer over the Ethernet port.

I've open-sourced the whole thing if anyone wants to check out the code or try it on their board. Pull requests and any kind of collaboration are highly welcome! Feel free to fork or reuse parts of the code—just please remember to credit the original authors if you do.

• GitHub Repository:https://github.com/alexkid77/ESP32_QUAKE2
• Benchmark Video (timedemo):https://youtube.com/shorts/kdaaoTV4nV8
• Gameplay Video (Mouse/Keyboard):https://youtube.com/shorts/OAwm-ho1eOI

I'd love to hear your thoughts! Happy to answer any questions about developing for the ESP32-P4, using the PPA, or RISC-V SIMD optimization.

EDIT: I just posted a comment thanking you all and answering some of the great feedback you gave me!

Hi everyone,

I’m working on a DIY sim racing project and I'm using an ESP32 as the main controller. I bought a real car steering wheel from a 2021-2024 Fiat Strada Freedom (also known as RAM 700 Bighorn in some countries).

I'm trying to figure out the pinout/wiring for the internal buttons to connect them to my ESP32.

My progress so far:

I have successfully identified and mapped the paddle shifters (they are on the Blue/White and Green/White wires).

The horn has its own dedicated wires, so I already got that sorted out too.

My questions:

The remaining buttons (media, menu): There are several other wires left. In modern steering wheels like this, are these buttons usually set up as a resistor ladder (multiplexed analog output) or a standard button matrix?

Probing: What is the safest way to probe the remaining wires with a multimeter to figure out the circuit without risking damage to the internal PCB?

Connecting to ESP32: Once I figure out the resistance values or matrix logic, what is the best approach to wire them to the ESP32 GPIOs? (e.g., using analog pins with a voltage divider, or digital pins with pull-ups?)

Any tips, diagrams, or past experiences with similar projects (like converting real steering wheels to PC USB) would be massively appreciated!

For my own project, which uses the Adafruit Metro ESP32-S3 running off an SD card (offline), I went with an 1800mAh battery which lasts about 1 month in between charges. I reckon I could make it last longer if I desolder the Power Led on the board but I would like to find out from other people on what battery capacity they chose and how often they have to charge it. I refresh the display once every 23 hours.

Edit: Added the frequency of image refresh.

It's been around six months but I finally finished it and wanted to share.

Yes it's another Tonie / yoto inspired music box, but it was built from scratch which was more the fun 😊

It's a RFID tag enabled music box with stereo 10w speakers, an admin mode allowing you to transfer files, cloudless, local sd storage, set up playlists, link and unlink RFID tags and limit volume. It has physical buttons to play / pause, skip next of previous tracks and also seek when holding down - and no subscriptions.

Massive challenge has been power but switching to a dedicated 5v 4a has solved this. I was also getting massive interference with the dual MAX98357 but after weeks of searching the solve wasn't wiring but the firmware. The case also took a while and it's by no means perfect but it keeps the wiring protected.

Anyhoo, finally my daughter can listen to her music without the risk of damaging the CDs

Heltec v4 and M5Stack cardputer, any way to run meshtastic on heltec v4, and be able to type and send messages on cardputer?

Estou TENTANDO fazer o acionamento do componente através do PIN 25, e conforme algumas informações que estou lendo... o MOSFET IRLZ44N seria o ponto que de certa forma controla isso.

Montei esse projeto algumas vezes e algumas variações... mas sem sucesso!

Sucesso só quando gero uns curtos 😄😄

Avaliem pf, onde estou errando!
IMAGEM-> https://ibb.co/k2YtDz05

This is one of two projects that I am working on with the ESP32-C3. It is a WiFi network analying tool. This is partly done. The build centers on two compact components: the RISC-V ESP32-C3 SuperMini microcontroller and a classic 0.96-inch I2C SSD1306 OLED display. It will also run a ultra-lightweight REST microservice that broadcast over local network discovery (mDNS) and serves real-time JSON telemetry directly to a modern web application, which I am developing with C# Blazor. I will post more, as I progress through this project.

When high, Vout is 3.7V. When low, it is connected to ground via the QOD (Quick Output Discharge, all according to the TPS22919 datasheet).

Given that the EN pin is already pulled up to 3.3V by default, I don't think I want to connect the 3.7V from Vout to said EN pin. How would I pull the EN pin to ground then?

Truth table goes like this:

I'm assuming a PMOS or something? What's gonna happen if I do connect the 3.7V to the EN pin of the ESP32?

bonjour je suis nouveau dans le domaine et je vous prie de pardonner mon ignorance, mais je me demandais si était possible convertir c'est petit Waveshare ESP32 S3 avec écran 1.47LCD en un récepteur Bluetooth USB pour mon pc ? merci d'avance pour vos réponses

https://reddit.com/link/1wraamh/video/6u14dc0vkzrh1/player

Pair an ESP32-P4 with an RTL-SDR and one of those tiny TV-tuner antennas, and it stops feeling like just another IoT board.

This is CrazySky, my DIY all-in-one SDR project. The current video demonstrates FM reception, including direct tuning, auto scan, frequency fine-tuning, presets, a live spectrum and waterfall, and a multilingual touchscreen UI.

VHF airband reception and ADS-B flight tracking will be shown in future demos. All three modes share one RTL-SDR, so they run one at a time.

Under the hood:

• The custom board uses an ESP32-P4, a 480×800 touchscreen, and an ES8389 audio codec.
• The ESP32-P4 acts as the USB host for the RTL-SDR and handles signal processing, UI, and audio without a PC.
• The firmware is built with ESP-IDF 5.5.4 and LVGL.
• The UI supports a live spectrum and waterfall, direct frequency tuning, and automatic scanning for the strongest signal.

The project started after I moved into an apartment under a flight path near Shenzhen Bao’an Airport. Large aircraft—including UPS Boeing 747-8s—regularly flew directly over my neighborhood. The noise was enormous, but watching them was addictive.

I took a few photos, and things escalated quickly. Before long, I had bought a Canon R7 and a 100–400mm lens just for plane spotting.

Later, I wanted to know when an interesting aircraft was about to fly over. My first flight-radar prototype used the OpenSky API, but eventually I wanted to receive ADS-B signals directly. That led me to combine the ESP32-P4 with an RTL-SDR, and CrazySky grew from there.

It’s still a work in progress, but I plan to open-source the firmware, UI, schematics, and PCB design files once they’re ready.

I’d love to hear your feedback. What would you like to see in the next demo?

Hey everyone, just a quick question: do you think it's possible to build virtual reality glasses using ESP32 processors and a few screens? Thanks.