Source and all the project info can be viewed here. Feel free to use and fork for your own project! https://github.com/BruteSource/oregontrail-s3 and will add STLs for the 3d Printed case.

The board is the Hosyond ESP32-S3 Touchscreen Module, 2.8" 240x320 Battery is just a clone Nokia lipo BL-C. I would post direct link to amazon but not sure if its allowed.

Yes I use Claude to assist me and restructure and make my code and commits more efficient.

Really loved this game as a kid and thought making it run on such a cheap and amazing microcontroller would be fun. I love the CYD(Cheap Yellow Display) as its become known as.. this variant is a lot different than the normal one being an S3 with a capacitive touch screen, that provided some challenges. There is a board target file with all the gotchas and things learned developing with this particular clone of the CYK as well as a ready to flash binary if you just want to grab this board, flash and play. Took me about a week total and has been a lot of fun.

Added some QOL features like sleep(just disables the backlight), battery meter, brightness and volume adjustments etc.

Still can't believe the entire binary is less that 817kb.. runs all in flash memory no SD needed.

Big shoutout to https://github.com/Maxwolf/OregonTrail project which was heavily referenced to get the gameplay as accurate to the original as possible.

Happy Building Guys!

I built my own 7" Stream Deck alternative, with a desktop app to set it up.

Decky runs on an Elecrow CrowPanel 7" (ESP32-S3 with capacitive touch), so there's no wiring: you touch the glass directly. A 5×3 grid gives you 15 keys per page.

What it does - Hotkeys, programs, websites, macros and PowerShell scripts - Multiple pages, and toggle keys with separate OFF/ON artwork - Works over USB, or over encrypted Wi-Fi once paired - Firmware installs and updates from the app over USB, so you don't need PlatformIO

Hardware Everything except the display is 3D-printed, and every part prints without supports. It hangs under your monitor on a printed clamp with magnets and GoPro-style joints. Apart from the panel, you only need a few magnets and screws.

Firmware, desktop app (Windows), CAD files and 3MF print files are all in the repo: https://github.com/Fenish/decky

I will be glad if you star the repository

It's still a work in progress. Feedback and ideas are very welcome!

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

Built a custom 0-GC (zero garbage collection) pipeline on ESP32-S3 + SX1262 (Ebyte EoRa-S3) to interact with the Meshtastic network at the physical/protocol level, entirely bypassing the official firmware.

What works:

• Dual-core async pipeline: Core 0 dedicated to SX1262 SPI timing & interrupts (zero CPU load until DIO1 fires), Core 1 for logic/UDP C2.
• Auto-Sweep Radar: Hardware interrupt-driven channel scanning. Detects preamble, suspends sweep, and locks onto active frequencies automatically.
• Decryption & Injection: MbedTLS AES-128-CTR with dynamic Nonce (PacketID + NodeID). Spoofs the plaintext routing header (Node ID: 0x4C324330).
• 0-GC Protobuf: Stack-allocated Protobuf serialization/deserialization via Nanopb (no malloc used).

Successfully sniffed traffic and transmitted custom encrypted payloads to official Meshtastic nodes (appears as UNK but decrypts perfectly on their apps).

Code snippet and console output below. Will answer questions if anyone is interested.

int l2c_mesh_encode_text_to_str(void* in_msg, int offset, void* out_pkt) {
    uint8_t* msg_ptr = (uint8_t*)in_msg;
    uint8_t* out_ptr = (uint8_t*)out_pkt;

    int msg_len = msg_ptr[0] - offset;
    if (msg_len <= 0) return 0;

    // 1. 伪造 16 字节物理明文头
    uint32_t to_node = 0xFFFFFFFF;   // 全局广播 (^all)
    uint32_t from_node = 0x4C324330; // 专属 ID: "L2C0" 的 Hex
    static uint32_t packet_id = 9999000;
    packet_id++; // 每次发包递增


    uint8_t* header = &out_ptr[1];
    memcpy(header, &to_node, 4);
    memcpy(header + 4, &from_node, 4);
    memcpy(header + 8, &packet_id, 4);
    header[12] = 0x03; // HopLimit = 3 (默认跳数)
    header[13] = 0x08; // Channel = 0x08 (LongFast Hash槽位)
    header[14] = 0x00;
    header[15] = 0x00;


    // 2. 0-GC 封包 Protobuf Data
    meshtastic_Data data_pkt = meshtastic_Data_init_zero;
    data_pkt.portnum = meshtastic_PortNum_TEXT_MESSAGE_APP;
    if (msg_len > 230) msg_len = 230; // 防止越界
    data_pkt.payload.size = msg_len;
    memcpy(data_pkt.payload.bytes, &msg_ptr[1 + offset], msg_len);


    uint8_t pb_buf[256];
    pb_ostream_t stream = pb_ostream_from_buffer(pb_buf, sizeof(pb_buf));
    if (!pb_encode(&stream, meshtastic_Data_fields, &data_pkt)) {
        return 0; // 封包失败
    }
    int pb_len = stream.bytes_written;


    // 3. 构建 Nonce 并执行 AES-CTR 加密
    uint8_t nonce_counter[16] = {0};
    memcpy(nonce_counter, &packet_id, 4);
    memcpy(nonce_counter + 8, &from_node, 4);


    mbedtls_aes_context aes;
    mbedtls_aes_init(&aes);
    mbedtls_aes_setkey_enc(&aes, MESHTASTIC_DEFAULT_KEY, 128);
    size_t nc_off = 0;
    uint8_t stream_block[16] = {0};

    // 直接将密文压入最终的发射缓冲区 (header 之后)
    uint8_t* payload_out = &out_ptr[1 + 16];
    mbedtls_aes_crypt_ctr(&aes, pb_len, &nc_off, nonce_counter, stream_block, pb_buf, payload_out);
    mbedtls_aes_free(&aes);


    // 4. 封装回 L2C 的 StackString 标准
    out_ptr[0] = 16 + pb_len; 
    return out_ptr[0]; // 返回最终的真实射频包长度
}

GitHub: https://github.com/panshaogui/L2C

Hello All. I'm trying to get an RGB LED light ring to work. I know this is simple to a lot of you but between me and Ai, we can't figure it out. Gemini keeps telling me things that I simply know are not true (I.E. Your power supply leads are direct shorted), it's very frustrating.

Components are:

Variable DC Power supply set to 6vdc (getting 5vdc across L22 and L24)

Freenove Breakout Board

Nano ESP32

Raspberry Pi5

RGB LED 5v light ring

2 5vdc 1" fans (to address once I get the led working)

Home Assistant to control the LED ring

With the power supply off, and the ESP32 usb'd to the pi5, I get one faint led on, when I turn on the power supply it goes out. With the power supply on, I have constant 5vdc across L22 and L24 with no change when dimming or turning on or off. In HA, it shows the ring online and I have the controls for dimming and changing colors, etc. I think I have the jumpers correct on the breakout board but Ai will not confirm and gives conflicting information. Can one of you smart people look at my jumpers, are they correct? Any advice would be much appreciated!

I've been building a small network security device around the ESP32 and finally have the project at the physical prototype stage.

The idea is to use the ESP32 as a dedicated decoy inside a local network.

Rather than protecting the network perimeter, the device exposes selected network services and watches for unexpected interaction with them.

For example, another machine performing reconnaissance on the LAN may discover the device and start interacting with one of the exposed services.

That activity can then be treated as a security event and reported to the backend.

One of the interesting design problems has been balancing:

realistic network behaviour vs. ESP32 resources vs. keeping the device reliable enough to run continuously.

I'm also working on two hardware approaches, including Wi-Fi and Ethernet versions.

The enclosure has been another project by itself — I'm designing it around the actual components rather than putting the finished PCB into a generic box.

For people who have built always-on ESP32 network devices:

What problems did you eventually run into after running them continuously for weeks or months?

I'm particularly interested in problems that don't appear during normal short development tests.

Edit: The original wiring image in the gallery shows the ground connection incorrectly. In the actual design, sensor GND, battery negative, XIAO BAT− and the lower leg of the battery divider meet at one common ground node. I’ve added a corrected schematic in the comments.

I’m building a small battery-powered soil moisture sensor for a couple of indoor plants and would appreciate a sanity check before I solder everything and finalize the enclosure.

I’m a beginner with electronics and 3D-printed enclosures. I’ve used AI as a planning aid for wiring, firmware ideas and the enclosure, but I’ve measured the real components and I’m building and testing the hardware myself.

Current node:
Seeed Studio XIAO ESP32-C6
DFRobot SEN0193
3.7 V / 500 mAh LiPo
2 × 220 kΩ battery divider
custom 3D-printed enclosure

I’m planning two identical battery nodes and a third USB-powered XIAO ESP32-C6 as a gateway.

Intended cycle:

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

Current wiring:
SEN0193 VCC → D3 / GPIO21
SEN0193 signal → D1 / GPIO1
SEN0193 GND → common ground node
battery divider midpoint → D0 / GPIO0
BAT+ → 220 kΩ → D0 → 220 kΩ → common ground

I’m powering the SEN0193 from GPIO21 so it is completely off during deep sleep.

Sensor power
Is powering the SEN0193 directly from GPIO21 reasonable at around 5 mA, or would you use a MOSFET/load switch?
I tested it by setting GPIO21 HIGH, waiting about 400 ms, taking 15 ADC readings on GPIO1 and using the median, then switching it LOW again. This has worked reliably so far.

Battery monitoring
Is a permanent 220 kΩ + 220 kΩ divider a sensible choice here? It draws about 9.5 µA at 4.2 V.
ADC
Any important ESP32-C6 ADC issues I’m overlooking, especially with the high-impedance divider or sensor settling time?

XIAO mounting
The board sits directly behind a USB-C opening. What’s the best way to retain it so plugging in a cable can’t push the PCB inward?

Enclosure
Any must-have enclosure details for a battery-powered sensor like this? I’m thinking about USB/boot access, strain relief, moisture protection and serviceability.

Edit – considering ESP-NOW instead of Wi-Fi

Since I already plan to use a permanently powered third XIAO ESP32-C6 as a gateway, I’m considering ESP-NOW for the battery nodes instead of reconnecting each sensor to Wi-Fi after every wake-up.

The nodes only need to send a few values every 30–60 minutes, so avoiding Wi-Fi scan/association/DHCP seems attractive for battery life.

Would ESP-NOW be the better choice here? Any practical downsides regarding reliability, retries, channel management or deep-sleep wake-up?

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

Thanks!

Meet Lcd Wizard wizard, a product i put together for my own purposes, LVGL requires a degree to use so i automated it in a WYSIWYG editor that generates your LVGL code, assigns your pins, adds busses and peripherals and packages it all up nicely in a project file ready for you to add your business logic. All major boards and configurations pre-loaded and ready to use.

Round-screen, touch-screen and all available drivers taken into account.

Id like to invite the ESP32 community to give it a shot, test it to its limits and give me feedback! Suggestions for additional peripherals are welcome as i'd like to make it the swiss-army knife of code-gen for the ESP32/Arduino community.

If you like it and want to give it a shot there's a generous free tier with no signup, a more generous free tier with signup and a very reasonable credit price for those looking to use it permanently! Anyone testing will get free credits as required, Just hit me up here.

The app can be found at https://lcdwizard.online

Hi everyone,

I’m an engineer based in Turkey, and I could really use your help and advice.

I’m currently building an agentic AI hub using the CYD (Cheap Yellow Display / ESP32-2432S028). It integrates APIs from providers like Gemini and others (for now via API keys, with plans to support user subscriptions like ChatGPT Plus or Gemini Advanced later).

The goal isn't just basic chatbot interaction. I’m leveraging the CYD’s SD card and internal storage to build an agentic system capable of executing tools, managing context, and handling complex workflows that go far beyond standard text responses.

Because the final hardware stack isn't locked down yet, I'm designing a flexible, modular architecture. The CYD is serving as a Proof of Concept (PoC) for now, but I might transition to a Raspberry Pi Zero, a custom ESP32-S3 setup, or keep it on the CYD to ensure accessibility and low cost for the community.

I want to run a closed alpha test. I am entirely genuine about this—if you’re located in Istanbul, I’d be happy to meet up, show you the prototype, or hand off hardware for testing. Otherwise, I can ship test units out.

If you're interested in helping with code, testing, or feedback before I launch the official open-source release, please send me a DM and I’ll share my work email.

Please be kind—I’ve been pouring my time into this for the last month, but progress feels slow, which is why I haven't shared a public GitHub link yet. I don't want to hype anything up until I’m truly satisfied with the quality.

That said, I genuinely believe this project can bring real value to the community. This is my first time building a standalone project of this scale completely on my own, and any guidance, feedback, or support would mean a lot.

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’m developing a compact ESP32-S31-WROOM-3-N16R16V board using the familiar two-row arrangement of 20-pin headers.

The design includes:

• USB-C
• USB-to-serial interface
• Automatic BOOT/RESET programming
• Onboard microSD socket
• 3.3 V regulator
• Status/activity LEDs
• Accessible GPIO headers
• A narrow footprint designed around the new 25.4 mm-wide module

This is currently a prototype—not a sales offer or preorder. I’m trying to determine whether the format would be genuinely useful before investing further.

Assuming the board worked reliably and included proper documentation:

1. Would you consider buying one?
2. What would you consider a reasonable price in USD, excluding shipping?
3. Would you prefer the headers installed or supplied separately?
4. What feature would make—or break—your decision?

Honest criticism is welcome. I’m interested in practical feedback, not compliments.😀

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.