Why is my serial connection transmitting slightly incorrect characters?

Question

I have four configurations I'm testing, and one of those configurations is showing symptoms of incorrect transmission in one direction only (from my laptop terminal to the server).

• Direct connection to device model-type-A (works fine)
• Extended connection to device model-type-A (works fine)
• Direct connection to device model-type-B (works fine)
• Extended connection to device model-type-B (problems occur)

Type-A and Type-B are the same device make, but different device models / generations.

Connection settings are baud=9600, databits=8, stopbits=1, parity=none, flowctl=none

What is direct VS extended? For a direct connection, I am using a laptop with a Tripp-Lite USB-to-RS232 dongle (male port), and then connecting directly to the (male) serial port on the server machine which hosts the terminal application.

For an extended connection, it is the same as a direct connection, but with the addition of an industrial-grade 15-foot female-to-female RS323 serial cable between the dongle and the server.

What are the symptoms of the problem? Normal output/characters coming from the TTY server to my laptop show up just fine. However, characters going the other direction (input to the TTY server) are wrong 95% of the time, and this visibly shows in the 'echo back'. However, they're not wrong in a random sense (like you would expect from a bad cable). The characters are wrong in a very predictable way. It seems that only some bit positions are getting flipped.

'a' 0x61 -> 0x40 0x41 0x60 0x61 
'b' 0x62 -> 0x40 0x42 0x60 0x62
'c' 0x63 -> 0x42 0x43 0x62 0x63
'd' 0x64 -> 0x40 0x44 0x60 0x64
'e' 0x65 -> 0x40 0x41 0x64 0x65
'f' 0x66 -> 0x44 0x46 0x64 0x66
'g' 0x67 -> 0x46 0x47 0x66 0x67

For example, when I type the letter 'a', I will see one of the four characters (@,A,`,a) above. The 'highest' of the range will be the correct value, and the lowest of the range always tends to be the correct value minus roughly 0x20.

It almost looks like an incorrect terminal setting, but again this behavior change only occurs when adding a simple cable extension. The settings work fine with the absence of the extender.

I have also tested the cable in question and used several cables (of the same part number). When testing the cable directly between two laptops (using the same TrippLite dongle on both ends), the data comes through fine in both directions.

Any partial information that might lead to figuring this out is appreciated.

Answer 1

You need to check the signal quality and timing at the receiving end. You may be able to get away with one of those being a bit off, but not both.

RS232 doesn't send a clock signal. It relies on the receiver running at the same speed as the sender, and starts synchronization on the start bit.

Depending on what's generating the signal, a software emulation of a UART may be poor on the timing side, compared with a real UART and a quartz clock.

If the driver isn't powerful enough, then the capacitance of a long cable may mean that the rise and fall times aren't within the RS233 spec by the time the signal arrives.

Answer 2

While I don't know the low-level root cause, I've been able to resolve the flipped bit problem by using a different USB-to-Serial adapter.

The Startech ICUSB2321F works with all of our use cases without encountering any bit flipping. It uses the FTDI FT232R chip. While the TrippLite U209-000-R adapter uses the very common Prolific PL2303RA chip.

My suspicion is that the FT232R chip has a design which allows for better transmission over distances when compared to the PL2303RA, since the issue only occurs with data going 'outbound' over longer cables. Concerningly, the PL2303RA was having bit flipping issues even with 10 foot cables.

Small side note for anyone using the adapter with Windows: beware that Windows may try to interpret your COM device as a mouse when you plug it in. I was able to get around this by leaving the serial cable disconnected until a few seconds after Windows was done with the device handshake.