it is next to the usb input and when it heats up to about 55degrees celsius it probably shuts off entirely…. baby monitor

Complete tutorial with all files available 👇🏼 https://youtu.be/23EBLhm-rG8

Built an air mouse powered by the onboard IMU of the kode dot, turning hand movements into real-time cursor control.

Developed in PlatformIO + VS Code with the Arduino framework.

Runs on the kode dot, a pocket-sized dev board based on the ESP32-S3R, featuring 32 MB flash, 8 MB PSRAM, Wi-Fi, Bluetooth 5 LE, 2.13″ AMOLED display, LiPo battery, micro-SD, RGB LED, I²S mic and speaker, and 14 GPIOs.

The integrated 9-axis IMU (accelerometer + gyroscope) enables gesture-based input without external hardware.

Full example repo here: GitHub – AirMouse (github.com/kodediy/kodedot_examples/tree/main/AirMouse)

More about the project: kode.diy

Detailed docs on the device’s components and examples: Kode Docs

We are a small engineering team, developing POOM, an open-source ESP32-C6 multitool that started as a wireless pentesting device but evolved into something more versatile. Today I wanted to share one of its more creative applications: wireless motion-controlled MIDI drums.

Technical Implementation:

• Using the onboard 6-axis IMU (accelerometer + gyroscope) to detect gesture patterns

• Real-time quaternion calculations to determine strike velocity and direction

• BLE-MIDI protocol implementation for <10ms latency to DAW

• Custom threshold algorithms to prevent false triggers while maintaining responsiveness

The Hardware:

• ESP32-C6 (RISC-V core, WiFi 6, BLE 5.0, 802.15.4)

• 6-axis IMU for motion sensing

• NFC module

Other Modes: While the MIDI controller is fun, POOM actually has 4 operational modes:

1. Maker Mode -I2C/SPI, sensor reading

2. Zen Mode - BadUSB, BLE spam, WiFi tools

3. Gamer Mode - Macro keys, mouse jiggler, runs arduboy games.

4. Beast Mode - NFC cloning, advanced multi protocol sniffing

Happy to answer any technical questions about the implementation, especially the IMU processing or BLE-MIDI protocol details. Also curious if anyone has suggestions for other creative uses of the motion sensing capabilities!

I have this microcontroller and don't know what to do with this.

So… Qualcomm buying Arduino. I get the whole “more resources, fancy new boards, AI at the edge” pitch, but a bunch of red flags are popping up for me:

• Docs + blobs + dev vibes. Cool hardware means nothing if you’re stuck with sparse docs, binary blobs, or the classic “talk to a sales rep for details” wall. That’s not the beginner-friendly, dig-in-and-learn Arduino experience a lot of us grew up with.

• Does “open” actually stay open? Everyone promises the soul of Arduino won’t change after the press release. But acquisitions tend to drift toward proprietary tooling, preferred silicon, and tighter ecosystems over time. I really hope this doesn’t turn into “works best on Qualcomm” everything.

• Price creep + product drift. When an entry board starts looking like a tiny Linux computer with an MCU bolted on, you’re drifting away from the simple, affordable microcontroller roots. At that point you’re comparing it to a Pi or a $6 Pico and wondering where the value is for basic projects.

• Longevity + kernel support worries. The whole point of Arduino in classrooms and hobby projects is that stuff keeps working years later. Will OS images, kernels, and drivers actually stay current long-term, or will support taper off after the launch hype?

• Naming + shield confusion. Slapping “UNO” on wildly different hardware generations is asking for classroom chaos. Teachers and beginners just want to blink an LED or read a sensor without juggling OS images, new connectors, and gotchas.

• Telemetry / EULA / lock-in anxiety. I’m bracing for heavier cloud tie-ins, logins in the IDE, and “special accelerators” that only shine on one vendor’s chips. It always starts optional… until it quietly isn’t.

• Community culture risk. Arduino’s superpower is the vibe: examples that just work, libraries that are easy to use, shields you can stack, and a community that welcomes newbies. Under a big chip company, the fear is priorities tilt toward enterprise/industrial and the hobby/education side slowly gets less love.

I’d love to be wrong. If we get great docs, mainlined drivers, true long-term support, and first-class treatment for non-Qualcomm boards in the IDE, I’ll happily eat crow. But right now, the skepticism feels earned.

What are you doing? Sticking with classic Unos, jumping to Pico/ESP, or waiting to see if this turns into blob-city?

Used an ESP32 to build POOM a pocket multitool with 4 different modes. Just launched on Kickstarter.

What you're seeing: Zen Mode with BLE MIDI sending to GarageBand (button control only in this video). Motion control demo next week.

ESP32 is handling:

• BLE MIDI with full library

• 6-axis IMU for motion sensing

• OLED display

• USB HID emulation

• WiFi for MQTT/webhooks

Battery management

Other stuff it does:

• Maker Mode: MQTT, Qwiic sensors, FastAPI, n8n

• Gamer Mode: Media control, keyboard/mouse HID

• Beast Mode: WiFi/BLE sniffer, PCAP output

Firmware: ESP-IDF, fully open-source, OTA updates, web server for config. FOLLOW US on instagram for more updates

I just finished my first PCB assembly project and built this 8×8 RGB LED matrix.

I’ve always wanted to create my own Arduino modules instead of just buying ready-made ones, so I decided to start with this: a modular RGB panel that works with Arduino, ESP32, and similar boards using just one data pin.

You can also chain multiple panels together to make larger displays.

This started as a learning project, and seeing it light up for the first time was amazing.

I’ve open-sourced the entire project (files + code) because I want to help other makers go down the same path.

I also made a YouTube video sharing more details about how I built it and what I learned along the way.

Feedback and criticism are welcome. I’m still learning.

Christmas present

I asked him what microcontroller he is using. He said he made them himself. I'm not sure whether this is feasible for a normal person or just something lost in translation (he is from the Philippines or Indonesia)

If it's possible to make them oneself, how would you do it?

It had to be done.

I couldn't call Kode Dot a proper maker device without porting the classic benchmark.

The goal was to max out the ESP32-S3 capabilities for this port:

• Memory: Utilizing the 8MB PSRAM allows for smooth WAD loading and texture caching without hiccups.

• Display: Running on a 2.06" AMOLED Touchscreen. The deep blacks make the dungeons look way better than on standard TFTs.

• Audio: Full sound effects enabled via the onboard speaker (I2S).

• Controls: Mapped to physical tactile buttons (plus Neopixel feedback for damage/status).

The code is available on GitHub if you want to test the performance on your own S3 boards with similar specs.

Source Code (GitHub): https://github.com/kodediy/kodedot_SharedExamples/tree/main/Doom

Kode Dot device: https://www.kickstarter.com/projects/kode/kode-dot-the-all-in-one-pocket-size-maker-device/description

Documentation: https://docs.kode.diy/en/introduction

Already dumped the firmware from the eprom. Tried to disassemble the 8051 code. But guess it's to much efford. This board is connected to a monochromatic blue lcd with a flurescend tube backlight, there's is also a relay board connected to the ribbon cable to control pumps. I just want to showcase this board and want to know if anyone knows about these old dev boards, because i guess this was custom made. It has no silkscreen.

A few years back I made the kind of serial terminal which I had always wanted when doing embedded work. I finally got around to polishing it up enough to release to the world.

https://gitlab.com/kubark42/AeroTerm/

Alpha release with macOS/Linux/Windows binaries: https://www.reddit.com/r/microcontrollers/comments/osstgk/aeroterm_an_open_source_serial_terminal_for/

The primary feature which drove me to make this is the frustration at trying to figure out baud rates and other serial port settings. If you do enough embedded work you'll eventually find a device with an unknown serial port setting and you now have to figure it out.

Other serial terminals are a bit of a click-o-rama to change serial port settings, here they are up front and there's no need to close and reopen the serial port to try a new settings. Finding the baud rate for that five-year-old BT bridge device you had lying around is no longer a challenge!

Another nifty feature is the ability to record serial data and to play it back to the serial port at a user-configurable speed. This is really helpful for testing and debugging both firmware and cloud ends of the embedded pipeline.

Other features of interest:

• Simple and intuitive to use

• Search field for making patterns "pop"

• Visualizes in the data stream when the user sends data to the device

• Can be configured to send keyboard input immediately or in batch

• Saves the logfile in base64 encoding in a JSON file.

• Playback speed can be adjusted. This is very helpful for reproducing embedded hardware errors..

• Change serial port settings without forcing the user to close and re-open the port. Saves clicks!

The software is a classic Qt project, done in a mix of C++, QML, JS. If you don't want to download one of the binaries, ou can compile it yourself by simply opening the project in Qt Creator and hitting the build button. There's no special software requirement beyond a standard Qt SDK install. I have built it on Qt 5.15, but I see no reason why it wouldn't work with Qt 6.

I'd love feedback. The terminal is feature complete, although the UI is raw. I figured there was no point in getting the components into their pixel perfect place only to dramatically move things around based on real-world feedback.