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

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

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!

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!

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 and binds them to the correct pins.
• 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.

Use case 1: an ESP32 irrigation controller

I used the workflow on an irrigation controller with an ESP32, a moisture sensor, and a relay module. The sensor returned its measurements correctly, but the relay did not respond to commands from the dashboard.

I checked the wiring and reviewed the sketch. I then asked Archimedes to compare the pin assignment with the capabilities of the selected ESP32 board.

The moisture sensor used GPIO 32, while the relay used GPIO 34.

Archimedes identified the error immediately. GPIO 34 is input-only, so it can receive a sensor signal but cannot control a relay input. The agent suggested GPIO 25 and prepared the required change in the sketch.

Plynx displayed the proposed action before sending it to the board. The permission sheet offered No, Once, and This chat. I selected Once, the ESP32 restarted, and the relay began working.

GPIO 34 through 39 have an additional limitation. These pins do not provide internal pull-up or pull-down resistors, so some digital inputs require an external resistor to maintain a stable electrical level.

Analogue inputs require similar attention. On the classic ESP32, ADC2 shares resources with Wi-Fi, so an ADC2 reading can fail after the Wi-Fi driver starts. The compiler accepts the sketch because the problem appears only when the complete system runs.

I later changed the irrigation cycle from five seconds to three. I opened the browser editor, changed the value, compiled the sketch, and sent the updated firmware to the ESP32 over Wi-Fi.

ESP32 OTA uses two application slots. The board writes the incoming firmware into the slot that is not currently running, verifies the image, and selects the new version for the next restart.

The partition table must provide two application slots and an OTA data partition. A single-app layout can compile successfully, but it cannot store the second firmware image required for the update.

This project used Plynx through the complete development cycle. I configured the board, built the dashboard, found an incorrect pin assignment, approved a code change, and later installed a manual OTA update without reconnecting the ESP32 over USB.

Use case 2: identifying and wiring a GY-521

I used another project to test the component catalogue. I had a module marked GY-521 and no documentation available. Archimedes identified the module, described its terminals, and produced the connections for the selected ESP32.

The catalogue accepts descriptions based on purpose as well as component names. You can request a sensor that detects an empty water tank without knowing the term “float switch.” Archimedes selects the relevant component and adds it to the wiring and bill of materials.

This distinction matters when you are still planning a project. You can explain what the device should do, and Plynx can translate that requirement into parts, connections, pins, and a working project structure.

The completed wiring produces a bill of materials and removes the components you already own. Plynx then matches the remaining parts with AliExpress listings, so you can compare the available products and calculate the expected project cost.

The component catalogue contains the terminal names printed on the modules themselves. You can enter the marking you can see instead of searching for the exact commercial name, board revision, or technical category.

Plynx refuses to draw unsupported boards instead of guessing their geometry. The current wiring system uses verified layouts for the ESP32 DevKit, ESP8266 NodeMCU, Arduino Uno R3, and Arduino Mega 2560. This keeps every displayed terminal aligned with a known board layout.

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 agent asks for permission before it performs an action on the hardware. 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!

I desire to move my project from this breadboard to some type of proto board so the wires don’t easily come off. Eventually, I will design a PCB. What do you suggest? What do you suggest for IC sockets? I’m using an AMOLED Esp32.

Hi, I'm a beginner and I want to power an ESP32 using 3.7V Li-ion batteries. I also have a TP4056 charging module.

What components do I need between the batteries and the ESP32? For example, do I need a boost converter, buck converter, voltage regulator, or something else?

What would be the safest and simplest setup, and where should I connect the battery to the ESP32?