RS232 over USB, PL2303

Status
Not open for further replies.
If I were you, I would remove everything from your program for a while and would leave only a small part which sends known codes and then tried to see if the received codes match the sent codes. This way you'll know if it is a problem with UART or some sort of interference from the other parts of the program.
 
Ok, I grabbed about 250mS worth of Tx data using a digital scope's one shot trigger.

When compared to the Terminal ASCII display it turns out that the Scope data log shows perfect 104uS bit transmissions which match the expected data. The received ASCII data is different to the transmitted data as defined by the scope log.
I tried a second PL2303 which showed similar, but lesser probs. I know the USB interface is good as I run my PICKIT2 from it.

Maybe these <$3 cables have their problems?
Is there a better quality RS232 over USB cable?
 
It is strange that some codes are missing completely while others are perfectly intact. As if the line would go down for short periods of time. May be a bad contact? It also could be a software problem on the receiving end.

Do you have a real COM port on your computer? Even new PCs often have COM connector on the Motherboard. Look at the BIOS setup. If there's enable/disable COM1 there, you can find it.
 
The PC is an old Duron (1GB, win xp) so it has real com ports. Are you saying to wire up a db9 and use com1? I would need to level shift then?
 
Since your verified that your MCU produces the correct code, you have 3 things that are suspect - bad ground, bad USB link, or bad PC software. You need to eliminate them one-by-one until you find a bad one.

To eliminate USB link, you need to connect to COM port directly. Yes, you would need some sort of IC such as MAX232 or some custom-made curcuit to connect it. But it seems to be the only way to bypass the USB link.

Or, you can suspect that you have a bad ground. Then you can re-wire things so that your MCU is USB-powered (or battery-powered with common ground with USB) and see if the problem goes away. I don't suggest doing that permanently, only to test and see if the ground is a problem.
 
I powered the Mcu from the USB...same results. That leaves building an rs232 link. I do have max 232 and FT232 chips on hand.
 
Can I suggest your problem might be with the cable bandwidth. You dont say what transmission distance you are sending over, but if you driver cant supply sufficient current into the cable capacitance, you will finish up with rounded, delayed pulses at the receiver.
If the cables you are using are PVC insulated, this will raise the cable capacitance. Try some polyethylene or polypropylene insulated cable. Another problem might be your cable is a multiple single core conductor cable whereas you may need a twisted pair type of cable. Maybe try running the data circuits in 93 ohm coax.
Hope this helps.
 
I never did give those specifics...but here is the item
**broken link removed**

1 metre long molded USB /rs232 4 wire cable. Sometimes I get good data, but as the data gets larger most times it's missing digits. 50% chance of good data, IF < 100bytes.
Chip is 'genuine' prolific HX/HXA, based on the chip detect executable in the driver.

Also this:
https://www.spinics.net/lists/linux-usb/msg96609.html
is interesting, as I am losing bytes.
 
Update:
I used the UART tool in the PICKIT2 ...all data received reliably as transmitted. Logged to a txt file and imported into Excel as comma delimited . All went well.
I guess that leaves the prolific PL2303 cables as the prob.
 
So do you need more help?
I have some experience with uarts/rs232/25pin connections/cable characteristics/ gained from the 1970's. I think North Guy is clued up on the more modern hardware stuff and has a lot to offer. When you go on about the hardware you have I've no idea what yr talking about. Remember that the 9600 Baud is SLOW so the problem may have something to do with how the ground referenced data from the uart is being transmitted. It shouldnt need a USB to send that stuff a couple of meters to the receiver. So there might be some problems around maybe you are using USB balanced pair cable for a ground referenced signal; or maybe there is unwanted coupling between the various transmission wire in the cable. Ground referenced signals should be transmitted on say coax cable, or single conductor cables; balanced data circuits must use balanced pair cable.
Hope I'm not telling you how to suck eggs, but the problem sounds like one of those silly things that happen in life and when you solve the problem you kick yourself.
 
Based on what i see in the corrupted data sections, the prolific cable is also swapping data around. Eg. byte 10 comes after byte 12. That says to me that some driver buffer pointer is over running every so often, causing later data to mix with earlier data, then it gets good for a bit and happens again.

The matter of cable grounding/balanced pair doesn't factor as I can run the PIC directly off the gnd & Vdd supplied by the PL2303 cable, with no external power and the same result happens. Also I am running the PIC off a 2 prong nokia 'charger' which is isolated and has no true earth.

Since this is half duplex....there is no transmission wire coupling in a 4 wire device, rx, tx, Vdd, gnd.
 
Mosaic said:
I guess that leaves the prolific PL2303 cables as the prob.
Click to expand...

Skipping entire codes without any damage to anything else looks more like software problem. I think the PL2303 firmware is to blame. You posted a link where people have seen it doing the same thing.

I agree with rumpfy that there's no need for USB at 9600. But if you do need USB, there are other varieties of USB/UART converters.
 
I had another go at this PL2303 issue. The cable has a fairly high accuracy rate (99+%) when I use it with a loop back so the Tx feeds the Rx.
Nevertheless it's very dodgy from the PIC signal, sending 100bytes takes multiple tries for a clean uplink. . The same PIC data is perfectly received via the PICKIT2 UART tool, no errors at all. All power supplied by the USB itself so no ground loop issues.

I am wondering if the PL2303 might have a timebase error which adds to the PICs -.16% period error, which can cause an occasional data dropout. I suppose grabbing a sample of a PL2303 transmission on the dig. scope might reveal such an issue.

Edit:
Ok I checked the Tx clock of the PL2303...it is 108 uSec per bit period or 9259bps....
The Tx clock off the PIC is 104uSec per bit period = 9615 bps

The PL2303 is about 4% SLOW........

I note a 12Mhz crystal onboard the PL2303...is there any way to alter the caps to get that to reduce this % error?
 
Last edited:
4% slow compared to what.. maybe the device reading the dataline is 4% fast.
 
9600,n,8,1 => 9600 bit per sec or about a 104 usec period per bit.
The PL2303 is clocked at 9259 bps... so its offspec by 3.55% , possibly more due to temperature variations. I checked it with a 100Mhz scope capture.

I have identified a cheap crystal replacement to reduce the error.
A crystal running at 12.426 Mhz should be spot on. I see a 12.288 Mhz for $0.18 at Newark of matching dimensions and mounting.
https://www.newark.com/fox-electronics/foxslf-128-20/crystal-12-288mhz-20pf-thru-hole/dp/61T5317

That should reduce the error to .138/12.426 = 1.11% which is in spec for RS232 tolerance. I have about a dozen of these 'defective' cables on hand.

I base this on the following:
The 16C550 UART statemachine uses a
16x over-sampling statemachine for detecting the NRZ bit-frame,
(start/stop + each data bits). Given this, we have a 1/16 per bit
frame detection that is used by the 16C550 silicon. This gives us a 6.
25% per state detection for the UART.

So...if we say that for adequate and reliable bit-frame detection, we
require at least 1/2 an LSB for bit-acquisition, this gives us a value
of 1/32 which equals 3.125%.
 
why don't you just match the receiving end to the baudrate.. no need to adjust capacitors etc.
 
Mosaic said:
Um, how do you suggest I do a 3.55% shift in the bps?
Click to expand...
Did you measure the timing at the receiving end? If not, how do you know you need a 3.55% shift. And why do you have dozen of these defective cables.. are you in the business of buying and reselling shitty cables? Worst business plan ever.

I have two "Belkien FSU103v" usb to uart cables.. both of them crashes my win7 after 5 minutes of use. If you buy shitty cables, the best you can do is to throw them in trash..
 
Last edited:
NorthGuy said:
You simply set the baud rate on the PIC to 9250 instead of 9600.
Click to expand...
Not so easy to do with the hardware EUSART. The BRGH stepping @ a 2Mhz Fosc works out to 7.69%. So the next step down is 8861 bps.

Looks like I have to go with a 4Mhz clock to get 3.8% step down (9245bps). I'll give it a try, thx NG. At least it will verify the solution before I change any crystals.

misterT said:
Did you measure the timing at the receiving end? If not, how do you know you need a 3.55% shift. And why do you have dozen of these defective cables.. are you in the business of buying and reselling shitty cables? Worst business plan ever.
Click to expand...

I created a battery Capacity (Ah) kit published here on ETO which calls for RS232/USB. The PL2303 is suggested as the FTDI cables are about 4x the price. Thus I needed to solve this issue for the benefit of the kit users. I never buy 1 part when I am prototyping, I purchased different PL2303 cables (latest chip & firmware) from 2 Ebay suppliers to verify compatibility. I design for as much real world variability as I can.
 
Last edited:
Status
Not open for further replies.

Similar threads

F
  • Question
CH348 USB – Octal USB GPIO Registers
Replies
2
Views
4K
For The Popcorn
F
P
Which MCU for translating usb-midi to control LED lighting?
2
Replies
28
Views
9K
be80be
B
USB PIC Programmer with 40 pin Zip socket
2 3 4
Replies
68
Views
3K
be80be
  • Question
Bi-Directional RS232 problem?.
Replies
16
Views
3K
Nigel Goodwin
MPLABX , and USB tools
Replies
5
Views
5K
Pommie
P
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…