There is a specific kind of bug that only shows up when you remove something. Not when you break it, not when you misconfigure it, but when you take it out entirely and discover that it had a second job nobody wrote down.
I spent a few months this year replacing the engine computer in a 2001 Dodge Stratus with a Speeduino DropBear v2, an open-source standalone ECU. I planned it carefully. I mapped every pin. I wrote a note titled “Confirmed so far.” Then I turned the key and got nothing at all.
The answer was three sentences further down in my own notes, in a warning I had written to myself and then argued my way out of.
The setup: why not just replace the computer?
The obvious plan for a standalone ECU swap is: unplug the factory box, plug in the new box, drive away. That does not work here, and the reason is the transmission.
The Stratus has a 41TE four-speed automatic. Early in the project I assumed, as a lot of online writeups will tell you, that this generation of Chrysler used a single combined SBEC III module handling both engine and transmission. If that were true, replacing it would mean also replacing the transmission controller, which means building a shift strategy from scratch for a torque converter I know nothing about.
That assumption was wrong, and finding out it was wrong was the first good thing that happened in this project. The 2.4L automatic actually has a separate PCM (engine) and TCM (transmission). They talk to each other over the Chrysler PCI bus, plus one direct wire. That’s a much better situation than a combined module, but it comes with a catch.
The TCM does not have its own sensors. It schedules shifts based on engine data (RPM, throttle position, MAP, coolant temperature) that the PCM broadcasts onto the PCI bus. Take the PCM away and the TCM goes deaf.
So the architecture I settled on was: leave the factory PCM physically installed and powered, hand the engine over to the DropBear, and let the PCM keep doing its second job as a sensor aggregator and bus broadcaster for the transmission. Two computers on one engine, deliberately, with a clear line drawn between them.
Drawing the line
That line has to be drawn pin by pin, and the pins fall into two very different categories.
Inputs get shared. Both computers need to know engine speed, throttle position, and manifold pressure. The sensors stay wired to the PCM exactly as the factory left them, and I tee the signal wire off to the DropBear as a second, high-impedance listener. The PCM keeps supplying power and ground to the sensor; the DropBear just reads the voltage.
Outputs get handed over cleanly. Injectors, coils, idle air control, fuel pump relay: these move to the DropBear entirely. The PCM’s original drive pins for them get disconnected and go dead.
A few rules fell out of this that are worth writing down, because they are not obvious until you think about the electrical topology:
- Hall-effect sensors (crank, cam) tee just fine. They’re digital, they’re low-impedance sources, and a second high-impedance input doesn’t load them meaningfully.
- 5V analog sensors (TPS, MAP) tee fine too, for the same reason.
- NTC thermistors do not. Coolant and intake air temperature sensors are just resistors. The ECU reads them by putting them in a voltage divider with an internal pullup resistor. Wire two ECUs to one thermistor and you now have two pullups in parallel, the divider ratio changes, and both computers read the wrong temperature. There’s no clever fix. I installed a second coolant sensor in a different port for the DropBear and left the factory one alone.
- Sensor grounds must be tied together. The DropBear’s analog ground and the PCM’s sensor ground have to be bonded, or every shared analog reading is referenced to a slightly different zero and drifts.
There’s one more wire worth mentioning because it’s the most interesting thing in the factory design. When the TCM is about to shift, it pulses a dedicated wire to ground, the torque reduction request. The PCM sees the pulse, briefly retards timing to soften the shift, and acknowledges over the PCI bus. If the TCM doesn’t get two acknowledgements in a row, it logs a fault.
My original plan involved building an RP2040-based PCI-to-CAN bridge so the DropBear could participate in that handshake. Then I realized: I don’t have to. Because the PCM stays alive and stays connected, it keeps acknowledging exactly as the factory intended. I could just tap the torque reduction wire, and let the DropBear listen in as a third party so it can retard timing too. The handshake it’s not part of continues without it. An entire planned subsystem deleted itself.
That is the general shape of the good decisions in this project: leave the factory system intact and eavesdrop, rather than replacing it and reimplementing what it did.
Which makes it a little funnier that the thing that stopped me cold was a place where I did not do that.
The coil pack
Ignition on this engine is wasted spark: two coils, four cylinders, each coil firing two plugs simultaneously through plug wires. Coil 1 handles cylinders 1 and 4, coil 2 handles 2 and 3. One of each pair is on its compression stroke and gets a useful spark; the other is on exhaust and gets a spark into nothing. Standard, cheap, reliable.
The question I needed to answer was whether these were “smart” coils or “dumb” coils, and it matters enormously.
A dumb coil is just a transformer. To fire it you connect its primary winding to ground, let current build up for a couple of milliseconds (that’s dwell) then break the connection. The collapsing field fires the plug. The switch doing that has to handle 6 to 10 amps. That switch is called an ignitor, and it’s a chunky power transistor with a heatsink.
A smart coil has that ignitor built into the coil housing. You feed it a logic-level signal (5V, a hundred milliamps) and the coil handles its own current internally.
The DropBear’s ignition outputs are logic-level. They can source about 100 mA. Connect one of those directly to a dumb coil and you are asking a signal transistor to pass ten amps. It does not survive that. It doesn’t survive it once.
So I investigated, and I wrote down what I found:
Type: wasted-spark coil pack, 2 coils with internal ignitors (smart coils)
Connector: 3-pin (1 supply + 2 trigger inputs)
And I wrote down my reasoning, which rested on two pieces of evidence.
Evidence one: the connector has three pins. One +12V supply from the automatic shutdown relay, and two more, one per coil. If those two are trigger inputs, this is a smart coil pack.
Evidence two: the factory service manual describes the PCM’s coil outputs in degrees of dwell. The pinout literally reads “5°, at 55 mph: 8° dwell.” The PCM is specifying how long to charge in crankshaft degrees, not managing a current ramp. That’s smart-coil behavior: the ECU says when, the coil figures out how.
Two independent lines of evidence, pointing the same way. I checked the box:
☑ Smart coil with internal ignitor confirmed (3-pin connector + PCM dwell-degree drive)
And then, in the gotchas section of the same note, I wrote this:
Do NOT connect DropBear’s logic-level outputs directly to a high-current dumb coil (no internal ignitor). This would draw 6–10 A through DropBear’s 100 mA output transistor and instantly destroy it. The 3-pin connector + dwell-degree PCM drive both confirm this is a smart coil, so we’re fine.
I identified the exact failure mode. I described the exact consequence. Then I dismissed it, citing the same two pieces of evidence, and moved on.
First crank
Wiring done. Injectors on the DropBear, coils on the DropBear, idle valve on the DropBear, PCM still installed and awake for the transmission. Fuel disabled for the first attempt, because you check for spark before you check for combustion.
No spark. Not a weak spark, not an intermittent spark. Nothing on any plug.
The DropBear was seeing crank and cam sync, it knew where the engine was and it was commanding ignition events on schedule. The outputs were toggling. The coils had their 12V supply. Everything the software could tell me said it should be running.
There was no ignitor anywhere in the circuit.
The ignitors were inside the factory PCM. Not in the coil pack, but in the box I had just finished disconnecting from the coils. The PCM’s coil driver pins weren’t logic outputs at all; they were the high-current switched side of two power transistors sitting on a heatsink inside the case. My DropBear was politely waving 5V at a pair of coil primaries that needed someone to yank ten amps to ground.
Why the evidence lied
Both of my confirmations were consistent with the wrong answer. That’s the part worth generalizing.
The three-pin connector proves nothing. Think about what a dumb coil pack driven by a remote ignitor actually looks like from the connector: one +12V feed, and two wires carrying each coil’s primary low side back to wherever the switching happens. That is three pins. It is exactly three pins, and it is physically indistinguishable from one supply plus two logic triggers.
There’s even a tell I walked straight past. A genuine smart coil needs a power ground. The internal ignitor has to dump its current somewhere. A two-coil smart pack should have a dedicated ground pin, and mine didn’t. I’d quietly assumed it grounded through the mounting bracket to the cylinder head. It doesn’t need to, because there’s nothing inside to ground. The two “trigger” wires were the ground path, switched a few feet away.
Dwell in degrees proves nothing either. I reasoned that commanding dwell duration meant the ECU wasn’t managing current, so the coil must be. But an ECU with an internal ignitor also commands dwell (that’s just how long it holds its own transistor on). Specifying dwell tells you the ECU is doing time-based charge control. It tells you absolutely nothing about which side of the connector the transistor lives on.
So I had two observations that were each perfectly compatible with both hypotheses, treated their agreement as corroboration, and marked the question closed. They agreed because they were both silent.
The real lesson is narrower and more useful than “be careful”: you cannot determine where the ignitor lives by looking at the coil pack. Not from pin count, not from connector shape, not from how the factory ECU describes its outputs. The only reliable answers are measuring the resistance of the coil primary. A dumb coil reads under an ohm, a smart coil’s trigger input reads like a logic input, or finding the ignitor physically. On this car, finding it physically meant opening the ECU.
The fix
The fix is a part that exists precisely because this situation is common: an external ignitor module. I wired in LX-301 ignitors between the DropBear’s ignition outputs and the coil pack. The DropBear drives the ignitor at logic level, which is all it was ever able to do, and the ignitor does the ten-amp switching the factory PCM used to do.
It fired right up.
Where it stands
The car runs and drives on the DropBear. The transmission shifts through every gear, which means the central bet paid off: keeping the factory PCM alive as a sensor aggregator and PCI broadcaster was enough to keep the TCM happy, with no bridge hardware and no reimplementation of Chrysler’s shift logic.
Knock sensing and vehicle speed input aren’t configured on the DropBear yet. Both are wired and available; I just haven’t set them up.
And the malfunction indicator lamp is on, with a healthy collection of stored codes. That one is my favorite detail of the whole build, because it is the system working correctly. The PCM still believes it owns the injectors and the coils. It is dutifully reporting that the hardware it’s responsible for has vanished. It’s right. I took it. Those codes aren’t a bug to chase; they’re the factory computer’s accurate description of a car that no longer matches its worldview, filed from the passenger seat while the transmission it still controls shifts perfectly.
The thing I keep coming back to isn’t the ignitor. It’s that the failure was written down in advance, in my own handwriting, with the correct consequence attached; and I disarmed it with the word “confirmed.” Two pieces of evidence pointing the same direction felt like convergence. They were just two views of the same blind spot.
Proudly putting back together 70% of my projects
I’ve been doing this long enough to know better, which is exactly the problem.
Reverse engineering is mostly the business of building a model of a system nobody handed you documentation for, and then finding out where the model is wrong. Experience makes the models better. What it does not do is make you more willing to leave them open. The better your priors get, the earlier you feel entitled to write confirmed, and the entire failure here lives inside that word. A less experienced version of me might have just put a multimeter on the coil primary, precisely because he wouldn’t have had two clever inferences to lean on.
Software is more forgiving about this than hardware is. A wrong assumption in software usually announces itself: an exception, a failed assertion, a stack trace pointing directly at the line where your model and reality parted ways. Hardware doesn’t do that. Hardware either sits there silently doing nothing at all, or it converts your mistake into smoke, and neither outcome arrives with a line number attached. I got the first kind. Given that the direction of my error was “drive a dumb coil straight off a logic pin,” I’m counting the DropBear’s survival as luck rather than design.
So, the standing disclaimer: I hack cars and computers as a hobby, and I proudly put back together 70% of my projects. The other 30% is where most of the learning actually happens. This one made it into the 70%, but only by way of a failure I had already written a warning about, in my own notes, and then argued myself out of.
If there’s one thing worth stealing from this, it’s that confirmed in your own notes should mean “I measured it,” not “I reasoned about it and the reasoning felt good.” I know the difference. I wrote it down wrong anyway.