- I am a student who enjoys building things, understanding systems, and learning by going deeper than the first explanation.
+ I am an Electrical & Electronics Engineering student at Bülent Ecevit University who builds hardware, writes low-level C and Rust software, and learns by going deeper than the first explanation.
@@ -53,21 +53,18 @@
01 // Who I Am
Learning by Building and Investigating
- My interests span both hardware and software. I do not want to limit myself to only one layer of a system. I want to understand how physical components, electronics, firmware, and higher-level software work together.
+ My interests span both hardware and software. I do not want to limit myself to only one layer of a system—I want to understand how physical components, electronics, firmware, and higher-level software work together.
- I am currently studying embedded systems, circuit analysis, C programming, and technical reporting. In the future, I want to study Assembly and continue developing my programming skills with C++, Python, Rust, and other technologies.
+ Right now, my active work centers on ESP32 / ESP32-S3 embedded systems in ESP-IDF (ISO C99 & FreeRTOS), circuit analysis, KiCad schematic capture, Python hardware tooling, and Rust systems programming on Arch Linux.
- I love open source, freedom, and making things that are useful, unusual, or simply fun. I am using this website to document my progress, express myself, share what I build, and find people who enjoy learning and creating together.
-
-
- I am currently studying Electrical and Electronics Engineering at Bülent Ecevit University. I am still exploring my exact future specialization, but I am especially interested in areas where hardware, software, human judgment, and practical engineering meet.
+ I love open source, freedom, and making things that are useful, unusual, or simply fun. I use this website to document my progress, share real schematics and firmware, and connect with people who enjoy building and learning together.
-
+
Connecting physical circuits, low-level code, and high-level software tools rather than treating them as separate worlds.
@@ -88,68 +85,54 @@
I often think about technology through a simple car analogy: if I want to drive a car responsibly, I should understand at least the basics of its steering, dynamics, brakes, and other important systems. If I understand how the car works and how to drive it, I can make good decisions, recognize problems early, teach someone else, and know what to ask for when something needs attention.
- I want to approach AI in the exact same way. I know AI is changing both hardware and software workflows, and I use AI tools when experimenting. However, I do not want to use AI blindly. I want to understand systems deeply enough to guide AI, evaluate its output, recognize mistakes, and take responsibility for the final result.
-
-
-
-
- 03 // Looking Under the Hood
-
Learning Reverse Engineering Honestly
-
- I am also interested in reverse engineering, and I am interested in understanding how software and systems work internally. I am still learning reverse engineering and experimenting with reverse-engineering tools—I do not pretend to be an expert.
-
-
- So far, I have experimented with tools such as Cheat Engine, Ghidra, and x64dbg to investigate and configure aspects of online game mechanics. In some of those experiments, AI tools generated or helped with parts of the code, and I did not yet fully understand every part of the underlying code that was produced.
-
-
- Being honest about that gap is important to me: that experience is actually what pushed me to study low-level programming, C, and future Assembly more seriously. My goal is not to pretend that I already understand everything—my goal is to understand more each time I investigate a system.
+ I approach AI in the exact same way. I use AI tools when experimenting, but I do not want to use AI blindly—I want to understand the hardware registers, pin strapping rules, and software architecture deeply enough to evaluate output critically and take full responsibility for the final system.
- This is where I document project build logs, embedded systems learning, circuit experiments, C programming notes, reverse-engineering learning, and honest reflections on what worked and what failed.
-
-
- Honest status note: This blog is a manually maintained static notebook. While I prepare my first full technical build logs, the entries below are clearly labeled as an Example / Starter Note and a reusable Template / Draft so nothing here pretends to be a finished achievement before it is written.
+ Where I document hardware build logs, ESP-IDF firmware architecture, circuit debugging stories, and honest reflections on what worked and what failed.
@@ -71,25 +68,22 @@
-
-
+
+
- Example • Work in progress
+ Starter Note• 3 min read
- Category: Personal Learning Reflections & Open-Source Ideas
-
-
- An introductory note explaining why I redesigned my site as a calm, honest workshop for hardware, software, C programming, and project build logs rather than a corporate résumé.
+ An introductory note explaining why I designed my site as an open engineering studio for hardware, embedded C firmware, and project build logs rather than a corporate résumé.
- A ready-to-copy static HTML article template containing placeholders for title, date, category, tags, reading time, what worked, what failed, and related project links.
+ A reusable static HTML article template containing sections for hardware schematics, firmware architecture, what worked, what failed, and related project links.
-
template
-
draft
-
build-log
+
template
+
build-log
@@ -125,25 +115,13 @@
-
- Upcoming Notebook Topics
-
What I Plan to Write About Next
-
-
MIDI project development: How my conversion script turns MIDI data into C code for two active buzzers, one passive buzzer, and a 1.3-inch AMOLED display.
-
RC controller & autonomous vehicle notes: Build logs and hardware-software integration lessons as components are tested.
-
Embedded systems & circuit experiments: Notes from studying circuit analysis, C programming, and future Assembly experiments.
-
Reverse-engineering learning notes: Beginner investigations using Cheat Engine, Ghidra, and x64dbg to understand how software works internally.
-
What worked and what failed: Honest debugging stories and lessons learned when guiding and verifying AI-generated code.
- I want visitors here to feel like they are meeting a friend or an engineering teammate. If you enjoy building things, learning deeply, or talking about how hardware and software work together, I would be happy to connect.
+ Whether you want to talk about ESP32 embedded firmware, circuit design, Linux systems programming, or open-source hardware collaboration, feel free to reach out directly via Gmail, LinkedIn, or GitHub.
- Follow my open-source repositories, check out my ongoing code and hardware-software projects, or open an issue/discussion on a repository.
+ My primary personal and engineering Gmail inbox. Ideal for project discussions, schematic/code questions, internship or collaboration inquiries, and fellow student builders.
+
- Explore the source code for this static workshop website or my ongoing Multi-Functional RC Controller project:
+ Browse my ESP-IDF C99 firmware, KiCad hardware schematics, Python MIDI RLE compilers, and Rust Linux desktop tools, or connect with me on LinkedIn.
+ Standalone Linux desktop launcher written in Rust to run Point Blank with 100% unmodified official CheatBlocker anti-cheat, automated Wine prefix setup, and DirectX 9/11.
+
Open-source projects, learning in public, and using AI responsibly by understanding the underlying system
+
Embedded Systems & Electronics: ESP32 / ESP32-S3, ESP-IDF, FreeRTOS, SPI/I2C/PWM/PCNT peripherals, schematic capture, and breadboard-to-perfboard builds.
+
Systems Programming: ISO C99, C++, Rust, Python hardware tooling, and low-level memory/assembly analysis.
+
RF Telemetry & Robotics: 2.4 GHz nRF24L01+ wireless control links, Hall-effect gimbals, and 4WD autonomous vehicle control loops.
+
Reverse Engineering & Linux Internals: Studying binary behavior with Ghidra, x64dbg, Cheat Engine, and Wine/Proton runtime compatibility on Arch Linux.
-
-
- Future Community Note
-
- In the future, after this static portfolio and blog have grown with more project logs and articles, I hope to add a small community discussion space where people can talk about projects and experiments directly. For now, the site stays 100% static and simple, and GitHub is the best place to reach me.
-
+ ⚡ ELECTRICAL & ELECTRONICS ENGINEERING // OPEN WORKBENCH
+
Hi, I’m Ertunç Özbay.
- I build things, take systems apart, and learn how hardware and software work together.
+ I design embedded hardware, write bare-metal C & FreeRTOS firmware, and build open-source systems from the transistor level up to Linux desktop tooling.
- This is my personal workshop for embedded systems, electronics, software, reverse engineering, open-source projects, and the lessons I collect while building. I enjoy making useful, strange, and sometimes purely fun things while documenting what works, what fails, and how each system develops.
-
-
- Hardware + software learner • Open-source enthusiast • Student builder
+ Welcome to my engineering studio and notebook. Here I document my real hardware prototypes—from an ESP32-S3 2.4 GHz Multi-Functional RC Console and a Dual-Core ESP32 16-Track MIDI Synthesizer to a 4WD Autonomous Vehicle and a Standalone Linux Game Launcher written in Rust.
- An ongoing project focused on RC control and hardware-software integration, built to understand how physical inputs and control logic work together.
+ A handheld 2.4 GHz wireless transmitter and embedded control console powered by an ESP32-S3-N16R8 (16 MB Flash / 8 MB Octal PSRAM), nRF24L01+ PA+LNA RF transceiver, dual K-Silver Hall-effect gimbals, and shared SPI2 1.3" ST7789 IPS TFT + MicroSD bus.
- An ongoing project exploring RC control and autonomous vehicle behavior across electronics, control logic, and software.
+ A standalone dual-core ESP32 MIDI synthesizer, drum sequencer, and 30 FPS SPI OLED visualizer with a custom Python RLE MIDI-to-C compiler (midi_to_c.py), hardware PCNT rotary encoder, passive melody piezo, and dual active drum buzzers.
- A breadboard-based project that plays MIDI melodies by converting MIDI data into C code for the device, driving buzzers, an AMOLED display, and physical controls.
+ A companion 4WD robotic vehicle platform designed to pair with the 2.4 GHz Multi-Functional Controller while exploring closed-loop motor control, telemetry feedback, and autonomous obstacle-avoidance logic.
+ An all-in-one standalone Linux desktop launcher written in Rust that runs Point Blank (Zepetto / TAM) on Linux with 100% unmodified official CheatBlocker anti-cheat, automated Wine prefix provisioning, and DirectX 9 / DirectX 11 support.
+
- I do not want to understand only one isolated layer of a system. I study how physical components, circuits, C code, and software tools connect so I can make informed decisions and take responsibility for what I build.
+ From decoupling capacitors, BJT switches, and SPI bus arbitration up to FreeRTOS tasks and Python/Rust tooling—I study how every layer connects so I can take full ownership of what I build.
- Not every experiment begins as a polished project. The Lab page holds my current circuit tests, MIDI-to-C conversion scripts, reverse-engineering learning notes, and open technical questions.
+ Explore my active breadboard tests, RLE MIDI-to-C compression algorithms, hardware protection fixes, and reverse-engineering study notes.
- A manually maintained notebook for build logs, C programming notes, embedded experiments, and honest reflections on what worked and what failed along the way.
+ Reach out directly via Gmail (ertuncozbayh@gmail.com), Outlook, LinkedIn, or GitHub to discuss embedded systems, electronics, or open-source builds.
- Welcome to my open workbench. Not everything I do starts as a structured project—this page tracks my ongoing hardware experiments, conversion scripts, reverse-engineering learning notes, playful breadboard builds, and the technical questions I am currently investigating.
+ Welcome to my open workbench. This page tracks my real engineering experiments, hardware debugging breakthroughs, Python/Rust tooling scripts, and reverse-engineering study notes.
@@ -53,167 +53,102 @@
- 01 // Active Bench
-
Current Experiments
+ 01 // Active Bench Breakthroughs
+
Recent Hardware & Firmware Experiments
-
+
- On the Breadboard
- Hardware + C
+ Solved on Breadboard
+ ESP32 Dual-Core • Python RLE
- Testing how two active buzzers and one passive buzzer behave together on a breadboard alongside a 1.3-inch AMOLED screen, a rotary encoder, two buttons, and two LEDs as part of my MIDI Breadboard Instrument.
+ While building the 16-Track MIDI Breadboard Instrument, raw MIDI delta-slices caused the LEDs and 1.3" SPI OLED to strobe violently. Writing a custom Run-Length Encoding (RLE) compressor in Python (midi_to_c.py) and transposing bass-heavy tracks like Seven Nation Army +2 octaves solved both flash exhaustion and piezo acoustic roll-off.
-
+
- Ongoing Study
- Control & Integration
+ Hardware Rev 0.1 → Phase 2
+ ESP32-S3-N16R8 • SPI2 Bus
- Exploring how physical inputs on my Multi-Functional RC Controller and control logic for my RC and Autonomous Vehicle can be organized cleanly across hardware and software.
+ On the Multi-Functional RC Controller, the ESP32-S3-N16R8 reserves GPIO 35–37 for internal Octal PSRAM/Flash. We remapped the shared SPI2 bus (MOSI: 11, MISO: 13, SCK: 12) with dedicated hardware CS lines for the nRF24L01+ (CSN: 10), MicroSD (CS: 39), and ST7789 IPS TFT (CS: 40).
-
-
-
-
- 02 // Physical Layer
-
Hardware Experiments
-
-
-
-
-
-
Circuit Analysis & Breadboard Prototyping
-
- Connecting classroom circuit analysis concepts to real breadboard setups—watching how physical components, buttons, encoders, buzzers, and indicator LEDs behave in practice.
-
-
-
-
-
-
-
Physical Computing Interfaces
-
- Experimenting with tactile hardware inputs (rotary encoders and push buttons) and compact displays (such as a 1.3-inch AMOLED screen) to make embedded builds interactive without relying on a PC screen.
-
-
-
-
-
-
-
+
- 03 // Code & Tooling
-
Software and Conversion Tools
-
-
-
-
-
-
MIDI-to-C Code Conversion Script
-
- A custom script I wrote that takes MIDI data and converts it into C code for my breadboard instrument. It bridges higher-level musical data with low-level C arrays that the hardware can play directly.
-
-
-
-
-
-
-
C Programming & Future Language Exploration
-
- Practicing C programming for embedded systems now, while preparing to study Assembly for deeper low-level understanding and expanding my toolkit with C++, Python, and Rust.
-
-
-
-
-
-
-
-
-
-
- 04 // System Internals
-
Reverse-Engineering Learning
-
-
-
- Beginner Learning Log
-
- I am learning reverse engineering and experimenting with reverse-engineering tools because I am interested in understanding how software and systems work internally.
-
-
-
Tools I have experimented with: Cheat Engine, Ghidra, and x64dbg.
-
What I tried: Investigating and configuring aspects of online game mechanics.
-
Honest reflection: In some of these experiments, I used code generated with the help of AI tools and realized I did not yet understand every line of the underlying code. That realization motivated me to study C, memory concepts, and future Assembly systematically so I can read and verify what happens under the hood myself.
-
-
-
-
-
-
-
-
- 05 // Playful Curiosity
-
Unfinished or Playful Builds
-
-
-
- I believe some of the best learning happens when building things that are unusual, playful, or simply fun. Playing MIDI melodies across two active buzzers and one passive buzzer on a breadboard started from that exact spirit—combining music, C code, and electronics just to see how far a breadboard setup can go.
-
-
-
-
-
-
-
- 06 // Open Questions
-
Questions I Am Currently Investigating
+ 02 // Code & Systems Tooling
+
Custom Compilers & Linux Runtime Tools
-
+
-
How do C constructs map to Assembly and hardware?
+
+ Rust • Linux x86_64
+ Wine & DirectX 11
+
+
16-Byte TLS Alignment for DirectX 11 on Linux
- As I study C programming and prepare to learn Assembly, how do compiled functions, memory layouts, and hardware registers look when inspected inside tools like Ghidra or x64dbg?
+ In pointblank-linux, we engineered a standalone Rust launcher that automatically provisions a 16-byte TLS-aligned ntdll.dll runtime and vcrun2022 / d3dx11_43 components so Point Blank runs at 200 FPS in DirectX 11 on Linux with unmodified official CheatBlocker anti-cheat.
-
+
-
How can we use AI tools without losing deep system understanding?
+
+ Python 3 • mido
+ Embedded Audio Tooling
+
+
RLE MIDI-to-C Struct Compiler (midi_to_c.py)
- What foundational knowledge across electronics, firmware, and software is essential so a builder can guide AI effectively, spot subtle bugs, and stay fully responsible for the system?
+ Converts multi-channel `.mid` files into compact C99 SequenceStep struct arrays (`{frequency, duration, kick_drum, hi_hat}`), automatically routing MIDI Channel 10 and low bass notes (`< MIDI 50`) to hardware percussion buzzers.
+
+
+
+
+ 03 // System Internals
+
Reverse-Engineering & Low-Level Study Log
+
+
+
+ Looking Under the Hood
+
+ I study reverse engineering using Ghidra, x64dbg, radare2, and Cheat Engine to understand how compiled C/C++ binaries, memory layouts, calling conventions, and hardware registers work at the machine instruction level.
+
+
+ Every time I inspect a compiled binary or debug an ESP32 panic backtrace, it reinforces why deep knowledge of C, memory alignment, and Assembly is indispensable.
+
- Here are the three real projects I am currently building and documenting. Because I value honesty in technical documentation, each project page lists only confirmed components and real progress—never invented specifications.
+ Every project documented here is backed by real hardware on my bench or shipped open-source code on my GitHub—complete with verified pinouts, schematics, build photos, and dedicated slots for upcoming YouTube Proof-of-Concept (PoC) demonstration videos.
- An ongoing RC controller project focused on remote control hardware and hardware-software integration.
+ A custom 2.4 GHz wireless remote controller and multi-purpose embedded console built around the ESP32-S3-N16R8 and nRF24L01+ PA+LNA transceiver. Currently built as an early Rev 0.1 perfboard carrier and transitioning into a DT-100 (190×137×59 mm) desktop console with dual K-Silver Hall-effect gimbals and a 1.3" ST7789 IPS TFT display.
-
Confirmed technologies & focus:
-
RC Control
-
Hardware-Software Integration
-
Open-Source Repo
+
ESP32-S3-N16R8
+
ESP-IDF v5.2.2 (C99)
+
nRF24L01+ 2.4 GHz RF
+
Hall-Effect Joysticks
+
ST7789 TFT + MicroSD
+
KiCad Schematic
-
What I am currently learning: Structuring an RC controller system so physical inputs and control software stay reliable and modular.
-
Next step: Documenting confirmed hardware choices, wiring notes, and iteration logs as testing progresses.
+
Includes on page: 3 early prototype build photos, full KiCad SVG schematic, verified ESP32-S3 GPIO pinout, Phase 2 DT-100 BOM, and 🎬 YouTube PoC Video Placeholder.
- An ongoing project exploring RC control and autonomous vehicle behavior. This project is part of my effort to understand systems across electronics, control logic, and software.
+ A standalone dual-core ESP32 MIDI synthesizer, drum sequencer, and 30 FPS SPI OLED visualizer programmed in ESP-IDF v5.2.2, paired with a custom Python Run-Length Encoding (RLE) MIDI-to-C compiler (midi_to_c.py) driving a passive melody buzzer, two active drum buzzers, LEDs, and a hardware PCNT rotary encoder.
-
Confirmed technologies & focus:
-
-
RC Control
-
Autonomous Behavior Exploration
-
Electronics
-
Control Logic & Software
-
-
-
-
What I am currently learning: How manual RC control and autonomous decision logic interact with physical vehicle electronics.
-
Next step: Confirming and testing the hardware platform before publishing specific sensor or controller details.
- A breadboard-based project that plays MIDI melodies by converting MIDI data into C code for the device. The hardware currently includes two active buzzers, one passive buzzer, a rotary encoder, a 1.3-inch AMOLED display, two buttons, and two LEDs.
-
-
-
Confirmed components & tools:
-
ESP32 Dual-Core (ESP-IDF v5.2.2)
-
Python RLE MIDI-to-C Compiler
-
16-Track Flash Symphony
-
2x Active Buzzers (Kick/Hat)
-
1x Passive Buzzer (LEDC PWM)
-
1x Rotary Encoder (PCNT)
-
1.3" SPI OLED (30 FPS)
-
2x Buttons & 2x LEDs
+
ESP32 Dual-Core (160 MHz)
+
Python RLE Compiler
+
16-Track Flash Symphony
+
3x Buzzers (Melody/Kick/Hat)
+
1.3" SPI OLED (30 FPS)
+
PCNT Rotary Encoder
-
What I am currently learning: RLE compression of fragmented MIDI events into C struct arrays, acoustic transposition (+2 octaves) for passive piezo resonance, and Dual-Core FreeRTOS IPC between Core 0 (30 FPS OLED UI) and Core 1 (microsecond audio engine).
-
Next step: Migrating the dual-breadboard prototype onto a soldered perfboard or custom KiCad PCB.
+
Includes on page: 3 high-res breadboard photos, 16-track playlist table, ESP32 pinout, RLE compression architecture, and 🎬 YouTube PoC Video Placeholder.
+ An ongoing 4WD robotic vehicle platform exploring manual 2.4 GHz RF remote control (paired with the Multi-Functional Controller) alongside autonomous obstacle avoidance, motor driver electronics, and real-time control logic.
+
+
+
+
4WD Vehicle Platform
+
2.4 GHz RF Receiver Link
+
Autonomous Control Logic
+
Power & Motor Electronics
+
+
+
+
Includes on page: System scope, manual-to-autonomous control transition notes, and 🎬 YouTube PoC Video Placeholder.
+ A self-contained Linux desktop launcher written in Rust that runs Point Blank (Zepetto / TAM Game) on Arch, Ubuntu, and Fedora with 100% unmodified official CheatBlocker anti-cheat, automated Wine prefix & Winetricks provisioning (vcrun2022, d3dx11_43), and 200 FPS DirectX 9 / DirectX 11 borderless fullscreen support.
+
+
+
+
Rust
+
Wine / DirectX 9 & 11
+
16-Byte TLS Runtime
+
Arch / Debian / Fedora
+
+
+
+
Includes on page: Architecture overview, Wine prefix automation breakdown, release links, and 🎬 YouTube PoC Video Placeholder.
A standalone, dual-core ESP32 MIDI synthesizer, drum sequencer, and 30 FPS SPI OLED visualizer written in ESP-IDF v5.2.2 (C99 / FreeRTOS), powered by a custom Run-Length Encoding (RLE) Python MIDI-to-C compiler.
@@ -59,14 +59,33 @@
What started as making a passive piezo buzzer squeak evolved into a full 16-track embedded music box with live kick/hi-hat drum transients, hardware PCNT quadrature rotary controls for real-time tempo and volume scaling, and dual-core FreeRTOS task isolation.
+ Upcoming YouTube video showcasing live playback across the 16-track flash playlist (Careless Whisper, Rondo Alla Turca, Seven Nation Army +2 octave transpose), real-time rotary speed/volume tweaking, and synchronized kick/hi-hat buzzers + LEDs.
+
-
+
+ Full Breadboard Layout: Dual-breadboard build featuring the ESP32 DevKit, 1.3" 7-pin SPI OLED display, KY-040 rotary encoder, tactile buttons, passive melody piezo, and dual active drum buzzers.
-
-
+
+ 30 FPS Live OLED Visualizer: Custom 5×7 font renderer displaying track code (WHISP), rotary mode (SPD / VOL), kick/hi-hat drum boxes, and dynamic frequency bars.
-
-
+
+ Controls & Acoustic Stage: Close-up of the rotary encoder, Play/Pause and Next Track buttons, green/red drum LEDs, and the 3-buzzer audio stage.
@@ -195,14 +214,13 @@
05 // Workshop Notes & Next Steps
Current State & Roadmap
-
- Current State
+
+ Current State & Next Steps
The firmware is rock-solid on the breadboard: the rotary encoder dynamically scales volume and tempo via lockless IPC variables, all 16 tracks play from flash memory, and the 1.3" SPI OLED renders real-time frequency bars and drum hits at 30 FPS.
- Next Steps
- Migrating the dual-breadboard circuit onto a soldered perfboard or custom KiCad PCB, and optionally re-integrating a WS2812B addressable RGB strip when expanding the enclosure.
+ Next Step: Migrating the dual-breadboard circuit onto a soldered perfboard or custom KiCad PCB.
- An ongoing project related to RC control and hardware-software integration.
+ A custom 2.4 GHz wireless transmitter and embedded control console powered by an ESP32-S3-N16R8 (Dual-Core LX7 @ 240 MHz, 16 MB Flash, 8 MB Octal PSRAM) and an nRF24L01+ PA+LNA RF transceiver.
+
+
+ Designed to serve as a universal handheld and desktop transmitter for external robotic platforms (such as my 4WD RC & Autonomous Vehicle) while integrating dual K-Silver Hall-effect joysticks, a 1.3" ST7789 IPS TFT display, MicroSD storage, and MAX4466 audio capture.
- The Multi-Functional RC Controller is an ongoing hardware-and-software build where I explore how a single remote controller can be designed, programmed, and adapted for practical RC applications.
-
-
- Rather than treating a controller as a sealed black box, I want to understand both the physical interface and the software logic that translates user input into control actions.
-
+ Note: The photos below show the very early Phase 1 (Rev 0.1) perfboard carrier build (click any image to zoom). Currently populated: female/male pin header sockets, 100 µF electrolytic bulk decoupling capacitor, ESP32-S3-N16R8 module, nRF24L01+ 2.4 GHz radio header, and 3.3V/5V/GND power distribution rails. These photos will be updated as the Phase 2 DT-100 desktop console modules are installed.
+
+
+
+
+
+ Top View (Rev 0.1): Early perfboard carrier showing dual 22-pin female header sockets for the ESP32-S3, power rail pin headers, and the 100 µF bulk capacitor.
+
+
+
+
+
+ RF Transceiver Profile: Side profile with the nRF24L01+ PA+LNA 2.4 GHz module and external SMA whip antenna mounted on the carrier.
+
+
+
+
+
+ Bottom Solder Routing: Hand-soldered point-to-point bus and power distribution traces on the underside of the phenolic perfboard.
+
+
+
+
+
+
+
+ 02 // Hardware Schematic Capture
+
Early KiCad 9.0 Schematic (mfc-1.svg)
+
+
+
+ Early prototype KiCad schematic (mfc-1.kicad_sch) — click to zoom full-screen.
+
+
+
+
+
+
+ 03 // Verified ESP32-S3-N16R8 Pinout & Bus Architecture
+
Master Node GPIO Allocation
+
+ Because the ESP32-S3-N16R8 reserves GPIO 35–37 internally for its 8 MB Octal PSRAM and 16 MB SPI Flash, all peripherals are mapped across safe ADC1, SPI2, and PCNT pins:
+
- How physical control inputs, embedded software structure, and clear technical documentation come together when designing a custom controller from scratch.
-
- Next Step
-
- Details will be documented as the project develops. As each hardware stage and software iteration is tested on the bench, I will publish confirmed component lists and build logs here and in the Blog.
+ The controller is transitioning from the bare Rev 0.1 perfboard carrier into a professional desktop console housing. Once the Phase 2 components below are mounted, the ESP-IDF firmware will be updated with drivers for each module:
+ Status: v1.0.0 Released
+ Project 04 // Rust • Linux Systems • Wine & DirectX 9/11
+
+
Point Blank on Linux — Standalone Community Launcher
+
+ An all-in-one standalone Linux desktop launcher written in Rust that runs Point Blank (Zepetto / TAM Game) on Linux with 100% unmodified official game files and native CheatBlocker anti-cheat (CB.exe + CB.cbm).
+
+
+ Built on Arch Linux without requiring Heroic, Lutris, or external wrappers—featuring automated Wine prefix & Winetricks provisioning, 16-byte TLS-aligned runtime support for DirectX 11, multi-region authentication, and native 1920×1080 borderless fullscreen at 200 FPS.
+
Point Blank Running Natively on Arch Linux (DX11 / 200 FPS / Official CheatBlocker)
+
+ Upcoming YouTube proof-of-concept gameplay and setup walkthrough showing prefix auto-provisioning, DirectX 11 200 FPS performance on Linux, and unmodified CheatBlocker anti-cheat execution.
+
+
+
+
+
+
+ 01 // Systems Engineering Overview
+
Solving Low-Level Windows-on-Linux Compatibility
+
+ Running legacy 32-bit/64-bit online Windows games with kernel/user-mode anti-cheat modules like CheatBlocker on Linux often fails due to unaligned Thread Local Storage (TLS) allocations in `ntdll.dll`, missing Visual C++ MFC redistributables, and broken WebView2 login flows.
+
+
+
16-Byte TLS-Aligned Runtime for DirectX 11: Automatically provisions a 16-byte TLS-aligned `ntdll.dll` Wine runtime so both DirectX 9 (`DXVersion = 9`) and DirectX 11 (`DXVersion = 11`) render cleanly without crashes.
+
One-Click Isolated Prefix Provisioning: Configures `~/.local/share/pointblank-linux/prefix` with `vcrun2022` (`mfc140.dll`, `msvcp140.dll`, `vcruntime140.dll`), `d3dx9_31..43`, `d3dcompiler_43`, `d3dx11_43`, and Edge WebView2 (`109.0.1518.78`).
+
In-Game `F11` Borderless Fullscreen Helper: Compiles a lightweight MinGW-w64 helper utility for instant 1920×1080 borderless fullscreen switching at 200 FPS.
+
+
+
+
+ 02 // Technical Specifications
+
Confirmed Capabilities & Supported Distros
+
+
+
+
Subsystem
+
Specification
+
+
+
+
+
Primary Language
+
Rust (Standalone Linux `x86_64` executable)
+
+
+
Anti-Cheat Compatibility
+
100% Unmodified Official CheatBlocker (`CB.exe` + `CB.cbm`)
- Status: In progress
- Project 02 // Electronics, Control Logic & Software
+ Status: In Progress
+ Project 03 // 4WD Robotics, Control Logic & 2.4 GHz Telemetry
-
RC and Autonomous Vehicle
+
RC and Autonomous 4WD Vehicle
- An ongoing project exploring RC control and autonomous vehicle behavior. This project is part of my effort to understand systems across electronics, control logic, and software.
+ A standalone 4WD robotic vehicle project exploring manual 2.4 GHz wireless control (paired with my Multi-Functional RC Controller) and autonomous obstacle-avoidance behavior.
4WD RC & Autonomous Vehicle — Wireless Drive & Control Loop Test
+
+ Upcoming YouTube demonstration covering 2.4 GHz remote drive response from the Multi-Functional Controller, motor driver PWM tuning, and autonomous mode switching.
+
+
+
+
+
01 // Overview
Why I Am Building This
- A vehicle project sits right at the intersection of the subjects I care about most: physical electronics, control logic, and software decision-making. If a software routine makes a bad assumption, you see it immediately in how the physical vehicle behaves.
+ A physical vehicle sits right at the intersection of the subjects I care about most: power electronics, closed-loop control logic, and real-time embedded decision-making. If a firmware routine makes a bad timing assumption or power transients aren't filtered properly, you see it immediately in how the vehicle behaves on the floor.
- Through this ongoing build, I want to explore both manual RC control and autonomous behavior step by step, connecting what I study in circuit analysis and embedded programming to a moving system.
+ This project is maintained strictly separate from the transmitter console so that the vehicle node and the Multi-Functional RC Controller communicate over a clean, modular 2.4 GHz packet protocol.
@@ -85,19 +105,19 @@
Project Name
-
RC and Autonomous Vehicle
+
RC and Autonomous 4WD Vehicle
Status
-
In progress
+
In progress (Hardware & control loop integration)
-
Areas Explored
-
RC control, autonomous behavior, electronics, control logic, and software
Details will be documented as the project develops and components are confirmed through testing.
+
Core Focus Areas
+
Manual 2.4 GHz RC drive, autonomous behavior exploration, motor drive electronics, and embedded control software
@@ -106,14 +126,14 @@
03 // Workshop Notes
What I Am Currently Learning & Next Steps
-
+
What I Am Currently Learning
- Understanding how electronics, control logic, and software layers depend on one another when transitioning between manual remote control and autonomous vehicle behavior.
+ Understanding how power supply decoupling, motor driver PWM control, and wireless telemetry packets interact when transitioning smoothly between manual remote control and autonomous vehicle behavior.
Next Step
- Details will be documented as the project develops. I am keeping this page strictly grounded—only adding sensors, microcontrollers, communication protocols, and test results after I confirm them on the workbench.
+ Publishing the dedicated vehicle repository, chassis photos, and the YouTube Proof-of-Concept drive video once bench and floor testing are complete.
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+