ATCU-ESP32: How I Built a Custom Transmission Control Unit Smarter Than the Factory One

Hello, Habr! I published this article on Drive, but it's equally relevant here. This post is for car enthusiasts, but I also highly value feedback from embedded engineers.

P.S. Please also describe your pain points and needs regarding both firmware and functionality. I might still have time to address them before the first production version.

I have a toy — an old Japanese car with a 6-cylinder 3-liter turbo engine, starting with the letter S. I decided to manage the engine through a January 5.1 6-cylinder ECU running TRS251 firmware. But what to do with the ancient yet solid 4-speed A340LE automatic transmission? The factory control unit doesn't play nice with January. I needed a new brain for the transmission. So I built one. From scratch. And then it turned out that I wasn't the only one who needed it.

Why Not a "Dummy Box" or Ratcu? Engineering Sabotage.

Like many others, I started by studying what was already available. Dummy boxes are a crutch that offers no flexibility. Foreign control units are expensive and complicated. Domestic Arduino-based solutions (the so-called Ratcu) — the idea is close, but the execution... Reading through forums, I collected a whole spectrum of common ailments:

Sensor interference: Ignition coil operation turned the speed and RPM signals into a noisy mess.

Burning driver transistors: A solenoid is essentially a coil. Cut the current — and you get a hundred volts of back-EMF slamming into the collector. Without protection diodes and snubbers, the driver transistors don't last long.

Bounce and glitches: Weak power filtering, no hysteresis in the comparators for the sensors.

Stone-age tuning: COM port, ancient software, a mandatory laptop in the cabin.

It became clear: to build something for myself, I had to do it right. And if I'm doing it right — why not make it for others too?

From Soldering Iron to Laboratory: How Reliability Was Born

The idea of "I'll whip it up on my knee in three days" only worked for a proof-of-concept on a breadboard. For a production device, I had to set up an entire test proving ground.

1) A test bench instead of a car. I assembled a test bench with real solenoids from an automatic transmission, a selector bought from a Carina E at a junkyard, and a set of sensors. Figuring out the selector unlock electronics was a quest of its own — I had to untangle the intricate wiring of the contacts so that Park and Neutral would work flawlessly. I had to write a program on an Arduino to emulate vehicle operation (coolant sensor parameters, RPM, speed, throttle, etc.).

2) The war against interference — won. Instead of outdated circuits based on the LM1815, I used the MAX9926 chip. This thing was built for harsh automotive environments: built-in filters, short-circuit protection, clean hysteresis. The sensor signal is now crystal clear, even when spark plugs are arcing right next to it.

3) A power stage you can't kill. Each of the 8 channels (supporting S1, S2, S3, S4, SLU, SLT, SLC, SLN) consists of:

• An optocoupler at the input. Power supply breakdown? The control unit lives its own life, isolated and protected.
• A transistor with current headroom.
• A Schottky diode in anti-parallel to absorb the reverse voltage spike from the solenoid.
• A ceramic capacitor right at the drain for high-frequency noise.

Power supply fit for astronauts. The board receives "dirty" +12V from the vehicle's electrical system. Inside, it's met by an entire cascade of filters: ceramics (catching HF impulses), a 470 µF electrolytic capacitor (smoothing out voltage dips), a voltage regulator with a TVS diode (surge protection). A separate stabilized +5V is brought out to a connector for the sensors — no more hunting for "quiet" power in the wiring harness.

The Main Ace: Wi-Fi and a Web Interface. Goodbye, Laptop!

The heart of the system is the ESP32. This isn't just "an Arduino with Wi-Fi." It's a full-fledged platform. Once installed in the car, the unit broadcasts its own access point. You connect to it with your phone, open a browser — and you get a fully functional web interface.

What This Gives You:

Tuning from the couch: Shift maps, trigger thresholds, temperature correction — everything can be changed in a couple of taps on your phone.

Real-time dashboard: You can see the current gear, solenoid duty cycles, precise readings from speed, RPM, and transmission fluid temperature sensors. All of this — wirelessly.

Profiles for your project: Once you've dialed in the perfect shift map for a UAZ with an automatic transmission? Export the file. On the next UAZ — just import it. Hours of work saved.

Summary of the Unit's Functionality (Brief):

• Control of up to 8 solenoids (any combination of +12V / PWM GND).
• Connection for paddle shifters (tap shift) and brake light signal.
• Sensors: transmission output speed, engine RPM, ATF temperature.
• Import/export of settings.
• Full control and diagnostics over Wi-Fi.

What's Next?

Already in development: a CAN bus interface for data exchange with the engine ECU and instrument cluster, and a remote fine-tuning system (online tuning). I'm also planning to add over-the-air firmware updates. Basically, like updating a router.

Who Might Need This? (Spoiler: A Lot of People)

If you:

• Are swapping an engine to a controller that doesn't get along with the old automatic transmission (January, Bosch M7.3, etc.).
• Want to add paddle shifters to a classic automatic transmission.
• Professionally install automatic transmissions in non-standard projects (like the UAZ, for example).

P.S. The development is nearly at production quality. I'm finishing up the schematic revisions and running the first tests. Soon we'll be installing it in a Volga with a V8 engine from some Toyota and an A340 transmission.

If you have questions — ask in the comments, I'll try to answer.

Share this post with anyone who might find it useful. I need the feedback.

Also, please describe your pain points and needs regarding both firmware and functionality. I might still have time to address them before the first production version.