UART Link Fails Only at Long Cable Length
A controller talks to a remote display over a 3.3 V UART at 115200 baud, 8N1, on 18 m of unshielded twisted pair. Short bench tests pass; at the installed length roughly one frame in 500 has a checksum error, and errors increase when a nearby contactor operates. The UART lines run alongside a 24 V solenoid cable for part of the route. The engineer suggests simply lowering the baud rate to 9600 as a permanent fix. The protocol has a 1-byte checksum and no retry mechanism.
1. Assess the proposed baud-rate reduction and identify the deeper design weaknesses.
Read the worked answer
Dropping to 9600 raises bit time from about 8.7 µs to 104 µs, which improves noise immunity and tolerance of cable rise time, so it may reduce errors. But it is a workaround, not a fix: the link remains single-ended and unbalanced, so common-mode noise from the contactor and solenoid still couples in, and the protocol has a 1-byte checksum with no retransmission, so any corrupted frame is silently lost. The design weaknesses are: no differential signalling for an 18 m run, no shielding or defined return path, no retry or sequence numbering, and a checksum too weak to catch multi-bit bursts reliably.
2. Recommend a redesign and explain how you would validate it.
Read the worked answer
Move to a differential bus such as RS-485 with a transceiver at each end, shielded twisted pair with the shield grounded at one end, termination matched to the cable characteristic impedance, and a protocol with a CRC and acknowledged retries. If the UART must stay, add isolated transceivers and keep the signal pair separated from the solenoid cable. Validate by running the contactor and solenoid repeatedly while counting CRC failures over at least 10^5 frames at the installed length, then repeat at temperature extremes. Acceptance criterion: zero undetected corrupted frames and a defined, low retry rate. This proves the fix at the physical and protocol layers rather than relying on a slower baud.