Looking back at this project, the part that still makes me laugh is how small the original idea was.

I wanted to tune a motorcycle from an iPhone.

That was it.

I had a MicroSquirt ECU, it communicated over RS232, and I did not want to keep dragging a laptop and serial cable around.

Somehow that turned into:

• learning ESP32 development
• figuring out real RS232 signaling
• designing a PCB
• learning EasyEDA
• ordering assembled boards
• debugging hardware on the bench
• writing firmware
• building an iOS app in React Native
• learning Expo
• dealing with binary ECU protocols
• designing a snap-fit enclosure
• learning more about manufacturing
• getting an app onto the App Store
• and eventually trying to turn the hardware into an actual product

None of that was the plan when I started.

The PLC Background Mattered More Than I Expected

I went into this feeling like I was working completely outside my field.

In a lot of ways I was.

I did not have a background in PCB layout, embedded product design, or mobile app development.

But the troubleshooting mindset turned out to transfer surprisingly well.

PLCs teach you not to trust appearances.

The HMI can say one thing.

The PLC logic can say another.

The output card can show a light.

And the valve in the field can still be sitting there doing absolutely nothing.

You learn to follow the signal all the way through.

That same mindset ended up applying everywhere in this project.

The schematic says TX?

Trace it.

The firmware says the byte was sent?

Capture it.

The MAX3232 should be switching?

Measure it.

The CAD model says the snap should fit?

Print it.

The app says a write succeeded?

Read the value back.

That part of engineering turned out to be pretty universal.

AI Changed How Fast I Could Learn

I do not think I would have gotten through all of these different disciplines nearly as quickly without AI.

It let me move from one unfamiliar problem to the next without spending days figuring out what terminology I even needed to search for.

But the project also taught me not to confuse a good explanation with a correct result.

AI can be incredibly useful.

It can also be confidently wrong.

The farther the project went, the more I found myself using AI less like an answer machine and more like another person at the whiteboard.

Suggest something.

Challenge it.

Pull the datasheet.

Measure the board.

Try it.

See what happens.

That ended up being a much better way to use it.

The Best Part Was When Everything Finally Connected

There were a lot of individual milestones, but the most satisfying moment was probably when all the pieces stopped being separate projects.

The PCB was working.

The ESP32 firmware was moving the data.

The RS232 connection was solid.

GhostTune was connected over WiFi.

And the ECU was responding on the other end.

At that point the whole path was finally alive:

iPhone → WiFi/TCP → ESP32 → UART → MAX3232 → RS232 → ECU

and back again.

That was the original idea I had months earlier.

Just with a lot more work hiding inside those arrows than I expected.

Where It Is Now

The first GhostBridge hardware exists and works.

GhostTune exists and is on the App Store.

The enclosure is printed and assembled around the board.

And what started as an ECU-specific connection has turned into a more general question about what else a simple local WiFi-to-RS232 bridge might be useful for.

There is still plenty I would improve.

That is probably always going to be true.

But I have also learned not to look at version one only through the eyes of the person who already knows how to build version two.

The person who started this project had never designed a PCB.

That is easy for me to forget now.

If Someone Else Is Thinking About Starting

I am probably the wrong person to tell anyone to wait until they know what they are doing.

If I had waited until I understood ESP32s, PCB design, EasyEDA, React Native, iOS development, enclosure design, and manufacturing before starting this project, I probably never would have started it.

I learned most of it because I had a real problem in front of me that I actually wanted to solve.

That gave every new subject a reason to matter.

And when something did not work, I had something physical to test against instead of just reading theory.

So I guess that is the biggest thing I got out of the project.

You do not necessarily have to know every discipline before you start crossing into it.

But eventually you do have to understand enough to test your own assumptions.

And no matter how good the schematic, software, CAD model, or AI answer looks:

the hardware still gets the last vote.