2
\$\begingroup\$

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.

\$\endgroup\$
16
  • 2
    \$\begingroup\$ Do you have a scope? You could examine the signal shape on the wrongly receiving end. \$\endgroup\$
    – Eugene Sh.
    Mar 3 at 18:52
  • \$\begingroup\$ convert what you send and what you receive into raw binary. Remember UART is least significant bit first. See what exactly bit positions are flipped. Check stop bit timing. \$\endgroup\$
    – Ilya
    Mar 3 at 18:55
  • \$\begingroup\$ If you only need this for interactive terminal use,do you really need 9600 baud? Downgrading to a lower data rate would likely fix this. \$\endgroup\$
    – TooTea
    Mar 3 at 18:58
  • \$\begingroup\$ @EugeneSh. no, I don't have a scope, but that's an option I considered further down the road after trying easier things. \$\endgroup\$
    – Wisteso
    Mar 3 at 19:27
  • \$\begingroup\$ @Ilya I already know that it looks like the 0x32 bit, 0x02, and 0x01 bits seem to be flipped, but it's anywhere from 0 to 3 flipped bits. \$\endgroup\$
    – Wisteso
    Mar 3 at 19:27

2 Answers 2

1
\$\begingroup\$

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.

\$\endgroup\$
2
  • \$\begingroup\$ Since I have a working solution (using the startech dongle) I'll probably not be having the time to investigate you're suggesting, but what you're suggesting would explain everything. The dongle that worked is more expensive and a bit bulkier, so I'm guessing it uses a fancier UART / clock which explains why it works fine over the longer distance. \$\endgroup\$
    – Wisteso
    Mar 11 at 18:11
  • \$\begingroup\$ Found this potentially related question from a few years ago electronics.stackexchange.com/questions/422078/… \$\endgroup\$
    – Wisteso
    Mar 11 at 18:43
1
\$\begingroup\$

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.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ You can control whether Windows is running device detection over any of the FTDI serial ports. Go into device manager, into properties of the serial port, and disable plug-and-play. \$\endgroup\$ Mar 10 at 17:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.