Close

TX/RX Look Right Until They Aren’t

A project log for From PLCs to PCBs: Building a WiFi RS232 Bridge

I work with PLCs, not ESP32s. This is how AI, EasyEDA and React Native helped me turn an RS232 problem into real hardware.

crux-resolveCrux Resolve 5 hours ago0 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.

Discussions