# PL-2303TA TTL UART data corruption

For a lot of projects, I use a fairly common USB to serial dongle called "Prolific USB to Serial" which uses a PL-2303 TA chip to allow USB to 3V TTL serial (i.e. this kind on Alibaba).

I actually got it on Amazon though - but basically it's the same hardware.

## Disclaimer

Before I go on, I'm aware from the Prolific website.

Please be warned that counterfeit (fake) PL-2303HX (Chip Rev A) USB to Serial Controller ICs using Prolific's trademark logo, brandname, and device drivers, were being sold in the China market. Counterfeit IC products show exactly the same outside chip markings but generally are of poor quality and causes Windows driver compatibility issues (Yellow Mark Error Code 10 in Device Manager).

Now I don't see any warning triangle on the device manager and this is a PL-2303TX not HX chip -- but I'm suspicious that these probably came from the China market, i.e. Alibaba.

Anyway, end of disclaimer.

## Issue

The dongles work fine, except for when sending a particular message I've discovered since we use MODBUS for a lot of communication. The message below is what I am sending using RealTerm.

0x01 0x03 0x00 0x1C 0x00 0x01 0x45 0xCC


The scope images were taken with probe directly into the dongle output - i.e. the TX / RX / GND outputs were not connected to any hardware.

The problem is I only see this 50% of the time. Instead, sometimes I see the data below, when I don't change the message (just keep clicking "Send Numbers" on RealTerm):

Which is weird, and I have only seen it with these dongles. The even weirder thing is if I change the message to this:

0x01 0x03 0x00 0x1B 0x00 0x01 0x45 0xCC


(i.e. 1B instead of 1C -- ignoring changing the CRC i.e. the last two bytes of the MODBUS frame) -- it works 100% of the time!

I wonder if any one else has had any issue similar to this? -- and hopefully I haven't answered my own question with regard to the counterfeit issue. This issue doesn't appear to occur with an RS232 dongle that I have. Latest drivers for the PL2303TA don't appear to help. I was using 9600 baud , but saw the same problem with 57600 baud so is probably baud independent.

• Try a different terminal program, like hterm. Your problem might be within realterm software. Feb 13 '19 at 14:10
• Good observation, actually I missed out that I had started with other software first (CASModbus Scanner) and had this issue, I thought it was that software that was causing it which is why I went to RealTerm -- but same problem. I guess it's just a driver problem with specific output "0x01 0x03 0x00 0x1C..." Don't know why yet though. Feb 13 '19 at 14:42
• You probably need to take a look on what is happening on the USB side of this link. Feb 14 '19 at 19:20
• Also, what do you mean "ignoring CRC"? Which CRC? Who calculates it, and where does it go in the stream? Feb 14 '19 at 20:48
• The CRC is always the last two bytes of the MODBUS data stream, it is not important in this case as it is not related to the issue, I was just meaning that by chainging the 1C to 1B the message on the scope is a consistent message albeit an invalid MODBUS message as I hadn't changed the CRC to suit. I was doing it manually for the record so I couldn't be bothered working it out! Feb 14 '19 at 23:44