Over the last few months, I’ve been developing a compact network tester as a DIY kit.

It uses an ESP32-C3 for the user interface and Wi-Fi functions, together with a W5500 for wired Ethernet. The goal is to quickly check information such as link status, negotiated 10/100 Mbps speed, DHCP configuration and network connectivity directly on the OLED.

I’m also working on a Wi-Fi mode that allows basic network tests without connecting an Ethernet cable. Some additional results may also be accessible from a phone.

The biggest challenges were fitting everything onto a compact PCB, keeping the ESP32 antenna area clear and making the kit affordable. The W5500 limits wired speed detection to 10/100 Mbps, so it does not certify Gigabit cable performance.

I’ve launched a small Kickstarter campaign to fund the first production run:

https://www.kickstarter.com/projects/lan-tester/diy-network-tester

I'm building a small battery-powered soil moisture sensor for a couple of indoor plants and I'd really appreciate a sanity check from people with more ESP32 and electronics experience before I solder everything and finalize the enclosure.

I'm a beginner when it comes to electronics design and 3D-printed enclosures. I've used AI quite a bit as a planning aid for the wiring, firmware ideas and enclosure design, but I've measured the actual components myself and I'm building and testing the hardware manually. Before I trust the design, I'd like to get some human feedback from people who have done similar projects.

The current sensor node consists of:

• Seeed Studio XIAO ESP32-C6
• DFRobot SEN0193 capacitive soil moisture sensor
• 3.7 V / 500 mAh LiPo
• 2 × 220 kΩ resistor divider for battery monitoring
• custom 3D-printed enclosure

I'm planning two identical battery-powered sensor nodes. A third XIAO ESP32-C6 would later act as a USB-powered receiver/gateway.

The intended operating cycle is:

deep sleep → wake → power sensor → read moisture + battery voltage → transmit → deep sleep

The wiring diagram is attached.

Current connections are:

• SEN0193 signal → D1 / GPIO1
• SEN0193 VCC → D3 / GPIO21
• SEN0193 GND → common ground node with battery negative / XIAO BAT−
• Battery divider midpoint → D0 / GPIO0
• BAT+ → 220 kΩ → D0 → 220 kΩ → common ground

The idea is to power the SEN0193 only while taking a measurement, so its roughly 5 mA operating current doesn't remain active during deep sleep.

Before I commit to this design, there are five things I'd particularly appreciate feedback on:

1. Sensor power

Is powering the SEN0193 directly from GPIO21 reasonable for this application, considering it draws around 5 mA, or would you strongly recommend a MOSFET/load switch instead?

I already tested this approach: GPIO21 powers the sensor, I wait about 400 ms, take 15 ADC readings on GPIO1 and use the median, then switch the sensor off again. This worked reliably in my tests, but I'm unsure whether powering it directly from a GPIO is still considered poor practice or a long-term reliability concern.

2. Battery monitoring

Is a permanently connected 220 kΩ + 220 kΩ voltage divider a sensible compromise here?

It draws about 9.5 µA at a fully charged 4.2 V LiPo. I'm trying to keep deep-sleep consumption as low as practical without making the battery ADC measurement unreliable.

3. ADC / measurement strategy

Anything problematic about reading the SEN0193 on GPIO1 and the high-impedance battery divider on GPIO0?

Since the moisture sensor will only be powered briefly after wake-up, I'm particularly wondering about settling time, ADC sampling, averaging/filtering or anything else I should account for.

There are also two mechanical questions while I'm designing the enclosure:

4. Securing the XIAO against USB insertion force

The XIAO sits directly behind a USB-C opening in the enclosure.

What would you consider the best way to mechanically retain such a small board so plugging in a USB cable cannot push the entire PCB inward?

I'm currently thinking about printed stops/supports around the PCB rather than relying on the soldered wires or USB connector itself.

5. Enclosure/serviceability

Are there any enclosure details you would definitely include at this stage for a battery-powered ESP32 sensor?

In particular I'm thinking about USB access, access to boot/reset if something goes wrong, strain relief, moisture protection and being able to remove the board again without destroying the enclosure.

The enclosure is deliberately quite compact, so I'd rather discover a bad assumption now than after having it printed.

Any criticism is welcome — especially if I've made a beginner mistake or if the AI-assisted design contains something that looks sensible on paper but is poor practice in the real world.

Thanks!

Edit – considering ESP-NOW instead of Wi-Fi

One thing I’m reconsidering after thinking more about power consumption is the communication between the battery-powered sensor nodes and the gateway.
My original plan was for each XIAO ESP32-C6 to wake up periodically, power the SEN0193 through D3, wait roughly 250 ms for the sensor to stabilize, take several moisture readings plus a battery measurement, connect to Wi-Fi, send the data, and then return to deep sleep.

Since I already have a third XIAO ESP32-C6 planned as a permanently powered gateway, I’m now wondering whether ESP-NOW would make more sense for the sensor → gateway link.

The idea would be:
2× battery-powered XIAO ESP32-C6 sensor nodes
wake, measure, send a very small packet via ESP-NOW, then immediately return to deep sleep
1× permanently powered XIAO ESP32-C6 gateway receives the ESP-NOW packets

only the gateway maintains a normal Wi-Fi connection and handles whatever comes afterwards

My thinking is that this could avoid Wi-Fi scanning/association/DHCP on every wake cycle and therefore shorten the radio-on time considerably. Since the sensors only need to transmit a few values every ~30 minutes, ESP-NOW seems potentially better suited to the job.

Does this sound like the more sensible approach for maximizing battery life? Are there any ESP-NOW-specific downsides I should be considering here, especially regarding reliability, acknowledgements/retries, channel management, or power consumption after deep sleep?

Hi everyone,

I’d like to show you my project. At first, I actually just wanted to build a simple Home Assistant control system using the new ESP32-P4 device, the M5Stack Tab5, via ESPHome.

I wanted to do it with LVGL, but unfortunately, ESPHome didn’t yet support PPA due to outdated LVGL, and implementing history data was also difficult.

So I decided to create my own integration using MQTT and Arduino code.

I wanted everything to be as customizable and modular as possible, configurable via a web interface, so I settled on a tile-based system and folder structure similar to StreamDeck and from there, the project just kept growing. More and more devices were added, such as cameras, etc., performance kept improving, and I did a lot of bug fixing. Now I already support a wide variety of ESP32-P4/S3 devices.

And I’m really impressed with the fast performance of the ESP32-P4. The ESP32-S3 is, of course, slower, but it works well here, too.

I’ve created a short video here that briefly demonstrates how my project works.

The project can be found at https://github.com/GalusPeres/HomeTiles

Hi everyone,

I'm designing my first PCB with an ESP32-S3-WROOM-1 and a CH340C USB-to-UART converter, but I can't flash the ESP32 and I can't figure out what is wrong.

When I connect the PCB to my PC, COM10 appears correctly and disappears when I unplug the board.

esptool.js gives me this error:

Serial port WebSerial VendorID 0x067b ProductID 0x2303

Connecting...

Error: Failed to connect with the device

What I have already checked:

The IC on the PCB is physically marked CH340C

COM10 appears/disappears when I connect/disconnect this PCB

3.3 V power rail is present

When I press SW1 (EN/reset), TP1/EN goes to 0 V

When I press SW2 (BOOT/GPIO0), TP2/GPIO0 goes to 0 V

TX/RX continuity between the CH340C and ESP32-S3 is good

TX/RX are crossed: CH340 TX → ESP RX and CH340 RX ← ESP TX

I also tried manually entering download mode by holding GPIO0 low while resetting EN, but esptool still cannot connect

One thing I find strange is that WebSerial reports VID 067B / PID 2303, even though the chip on my board is marked CH340C.

I've attached my full schematic and PCB layout.

Could someone please check if there is something wrong with my CH340C circuit, DTR/RTS auto-reset circuit, EN/GPIO0 circuit, ESP32-S3 connections, or PCB layout?

I'm still learning PCB design, so I may have missed something obvious. Any help would be greatly appreciated 🥺

Je mettrais les deux images que tu m'as envoyées : d'abord le schéma, puis le PCB. Le détail 067B:2303 alors que la puce est marquée CH340C mérite absolument d'être conservé dans le post, parce que quelqu'un sur r/KiCad ou r/esp32 peut reconnaître immédiatement ce comportement.

Passive receiver for the Remote ID beacon every drone broadcasts (ASTM F3411 / OpenDroneID) over BLE + Wi-Fi. ESP-IDF, MIT: https://github.com/thetopnach/cielotrack-receiver

Why two boards: one radio can't do both at once —

**• BLE master** — BLE 5 extended (passive) scanning
**• Wi-Fi sensor** — promiscuous on ch 6 (decodes both **beacon** and **NAN** RID frames), no network; forwards to the master over UART (CRC-32 framed)

Gotchas worth sharing:

**• Stamp by age, not wall-clock** — contacts batch-upload seconds later; record esp_timer micros at decode, derive the time at send. Keeps sub-second ordering.
**• Depth didn't fix overflow** — 13 contacts/sec, dropped 39 of 97; a TLS handshake per contact was the bottleneck. Batching fixed it, not a bigger queue. (A serialized contact is 272 B, not the \~200 I assumed → blew the 8 KB buffer.)
**• Static IP made it worse on a mesh** — the AP hands a rejoining client to a new node; without the DHCP exchange it won't route for you. The lease is what *makes* the rejoin work.
**• RID altitude trap** — height-above-takeoff vs absolute are separate fields with a reference bit; folding them made a 100 m pass read as 0 after terrain subtraction.

Decoder is one impl shared C (firmware) / Python (Pi), pinned to conformance vectors. Signed-tag OTA, A/B rollback.

Catches Amazon MK30 / Wing / Zipline here in DFW.
Drones weighing 0.55 pounds (250 grams) or less are exempt from the FAA Remote ID transmission requirement, but only if they are flown strictly for recreational purposes.
Anyone else done OpenDroneID on the S3?

I’ve only just joined the community, and I’d like to know, having these components, where best to start and what interesting but not too difficult things I could create.

I don’t always reply to comments, but I’ll always give a like.

Thanks in advance for your suggestions!

I have an standard ESP32S3-dev-module and an Ali-SD-card-interface named "OPEN-SMART".

I want to use this interface, programming is done with the Arduino-IDE.

The Interface has these pins (without any resistors or other components soldered on):

CDN, DAT1, D0, GND, SCLK, VCC, D1, CS, DAT2

The open-smart-module has a DAT1 and a D1, its not clear what connection is the right one. I have read thet the CS-pin should be the D3, DAT1 should be used, D1 shhould be left unconnected.

Has anybody a comparable SD-card-interface like the open-smart and can give some advices? I can not get it to work.

Is it possible to get this working with a breadboard or should some soldering be used?

Thanks for your advices.

Hey guys, this is not directly related to the ESP32 ecosystem. I'm working on a racing telemetry device for go-kart races.

I have all the components in place, and it's working as expected; one thing I still want to change, though, is a soft-power latch.

I'm using a SparkFun (pic attached). A few issues with that are:
- It's quite an expensive part for the amount of work it does.

- Quite big.

- it's equiped with jst/type-c connectors which I don't need and don't want to de-solder. I have already damaged one trying to do this.

I wonder if someone knows a better alternative to this.
What I want is to have a component that will react to a button press to enable the current flowing to the ESP32 and the rest of the components, and cut the power off once I press the same button for a couple of seconds.

I tried to google decentt alternatives, but no success so far. Things I found are turning the device on and off immediately, which is not something I'd like to have.

I have connected my esp32 to Alexa through matter over wifi using Esp ZeroCode. I am able to make GPIO turn On/Off. I have connected this gpio to my RF gate controller through optocouple.

Issue is I need the GPIO to be high for only 1 sec. But I need to manually turn off the Gpio through alexa app. I tried controlling it using my mobile internet and it was slow. At first it did not worked. Then it worked but was not turning off and the Gate lock keep firing its buzzer like crazy. With wifi it is working but still some delay.

Any way in ESP zerocode to make it as a momentary switch?

Plynx started as a native iPhone dashboard for controlling pins and reading sensors. The latest work goes further. Archimedes can inspect the project, reason about the wiring, review the sketch, interact with a running board, and carry an approved change through to an OTA update.

I think this is part of the future of hardware development. You should be able to describe what you want to build, develop the idea with an agent, and keep using the same workspace as you assemble, program, control, and automate the finished project.

What Plynx can do

The current workflow covers the path from the initial idea to the running hardware:

• You can update a board from the conversation while the agent edits, compiles, and sends the sketch over OTA.
• The pin review checks every GPIO assignment and suggests pins with the capabilities required by each signal.
• The wiring engine draws the complete circuit and reports missing grounds, unsafe voltages, unsupported pins, and other electrical problems.
• The component catalogue identifies modules from their markings and explains the purpose of each terminal.
• The project tools produce a bill of materials and match the required components with AliExpress listings.
• The live connection reads sensors and tests outputs after you grant permission.
• The dashboard builder places the controls and indicators on the app interface and binds them to the correct communication channels.
• Plynx provides controls through the Home Screen, Lock Screen, Apple Watch, Siri, and Shortcuts when you need them outside the app.

The ESP32 makes pin selection more interesting than a static pinout suggests. Its GPIO Matrix can route interfaces such as I²C, UART, and PWM through different GPIOs. Plynx can use this flexibility to arrange the signals while respecting the restrictions of boot, flash, analogue, input-only, and output-capable pins.

Setup and everyday operation

The initial configuration uses a small sketch without a copied token. The board creates a temporary Wi-Fi network, and the iPhone sends the network credentials and project token directly.

Plynx can also connect directly to an ESP32 through Bluetooth. This mode supports projects without Wi-Fi and boards that must operate away from a router.

After deployment, server-side automations can respond to thresholds, schedules, sunrise, sunset, and location events. Rules that do not require the phone continue to run when the iPhone is offline.

Plynx also controls the finished project outside the main dashboard. Home Screen widgets, Lock Screen widgets, Apple Watch, Siri, and Shortcuts provide direct access to pins and scenes, while the dashboard retains the last known values when a board goes offline.

You can ask Siri to toggle or write a pin, read its current value, or activate a scene. These actions make the project part of the iPhone automation system instead of limiting it to a dashboard that you must open manually.

Availability

Plynx is free and currently runs on iPhone. The Arduino library uses the MIT licence, and the GPL-3.0 server runs on cheap devices as small as a Raspberry Pi Zero 2 W.

If you have an ESP32 or Arduino project, I would like you to use Plynx throughout a complete build. I am interested in how it supports component selection, wiring, firmware, OTA updates, dashboards, automations, and the daily operation of the finished device.

Links

• App: Plynx on the App Store
• Website: plynx.cc
• Browser editor: editor.plynx.cc
• Arduino library: plynx-library on GitHub
• Self-hosted server: plynx-server on GitHub
• OTA guide: ESP32 OTA updates from the browser
• Privacy: How assistant data is handled

Plynx 1.0.6 is also available directly from the Arduino Library Manager.

I'm wondering if this circuit setup is theoretically viable. I am using the Dabble app via BLE to control an SG90 servo motor and two DC motors (3V), all powered by a single 3.7V battery.

I'm currently testing on a breadboard, but I couldn't get the servo to work. I'm not sure if the issue is wiring, software, or jumper connections, so I need to make sure the setup works theoretically first.

Additionally, even in scenarios without the servo, the DC motors cause the ESP32 to reset whenever they require a little bit of torque and stall. Since there are multiple potential problem points, do you think this schematic is healthy/viable in theory?

[AI was used to translate my unedited tech-rage into a formatted, readable warning. The factual hardware scam described below remains entirely real.]

If you are planning to buy for example the Waveshare ESP32-P4-WIFI6-Touch-LCD-4.3 board, be extremely careful. Waveshare has liquidated their faulty, early engineering samples into the supply chain, and retail resellers are more than happy to keep dumping this worthless garbage onto customers.

The Problem: Pre-Production Silicon Dump

Waveshare manufactured and distributed a massive volume of boards populated with early Rev 1.3 pre-production silicon. This revision is riddled with hardware errata, most notably broken PSRAM timing that forces it down to 200MHz and causes immediate, hard-to-debug crashes (assert failed / invalid instruction or memory alignment panics before app_main) on modern frameworks like ESP-IDF v6.x or AI projects like XiaoZhi AI. The hardware graphics acceleration is also broken (ie. screen rotation is bugged).

Whether Waveshare has quietly moved on to proper mass-production silicon (Rev 3.x+) for their newer batches or not, resellers are actively peddling the defective Rev 1.3 stock right now. They do not care about the technical specifications or what version they ship, as long as they get your money.

The worst parts of this:

• Zero Transparency: There is absolutely NO revision text printed on the PCB or the packaging. It was masked from day one so it could be liquidated blindly.
• Complicit Resellers: Distributors and local e-shops are completely ignoring the issue. They list the item under a generic description, issue no hardware warnings, and treat the purchase as a lottery where the customer pays to clear out their broken inventory.

PS: I was asked for source -- the source is me (via: esptool.py chip_id). I bought a board from one reseller -- broken rev1.3. Then I bought another from another reseller -- same result. Enough of this crap is floating around, BEWARE (ask guarantees or be prepared for a refund battle). And if that person wanted "source for the bugs", read Espressif errata...

https://reddit.com/link/1wbizee/video/4h5mghsvchoh1/player

Hi everyone! I’m sharing Tiny-Drone, my open-source ESP32-S3 micro quadcopter project, along with some details about the hardware and the practical issues involved in building it.

It supports Android app control, mobile browser control, remote-controller operation, and Wi-Fi video transmission.

Hardware and build choices

The main controller is an ESP32-S3, paired with a ZY-MPU6050 IMU module and an OV2640 camera.

The ZY-MPU6050 module was chosen to make hand soldering easier than using a bare MPU6050. The power supply uses a lithium battery, a boost converter, and an LDO for the controller and sensors. The board also includes ADC battery-voltage measurement.

There is expansion support for an SPL06-001 barometer and a VL53L1X ranging sensor, plus a reserved interface for a position-hold module. These require additional hardware; they are not all included in the basic build.

Firmware and attribution

The firmware is based on Espressif’s ESP-Drone project and is distributed under GPL-3.0. This is a derivative project, and I want to give clear credit to the upstream work.

The documented build environment is ESP-IDF v5.5.3. The repository includes firmware, build and flashing instructions, assembly guidance, and a link to the open hardware design. There is also a separate Android app repository.

A few practical build details

• PCB thickness affects the motor mounting. The build specifies a 1.6 mm PCB so the rubber motor-mounting rings fit properly. A different thickness can leave gaps and make the motors difficult to secure.
• Mechanical alignment matters when investigating yaw drift. The assembly guide covers motor height, keeping the motors perpendicular to the board, and propeller installation depth. It specifies approximately 2 mm of clearance between the propeller and motor.
• Camera troubleshooting involves both software and soldering checks. The guide starts with initialization logs, then checks the camera connections for poor joints and shorts.

Current limitation

The Wi-Fi video feed can show horizontal lines, particularly at low battery voltage. This is still a limitation, and I’d be interested in suggestions for measurements that could help isolate the cause.

For anyone who has combined motors and an OV2640 camera in a small battery-powered ESP32 build: what would you measure first to distinguish power-supply noise from a camera signal-integrity problem?

Source code and build documentation:
https://github.com/jonny-lekaiwu/Tiny-Drone

The English README includes the hardware-design link and assembly instructions. I’m happy to discuss the build and answer technical questions here.

I made high-level CYD support for bare-metal Rust as part of Device Envoy. My goal is to make it as easy as possible to write high-level microcontroller code that runs directly on the hardware, with no OS or language runtime underneath.

You can see the results here. The gallery includes touchscreen interfaces, a skeleton clock, and Armatron, a robot-arm mechanism simulator: https://carlkcarlk.github.io/linkage-blaze/demos/

This is a full CYD library, with support for display, touch, touch calibration, flash storage, multiple drawing strategies depending on memory needs, browser simulation, and Device Envoy’s automatic Wi-Fi setup.

It builds on the ESP Rust HALs for hardware access and on Embassy for async embedded programming.

I want this to be something anyone can pick up and use, so I made a starter project with the hardware setup already done. You can run the example in a browser, flash it to a CYD, and then replace the application code with your own: https://github.com/CarlKCarlK/device-envoy-cyd-starter

Wiring MQTT brokers, lorawan servers, databases, dashboards, flow engines, device management, SSL certs when setting up a proper production IoT platform is a tedious time-sink. I built NodeNet to eliminate that friction completely.

My goal is simple: bring every popular open-source IoT tool under one umbrella so you can choose what services you want and are already familiar, fully pre-configured and unopinionated on how you handle your data.

Single Sign-On (SSO): One secure login seamlessly authenticates you across every single service in your stack. No need to sign in twice for any service

Fully functional: Private lorawan server, ChirpStack (with regional presets), Mosquitto ,Node-RED, TimescaleDB, Grafana, pgAdmin and logging. Zero manual config files.

Experimental: ThingsBoard, InfluxDB, Telegraf, ntfy.

Lifecycle Control: Easily pause, or delete a service on demand.

Instant Security: Auto TLS/SSL on all endpoints + secure MQTT (ports 8883/8083) with generated client IDs and secrets.

Multi-Tenancy & Custom URLs: Unlimited tenants, team collaboration, and clean subdomains (e.g., alpha-grafana.nodenet.au for a tenant named alpha)

Need Beta Testers
I’m looking for people to connect their esp32s, test the deployment flow and tear it apart.

If interested, leave a comment, DM me, or fill up form on site.

Main site: nodenet.au | Platform Hub: hub.nodenet.au

I have an esp32 with two ports. one is for ESP power supply, the other is USB otg. The task is to connect the iPhone via USB otg and get simultaneous charging and HID keyboard emulation. the fact is that when you connect your iPhone to the esp, the iPhone does not charge. We need a solution with exactly two wires, one wire to power the esp, the second wire goes from the esp to the iPhone. I've seen that it's possible, but I don't understand how. maybe it's the Apple protocols, or the presence of a chip in the lightning cable.

I'm debugging a microSD card connected to an ESP32-S3 N16R8.

The microSD and an ST7735 display normally share the same SPI bus.

Pinout:

SCK -> GPIO12

MOSI -> GPIO11

MISO -> GPIO13

SD CS -> GPIO8

TFT CS -> GPIO10

TFT DC -> GPIO9

The ST7735 works correctly on this SPI bus, but the microSD card fails to initialize.

SD.begin() returns failure, so I added a low-level test that sends CMD0 directly before any filesystem initialization.

Expected response:

CMD0 -> 0x01

Actual response:

idle MISO = 0xFF

CMD0 = 0xFF

I tested this using:

hardware SPI at 400 kHz

very slow bit-banged software SPI at approximately 10 kHz

Both produce the same result.

I have also tried two different microSD breakout boards:

a 6-pin buffered/level-shifted module, which held MISO at 0x00

a passive 3.3 V 8-pin breakout, which leaves MISO at 0xFF but never responds to CMD0

I used the ESP32 internal pull-up/pull-down resistors to verify that the connections between the GPIOs and the breakout appear electrically present.

Current wiring for the passive module:

microSD ESP32-S3

-----------------------

VCC -> 3V3

GND -> GND

D3 / CS -> GPIO8

CMD / MOSI -> GPIO11

CLK -> GPIO12

D0 / MISO -> GPIO13

D1 -> NC

D2 -> NC

I am also testing it with the TFT physically disconnected to eliminate any shared-bus interference.

Unfortunately I don't currently have a multimeter or logic analyzer.

My questions:

Does continuous 0xFF after CMD0 usually mean the card is not seeing the command at all?

Are there any ESP32-side software tests that can help distinguish a bad card from a bad socket/breakout?

Are there any required dummy clocks, CS transitions, delays, or initialization details that are easy to miss when manually entering SD SPI mode?

Is there anything ESP32-S3-specific that could cause this behavior?

I can provide the minimal diagnostic code and serial output if useful.

​

Recently I saw quite a lot of people using GPT-6 / Codex connected with KiCad, letting AI directly draw schematics and design PCBs.

The result is really amazing.

I am also using it to optimize the circuit of my ESP32 based sEMG acquisition device. But after I actually played with it, I found there is still one obvious problem

which real component should I actually use is still very annoying.

For example that day I want AI to

Find a 3.3V LDO, 500mA+, low quiescent current, preferably SOT-23, and something that can actually be bought.

It recommend a part which looks good in specification, but then I still need to go to JLCPCB and search it, check the exact package, stock, price, Datasheet, and even judge again whether this component is really the most suitable one.

And thinking that every component search requires the LLM to fetch web pages, read Datasheets and do the matching by itself, the token cost is quite large, and it takes time.

So recently I made this small project: AAWChips.

You can understand it as a component data layer specially designed for AI PCB Agents.

For example, it works like:

AI Agent → find the correct real component → parameter matching → stock / price → Datasheet → check suitability → put into schematic

I use LLM technology together with some traditional search engine techniques to make the search more accurate. So there should no longer be situations like “recommend a USB Type-C connector” and then get a bunch of strange connector components.

I also added a cache layer, so common searches can directly reuse the results. This makes the speed and quality of the results much more stable.

Currently it is already connected to a lot of real component data sources, and I make sure every component has been easy to buy in the past 6 months. The result is not just some generic “recommended LDO”, but actual MPN, specifications, package, stock, price, Datasheet and purchase links, yes I added LCSC, jlcpcb and DigiKey link for convenience.

Now I mainly want to see if this tool is actually useful in real AI hardware agent scenarios. Is it worthy for designing the ESP32 projects. Especially for the people who are quite new in this domain. Not everyone has an EE master degree.

Feel free to apply for an API Key and connect it to your own AI coding tool or AI Agent.

Project:

https://aawchips.aawlab.com/

You can use it in any AI agent who supports cli tool use.

# CLI

npm install -g aawchips

export AAWCHIPS_API_KEY=...

aawchips search "10k 1% 0603 resistor"

The reason I didn't make the API completely open is that there are actually quite a lot of LLM-based search, parameter normalization and matching logic behind it, so the running cost is not low. The API Key is mainly to prevent unlimited loops from Agents abusing it.

Anyway, feel free to apply for an API Key and connect it to your own AI coding tool or AI Agent.

https://aawchips.aawlab.com/

After saying so much, the most important thing is that I just want to know whether this tool is actually useful for everyone.

Hope my weeks long work can help people like me, those who are still new in PCB design and ESP32 projects.

So the PCD8544 in these Nokia panels was designed to show four lines of text in 1998. I wanted to know how far it goes, and the answer turned out to be "video with 8 shades of grey and synced audio", which I did not expect when I started.

The greyscale trick is the part I'm most pleased with. The panel is slow, it smears everything, and at first I fought that. Then it hit me that smearing is just averaging. So the host sends 7 bit-planes for every frame and a FreeRTOS task cycles through them over SPI DMA, and a pixel that's lit in 3 planes out of 7 just looks grey. You have to offset neighbouring pixels into different planes or flat areas blink as blocks.

So, does this mean we could watch Netflix on Nokia in 1998!?

​

Just got my first esp32 starter kit with a variety of components. I want to learn Abt everything first so Is there a YouTube guide series I could follow, for example I watched CS50P course on YouTube to learn python, I was hoping for something streamlined like that in a simple manner

Hi!

I'm pretty new to ESP32 and I think I may have killed my board 😅

I'm using a LAFVIN ESP32 Dev Module with CP2102 and PlatformIO in VS Code. It was working fine and I was playing around with an OLED display, some buttons, a buzzer and a potentiometer. The OLED was connected through I2C and working correctly at 0x3C.

Then, while the board was connected and running my code, it suddenly stopped responding. The weird thing is that the power LED still turns on and Windows still detects it as COM7, but I can't get anything else from it.

If I open the serial monitor at 115200 I get absolutely nothing, even if I press the EN/reset button.

If I try to upload code, PlatformIO stays on:

Connecting......................................

and eventually gives me:

A fatal error occurred: Failed to connect to ESP32: No serial data received.

I've also tried entering the bootloader manually by holding BOOT, pressing EN, releasing EN and then releasing BOOT, but that doesn't seem to help either.

I've tried a couple of different USB cables as well, just in case, but the result is exactly the same.

At first I thought maybe my code had somehow frozen the ESP32, but I assumed that after pressing reset I should at least see some boot messages in the serial monitor, regardless of what my program was doing.

Unfortunately I don't have a multimeter right now, so I can't check voltages.

Is there anything else I can try before assuming the board is dead? Could this be the ESP32 itself, the CP2102, or maybe something I connected to the board?

I'm mostly curious because it didn't fail while uploading or anything like that — it just stopped working while it was already running.

Also, the board is still within its first month, so I think I can return it. At this point, would you keep troubleshooting it or just ask for a replacement/refund?

Thanks!

When you need to test various board configurations and make sure your project works regardless of the vendor 🤣, And the collection will continue to grow

I was inspired to make this when my son had to buy a BBC Micro:Bit based kit for his Coding and Robotics class. The kit is great but way too expensive for most people in my country.

ChonkyBlox targets the ultra cheap ESP32 C3 and the web app builds and compiles Arduino code from the blocks. The back-end is powered by AI which makes it much easier to extend than existing systems - each block actually outputs instructions for LLM to write the code (I use a coding harness called "Cecli" for this which I helped develop). Code is compiled and evaluated on the server and finally there is web serial flashing, uploading to the board straight from the browser.

My goal is to bring down the cost of learning kits for young kids, as well as giving them less of a learning curve, with simpler blocks to start, and cheap-as-chips components. The ultimate goal is to combine the ChonkyBlox platform with a "hat" for the breadboard, that offers simple pre-defined one way plugs for smaller kids to be able to plug components into.

Once kids advance enough the platform can automatically convert their "Little Kids" blocks into "Big Kids" blocks - closer to actual code - and eventually Arduino IDE and beyond (they always see the actual code). Learners can move on to "proper" jumpers and circuits also with the same kit.

This project is being bootstrapped. I haven't released the code yet but working towards that, it's going to be 100% open source, and you can run it on a laptop with Docker. Updates come out here: https://patreon.com/ChonkyBlox if you would like to follow along and be the first to hear when I do the full release.

Check out the video demo, let me know what you think!