Project Logs

Collapse

• What Started as a Motorcycle Problem

  Crux Resolve • 2 hours ago • 0 comments

  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,...

  Read more »

• What I Would Change If I Started the Next Revision Today

  Crux Resolve • 2 hours ago • 0 comments

  The funny thing about finishing a project like this is that by the time it works, you know enough to immediately see all the things you would do differently.

  GB-01 solved the problem I originally had.

  It gave me a local WiFi-to-RS232 link that could sit between GhostTune and the ECU, and it proved the whole idea could work as a real physical product.

  But if I were starting the next hardware revision today, I would make some different choices.

  I Would Think More About RS232 Beyond My Original Use Case

  The first board was designed around the connection I needed.

  That meant TX, RX, and ground.

  For MicroSquirt, that was enough.

  Once I started thinking about GhostBridge as a more general RS232 device, the first obvious limitation was hardware flow control.

  Some equipment needs RTS/CTS.

  GB-01 does not route those signals.

  Interestingly, the MAX3232 already contains another transmitter and another receiver that I am not currently using.

  So one of the first things I would look at in a future board is using those additional channels for RTS and CTS.

  That would not make the device magically compatible with everything, but it would open the door to more equipment than the current three-wire design.

  I Would Design for Manufacturing Earlier

  When I started, my goal was basically:

  Make it work.

  That is probably the right goal for a first prototype.

  But if I were doing the next one, I would think about manufacturing much earlier.

  Part availability.

  Alternate components.

  Assembly cost.

  Connector choices.

  Test points.

  Programming access.

  How easily the board can be inspected.

  How easily I can test five or fifty boards instead of just one.

  Those questions become a lot more important once the hardware leaves your bench.

  I Would Make Testing Part of the Board Design

  I learned a lot by probing the first boards manually.

  For the next revision, I would want more deliberate test access.

  Power rails.

  UART signals.

  RS232-side signals.

  Reset and boot access.

  Anything that lets me quickly answer:

  Is the problem firmware, logic-level serial, the transceiver, or the external connection?

  One of the things PLC work has taught me is that good diagnostics save an incredible amount of time.

  That applies to PCB design too.

  I Would Think About the Enclosure at the Same Time as the PCB

  I treated the enclosure as something I would figure out after the electronics were finished.

  I probably would not do that again.

  Connector placement, board mounting, component height, programming access, cable clearance, and enclosure geometry all affect each other.

  Moving a connector a few millimeters on the PCB can make the enclosure much easier or much harder to design.

  Next time, I would probably work on both at the same time.

  I Would Keep the Bridge Protocol-Agnostic

  One thing I would not change is the basic separation between the hardware transport and the software using it.

  GhostBridge moves bytes.

  GhostTune understands the ECU.

  That turned out to be a much better architecture than baking ECU-specific behavior into the bridge itself.

  It also means the hardware can potentially be useful in applications I had never considered when I designed it.

  So even if the next revision becomes more capable, I would still try to keep the core transport as simple and transparent as possible.

  I Would Still Use AI

  Absolutely.

  But I would use it differently now.

  At the beginning of this project, I often needed AI to explain entire subjects I had never worked with before.

  Now I know enough to ask much better questions.

  Instead of:

  “How do I design this?”

  the questions become more like:

  “Here are the exact constraints. Here is the datasheet. Here is the board. What assumptions should I be challenging?”

  That is a much more useful relationship.

  The better I understood the hardware and software, the more useful AI became because I could tell when something did not make sense.

  And I think that is probably the biggest...

  Read more »

• When a Prototype Becomes a Product

  Crux Resolve • 2 hours ago • 0 comments

  There was a point in this project where GhostBridge worked.

  The PCB powered up.

  The ESP32 firmware was stable enough to move traffic.

  The RS232 side communicated reliably.

  GhostTune could talk through it to a real ECU.

  Technically, I had solved the original problem.

  But I started realizing there is a pretty big gap between “this works on my bench” and “I would ship this to somebody and expect it to work for them.”

  That brought a completely different set of questions.

  How repeatable is the hardware?

  Can I order five boards and expect all five to behave the same way?

  Can somebody plug the connectors in without stressing the PCB?

  Does the enclosure stay together?

  Can the board move around inside it?

  How am I going to power it?

  What happens when somebody connects to the WiFi for the first time?

  What information do they need before they can use it?

  And probably the biggest one:

  What assumptions am I making because I built the thing myself?

  On my bench, I already knew the pinout.

  I already knew which WiFi network to connect to.

  I knew the TCP address and port.

  I knew what the LEDs, firmware behavior, and serial connection were supposed to do.

  A customer knows none of that.

  That forced me to start looking at GhostBridge less like a project and more like a product.

  Manufacturing More Than One

  Ordering prototypes from JLCPCB was one thing.

  Thinking about repeatable production was different.

  I had to pay attention to part availability, substitutions, assembly, board cost, shipping, and whether the exact design I had tested could actually keep being built.

  That is another lesson I did not really appreciate when I started:

  A component can be electrically perfect and still be a bad production choice if nobody can get it.

  The BOM became more than a list of components.

  It became part of whether the design could actually exist outside of my own workbench.

  Firmware Had to Become Predictable

  The same thing happened with the firmware.

  During development I could change a setting, reflash the ESP32, reconnect manually, or look at serial output if something went wrong.

  That is not a good user experience.

  I needed the bridge to power up and behave predictably.

  The current setup creates its own local WiFi network and exposes the serial connection through TCP. No router or Internet connection is required for the basic link.

  For my original use case that was exactly what I wanted.

  Turn the bridge on, connect the phone, and communicate locally with the ECU.

  The less setup required, the better.

  I Had to Start Documenting the Limitations Too

  This was also when I started getting more careful about what the hardware doesn't do.

  GB-01 is a three-wire RS232 design.

  It routes TX, RX, and ground.

  It does not route RTS, CTS, DTR, DSR, DCD, or RI.

  That means I cannot just say:

  “If it has a DB9 connector, GhostBridge will work.”

  That would be wrong.

  A DB9 connector might not even be RS232.

  And even if it is RS232, the equipment could require hardware flow control, a different pinout, a null-modem connection, or serial settings that need to be matched correctly.

  That sounds obvious now, but productizing something forces you to think much harder about the difference between:

  “I made it work in my application”

  and

  “I understand the boundaries of where it should work.”

  I think that is an important engineering distinction.

  Then Came the Weird Business Stuff

  At some point I also had to deal with all the things that have nothing to do with UARTs or PCB traces.

  Packaging.

  Shipping.

  Instructions.

  A website.

  Support.

  Product descriptions.

  Pricing.

  App Store paperwork.

  Privacy policies.

  Terms.

  Things I definitely was not thinking about when I first connected an ESP32 to an RS232 transceiver.

  I even found myself worrying about whether a 3D-printed case that took around seven hours to print was practical if more than...

  Read more »

• What AI Actually Did on This Project

  Crux Resolve • 2 hours ago • 0 comments

  AI was involved in this project for months, but probably not in the way people imagine when they hear “AI-designed hardware.”

  It did not spit out a finished PCB, firmware file, mobile app, and enclosure while I sat back and watched.

  It was much closer to having a very fast technical sounding board available whenever I crossed into something I did not understand yet.

  That happened a lot.

  My background gave me a decent troubleshooting foundation, but I was constantly moving into unfamiliar areas:

  ESP32 hardware.

  RS232 electrical signaling.

  Component datasheets.

  PCB layout.

  EasyEDA.

  JLCPCB manufacturing requirements.

  C++ firmware.

  TCP networking.

  React Native.

  Expo.

  iOS builds.

  3D enclosure design.

  Every time the project crossed into another one of those areas, I could ask a very specific question and keep moving.

  That was incredibly useful.

  It was also dangerous if I stopped thinking.

  AI can give an answer with a lot of confidence even when the answer is wrong, incomplete, or based on an assumption that does not apply to the hardware sitting in front of you.

  I ran into that more than once.

  Sometimes the answer was exactly what I needed.

  Sometimes it got me 90 percent of the way there.

  Sometimes it sent me in completely the wrong direction.

  That is where I think my PLC background helped.

  In industrial troubleshooting, I am already used to separating what someone says should be happening from what the machine is actually doing.

  The same rule worked here.

  If AI said a pin should be high and I measured it low, I did not keep arguing with the meter.

  If a datasheet contradicted an explanation, the datasheet won.

  If a PCB looked correct but packets were not getting through it, the board was not correct yet.

  If a case looked perfect in CAD but the snap broke when I assembled it, the snap was too weak.

  The physical system always got the final vote.

  There was another benefit I did not really expect.

  AI made it easier to keep the entire project connected.

  Normally a hardware problem, firmware problem, mobile-app problem, and enclosure problem can feel like four separate projects.

  Here they were all affecting each other.

  Changing how the firmware behaved could affect the app.

  Changing the PCB could affect the enclosure.

  Changing a connector location could affect manufacturing and case geometry.

  A communication problem could be software, TCP, UART, the MAX3232, the DB9 wiring, or the ECU on the other end.

  Being able to reason across those layers without starting from zero every time was probably where AI helped me the most.

  But I would not describe the process as replacing engineering knowledge.

  If anything, it constantly showed me how much I still needed to learn.

  AI could explain what a MAX3232 does.

  I still had to probe the board.

  AI could help review a schematic.

  I still had to order it and find out whether it worked.

  AI could help write React Native code.

  I still had to connect it to a real ECU and make sure it did not do something stupid.

  AI could suggest a snap-fit change.

  I still had to wait seven hours for the printer to tell me whether it was a good idea.

  I think that is the part of AI-assisted engineering that gets lost in a lot of the conversation around it.

  When the output is a physical product, eventually the prompts stop mattering.

  Something has to power on.

  Something has to communicate.

  Something has to fit.

  And somebody has to prove it.

  For me, AI made it possible to get into a lot of technical areas much faster than I otherwise would have.

  But the most important sentence from the whole project is still the same one:

  The board on my bench was the final authority.

• The Moment I Realized It Wasn’t Really an ECU Adapter

  Crux Resolve • 2 hours ago • 0 comments

  GhostBridge started because of a very specific problem.

  I wanted an iPhone to communicate with a MicroSquirt ECU over RS232.

  So for most of the project, I naturally thought of the hardware as an ECU interface.

  That was the whole reason it existed.

  But once the hardware, firmware, and GhostTune were all working together, I started looking at the bridge by itself instead of looking at the complete system.

  And the obvious question hit me:

  What part of this board actually knows there is an ECU connected to it?

  The answer was basically none of it.

  The ESP32 does not understand fuel tables.

  The MAX3232 does not know what MS2/Extra is.

  The DB9 certainly does not care.

  At the hardware level, the bridge is really just:

  WiFi/TCP → ESP32 → UART → MAX3232 → RS232

  and the same path in reverse.

  GhostTune is the part that understands the ECU protocol.

  GhostBridge just moves the bytes.

  That separation was something I had intentionally designed into the firmware, but I had never really thought through what it meant for the hardware itself.

  It meant I had accidentally built something much more general than the original application.

  If another device uses a compatible three-wire RS232 connection and the software on the other end can communicate over TCP, there is no fundamental reason the bridge has to care whether that device is an ECU, test instrument, old piece of equipment, embedded controller, or something else entirely.

  That was a pretty interesting realization because the whole project had started in such a narrow automotive use case.

  It also made me start thinking harder about the limitations of the first board.

  GB-01 only routes:

  TX

  RX

  Ground

  That works for the application I originally built it for, but plenty of RS232 equipment also uses hardware flow control such as RTS and CTS.

  So this is not some universal “plug it into anything with a DB9” device.

  A DB9 connector does not even guarantee that the device is using RS232.

  Pinout, electrical standard, baud rate, data format, flow control, and whether the equipment is wired as DTE or DCE still matter.

  That became another rabbit hole.

  The interesting part is that the MAX3232 I used already contains more than the one transmit and receive channel I am currently using.

  So a future revision could potentially route another pair for RTS/CTS instead of changing the entire architecture.

  That is one of those things that seems obvious after the fact.

  Version one solved the problem I actually had.

  Only after it worked did I start seeing all the problems it might solve next.

  And that was probably the point where I stopped thinking of GhostBridge as just part of GhostTune and started thinking of it as its own piece of hardware.

• Then I Had to Put It in a Box

  Crux Resolve • 2 hours ago • 0 comments

  Once the electronics worked and GhostTune was talking through GhostBridge, I thought I was getting close to the end.

  I wasn’t.

  The enclosure ended up becoming a project of its own.

  I wanted something that looked like a finished device, not a PCB sitting loose in a generic electronics box.

  That meant designing around the actual board, the DB9 connector, the USB-C port, the component heights, and the way the PCB needed to be held in place.

  I also wanted the case to snap together instead of using screws.

  That sounded simple too.

  It wasn’t.

  My first enclosure ideas looked fine in CAD, but once I started printing them I found out pretty quickly that features that look strong on a screen can be weak in real plastic.

  Some locating features were too thin and broke.

  The snap geometry needed more material.

  The PCB could move more than I wanted.

  The connector openings were close, but not quite right.

  Then I started getting into the kind of adjustments I never expected to care about:

  0.1 mm here.

  0.15 mm there.

  Make this tab a little thicker.

  Move that rail outward.

  Reduce the USB-C opening slightly.

  I probably spent more time thinking about tenths of a millimeter than I had spent thinking about entire control panels in the PLC world.

  The process became pretty repetitive:

  change the model → print it → wait several hours → assemble it → find the next problem

  A full print could take around seven hours, so every bad revision had a built-in waiting period before I got to find out what I had done wrong.

  That made small changes feel surprisingly important.

  One version had small locating features near the DB9 that were too fragile and broke off.

  Those eventually got removed completely.

  The snap sections got thicker.

  The PCB retention changed.

  The centering rails changed.

  The connector openings changed.

  Even after the whole thing snapped together correctly, I still had a little bit of PCB movement inside the case and had to decide whether it was actually a problem or just me trying to make everything perfect.

  Eventually I got to a version that snapped together, held the board securely enough, lined up with both connectors, and looked like something I would actually be comfortable handing to someone else.

  That was another milestone for me.

  The project had gone from:

  jumper wires and an idea

  to

  custom PCB + firmware + iPhone app + custom enclosure

  At that point, GhostBridge finally looked like a product instead of a prototype.

  The next realization was probably the most unexpected part of the whole project:

  I had built it for an ECU, but there was really nothing ECU-specific about the bridge itself.

• The Other Half in React Native

  Crux Resolve • 2 hours ago • 0 comments

  Once GhostBridge could reliably move bytes between RS232 and WiFi, I had the transport problem mostly solved.

  The next problem was figuring out what to do with those bytes.

  I wanted the phone to do more than just prove that a TCP connection existed. I wanted to actually communicate with the ECU, read live data, work with tuning tables, and eventually make real changes safely.

  That became GhostTune.

  I built the app using React Native and Expo, which was another major jump outside my normal background.

  Before this project, my software world was much closer to PLC logic and industrial troubleshooting than mobile application development.

  Now I was dealing with things like React components, state management, navigation, binary data, networking, screen layouts, persistent files, and all the weird little details that come with building something for iOS.

  The first goal was simple:

  Can the app connect to GhostBridge over WiFi and exchange real ECU traffic?

  Once that started working, the project expanded quickly.

  It wasn’t enough to just display bytes.

  The app needed to understand the ECU protocol.

  It needed to request data, decode responses, display live values, handle tuning tables, manage files, and eventually support write operations without doing something stupid to the ECU.

  That last part became especially important.

  Reading data is one thing.

  Writing data to an ECU is another.

  I did not want a UI bug or a dropped connection to turn into an accidental permanent change.

  So the app gradually developed more safeguards around writes, temporary changes, verification, burns, restores, and communication state.

  That was one of the areas where the software became much more complicated than I expected.

  A button labeled “Write” looks simple on a screen.

  Behind that button there can be a lot of logic deciding whether the write should happen at all, whether communication is stable, whether the ECU accepted it, and whether the value read back matches what was requested.

  The more I worked on it, the more I realized GhostTune was becoming a serious project of its own rather than just a test application for GhostBridge.

  AI was heavily involved here too.

  I used it to work through React Native problems, protocol parsing, UI logic, state bugs, build errors, and eventually the increasingly large codebase.

  But the same rule applied as it did with the PCB.

  A piece of code could look perfectly reasonable and still fail the second it talked to a real ECU.

  The ECU did not care how convincing the code looked.

  It either returned the right bytes or it didn’t.

  Eventually GhostTune grew to the point where I was testing real ECU communication, tuning screens, file handling, and guarded write operations through the same GhostBridge hardware that had started as a basic serial experiment.

  Then came another thing I had never done before:

  Getting an iPhone app through Apple’s build, TestFlight, review, and App Store process.

  That turned out to be its own adventure.

  But when GhostTune finally made it onto the App Store, it was a pretty strange moment to look back at where the project had started.

  I had gone from:

  “Can I make this ECU talk to my phone?”

  to having a custom PCB, ESP32 firmware, a wireless RS232 transport, and an actual iOS application communicating through it.

  And I still hadn’t finished the enclosure.

• Making the ESP32 Disappear

  Crux Resolve • 2 hours ago • 0 comments

  Once the serial path was reliable, I wanted the bridge itself to stay as simple as possible.

  I did not want the ESP32 trying to understand ECU tables, tuning commands, or any of the application-specific protocol.

  Its job was just to move bytes.

  That sounds simple, but there were still a lot of details hiding underneath it.

  The ESP32 needed to create the WiFi connection, accept a TCP client, read data from the network, push that data out through the UART, then take whatever came back from RS232 and send it back over TCP.

  In other words:

  TCP in → UART out

  UART in → TCP out

  The less interpretation the bridge did, the better.

  That separation ended up becoming one of the most important design decisions in the project.

  If the bridge tried to understand the ECU protocol, then every new ECU or software change could turn into a firmware change.

  If it only moved bytes, then the intelligence could stay in the application.

  That also made debugging easier because I could think about the system in layers.

  Is the WiFi connection working?

  Is TCP connected?

  Are bytes reaching the ESP32?

  Are those exact bytes appearing on the UART?

  Are the returned serial bytes making it back to the client?

  I spent a lot of time testing those boundaries independently.

  There were firmware revisions where one part worked and another part didn’t.

  There were timing issues.

  There were cases where communication looked fine for a few messages and then failed under a longer test.

  And there were plenty of times where the most useful thing I could do was strip the problem back down and verify one direction at a time.

  That is another place where AI was useful.

  I could work through firmware ideas, networking behavior, buffer handling, serial settings, and debugging approaches quickly.

  But again, a code snippet looking reasonable did not mean the bridge worked.

  The real test was whether I could pass actual binary traffic through it reliably.

  Eventually the firmware became boring in the best possible way.

  Connect to the bridge.

  Open the TCP socket.

  Send bytes.

  Get bytes back.

  That was exactly what I wanted.

  The more invisible the bridge became, the better the design was doing its job.

  At that point I had working hardware and working transport.

  The next problem was much bigger:

  I still needed an iPhone application that actually knew what all those bytes meant.

  That became GhostTune, and it pushed me into React Native, Expo, ECU protocols, mobile UI design, and eventually the App Store.

• TX/RX Look Right Until They Aren’t

  Crux Resolve • 2 hours ago • 0 comments

  This was one of those problems where everything looked close enough to working that it became more confusing.

  The ESP32 was alive. The MAX3232 had power. I could see logic-level activity on the microcontroller side and real RS232-level voltage on the DB9 side.

  At one point I was measuring roughly +3.2 V on the TTL side and around +6 V between the RS232 transmit pin and ground.

  So the transceiver was clearly doing its job.

  The problem was that the thing still would not communicate correctly.

  This is where labels like TX and RX can get you into trouble.

  “TX” only makes sense when you are clear about whose TX you are talking about.

  The ESP32 transmits toward the MAX3232.

  The MAX3232 transmits toward the DB9.

  The device on the other end has its own TX and RX.

  Then DTE/DCE conventions get involved, and suddenly two signals that look perfectly logical on a schematic can still end up facing the wrong direction in the real connection.

  I eventually stopped looking at the labels and started treating it like I would troubleshoot an industrial control problem.

  Where does the signal physically start?

  Which pin does it reach next?

  What voltage do I actually measure there?

  Where is it supposed to go from there?

  That made the problem much easier to reason through.

  After tracing the path and correcting the TX/RX connection, communication finally started behaving the way it was supposed to.

  Then I ran a larger test instead of trusting a couple of successful messages.

  256 packets sent.

  256 packets returned.

  That was a pretty satisfying result.

  It was also a good reminder of something that came up repeatedly during this project: a design can look right, the firmware can look right, and even individual voltage measurements can look right while the complete system is still wrong.

  You have to test the entire path.

  That is also where my PLC background probably helped more than anything else.

  On a machine, I would never assume an output works just because the PLC says the output bit is on. I would follow it through the module, wiring, field device, and actual process.

  The same idea applied here.

  The schematic saying “TX” did not matter nearly as much as finding out where the electrons were actually going.

  Once I had reliable serial communication, the next problem became much more interesting:

  How do I make the ESP32 disappear as much as possible and just move bytes between RS232 and WiFi?

  That became the firmware side of GhostBridge.

• The First PCB Showed Up

  Crux Resolve • 2 hours ago • 0 comments

  Getting a PCB manufactured was one of those steps that felt bigger than it probably should have.

  Up to that point, almost everything could still be changed instantly.

  If the schematic was wrong, I could fix it.

  If a footprint was wrong, I could replace it.

  If routing looked bad, I could move things around.

  Once I placed the order, that changed.

  Now I had committed the design to actual copper, fiberglass, solder, components, and money.

  I used JLCPCB for manufacturing and assembly, which meant I also had to learn a whole new set of details around BOMs, part availability, assembly options, component substitutions, board files, and what the manufacturer actually needed from me.

  That was another part of the project I had never dealt with before.

  In the PLC world, if I need a controller, an input card, or a relay, I usually buy a finished product that already exists.

  Here I was the one creating the finished product.

  When the first boards finally arrived, I remember looking at them and thinking they looked far more professional than I expected.

  It was strange seeing something I had been staring at in EasyEDA suddenly sitting on the bench as a real assembled PCB.

  Then the excitement wore off and the real test started.

  Does it power up?

  Is 3.3 volts actually 3.3 volts?

  Is the ESP32 alive?

  Is the MAX3232 doing anything?

  Are the signals going where I think they are going?

  Does the DB9 behave like the schematic says it should?

  This was the point where I stopped being able to solve problems by moving things around on a screen.

  Now I had to measure them.

  I started checking power rails and signal paths and eventually confirmed that the RS232 side was producing real RS232-level voltages.

  That was a good sign.

  It also did not mean the board actually worked.

  That distinction became important pretty quickly.

  The board could power up, the ESP32 could run, the transceiver could generate the right kind of voltage, and communication could still fail.

  That ended up leading into one of the more useful debugging lessons of the entire project.

View all 12 project logs