USB-Serial cable problems

Now that serial ports are no longer being fitted to all PC motherboards it may sometimes be necessary to use a USB to RS232 serial cable to allow a PC to communicate with legacy devices using a serial connection. Hopefully, my experience with these devices will be of some use to others.

While working on the StagView and GPView applications, both of which communicate using a RS232 serial connection, I obtained a cheap USB to serial cable from ebay to make tests with. I was surprised to find that is worked correctly when used with Windows XP and Linux and it identified itself as a USB-SERIAL CH340 using the CH340 driver from winchiphead (wch.cn), Linux has a driver supplied for it.

Some time later I purchased, what I thought were, some more but from a different supplier on ebay. When they arrived they looked very similar but the plastic mouldings on the connectors were a slightly different colour, more blue than the green colour of the original cable, and where there was '340' marked on the original the latest ones were blank. The driver CD supplied was hard to read on most of the drives I have but I did manage to read it on a Blu-ray drive. It had the winchiphead drivers but I decided to keep the one installed already which was newer and each of the new cables identified itself as a USB-SERIAL CH340. However, they failed to work correctly when using RTS/CTS handshaking when used with exactly the same drivers used for the initial testing. I did try using the older driver for Windows XP from the driver CD and there was no difference. Using a serial analyser it was possible to see that the transmission of characters to the legacy device did not stop quickly enough when the CTS input to the PC was driven in-active to -12V. If RTS/CTS handshaking was not used they seemed to work with the Windows XP driver but were unreliable with the Linux driver.

The original cable is on the left and the later cable on the right.
Note that the IC is mounted 'Chip-on-board' ('Direct Chip Attach') so there is very little chance of finding out what it really is.

I knew that these cheap devices do not normally have level shifting circuitry to convert from TTL (0 - 5V) to RS232 (-3 to -15V - +3 to +15V) so I measured the voltages on the output pins. I confirmed that both types of cable do not have the extra circuitry and output 0V instead of at least the -3V required by RS232. Thinking that I should try a better made product I then purchased a genuine FTDI UC232R-10 USB-Serial Adapter, which (supposedly) has better driver support and RS232 level shifting circuitry, from Farnell and tested it with the latest Windows driver 2.12.00 from FTDI.

FTDI UC232R-10 USB-Serial cable

FTDI UC232R-10

After some initial testing which showed that all the cables had problems I purchased a Plugable PL2303-DB9 which is PL2303HXD based and is specifically listed on the Prolific website as proven to work correctly.

Plugable PL2303-DB9 USB Serial Adapter

Plugable PL2303-DB9

Test results

Here are the results of the tests I made using StagView, which uses no handshaking, and GPView, which uses RTS/CTS handshaking. A large data file was transferred to each device programmer and the throughput recorded. The results are intended to show the relative differences in transfer speed for the same application compared to using a standard serial port.

Tested with StagView (no handshaking is used)

USB-Serial cable used Results for Linux 2.6.x with supplied drivers Results for Windows XP with vendor's drivers
Original CH340 but slow quite fast
Suspect CH340 Does not work quite fast
FTDI UC232R (FT232BM) almost as fast as standard serial port quite fast
Plugable PL2303-DB9 (PL2303HXD) almost as fast as standard serial port quite fast

Tested with GPView (RTS/CTS handshaking is used)

USB-Serial cable used Results for Linux 2.6.x with supplied drivers Results for Windows XP with vendor's drivers
Original CH340 but even slower than with no handshaking (note 1) quite fast
Suspect CH340 Does not work Does not work
FTDI UC232R (FT232BM) almost as fast as standard serial port Does not work, fails to observe handshaking protocol
Plugable PL2303-DB9 (PL2303HXD) almost as fast as standard serial port quite fast

notes

1. Although it passes the test the facility to read the CTS status input does not work and so cannot detect if the cable is disconnected. This must be a bug in the CH340 Linux driver.

Conclusions

I believe that the "suspect CH340" cables are using poor copies (fakes) of the CH340 which have probably only been tested with the vendor's Windows CH340 driver with no handshaking used.

The vendor supplied Windows drivers for the UC232R (FT232BM) are useless if the application uses RTS/CTS handshaking. The result from the RTS/CTS handshaking test with the FTDI UC232R is even more surprising given that the FT232BM has the handshaking support built into the hardware ! I am assuming that the FTDI Windows driver is not enabling it correctly.

The drivers supplied with Linux for the CH340 do not perform as well as the vendor's Windows drivers, this may be because the CH340 that works may also be a fake.

The third party written Linux drivers for the FT232BM and the PL2303HXD are excellent and really show what the devices can do.

Knowing which CH340 cable is genuine, working copy or non-working copy is impossible from a picture and the FTDI UC232R has a driver problem with RTS/CTS handshaking. This leaves the Plugable PL2303HXD based adapter as the only cable that I tested which performed correctly with both applications but, for a desktop PC, purchasing a PCI-E serial card would be a better option.

home contact