RS232 over USB, PL2303

[NorthGuy]

I'll give it a try, thx NG.

That's actually was T's idea.

You can also increase resolution if you go lower rates. E.g. if you go 4800 (needing 4625) you can do it with 2MHz clock.

 

[rumpfy]

I think the 'A' in ascii stands for "asynchronous".
So the send clock and the receive clock need to be closely tuned. I dont know what the tolerance is but there will be a number for it. 3.55 sounds wrong. I would guess it should be less than 1 percent. After 8 or 9 time slots, you could be getting garbled characters due to the LSB being read incorrectly.
Hope this helps

 

[Mosaic]

Well after trying to correct for the 3.55% error...things improved marginally.
So more digging revealed that the PL2303 cable varies by up to 20 uSec long on a single bit pulse. Can't say why but the tolerance is offspec and similarly so with the other Pl2303 HX cables that I have.
I dropped the speed to 2400bps which is stable as far as PL2303 data comms go. This means to me that the 'drift' of the clock is what's the problem. The significance of the errors at 2400 bps are shrunk to 25% that of 9600 bps, bringing the comms into spec.

ASCII = American Standard Code for Information Interchange

EDIT:
As a method of averaging the net 'drift' I transmitted about 20 characters from the PC thru the Pl2303 cable for the Digital scope to log the bit transitions. With no change to the trigger or the data, resending the data a few times showed the last data bit pulse 'moving' around by up to 20 uSec, demonstrating the erratic transmissions and the effect of good data, bad data, good data that happens as the drift floats in and out of spec.

 

[rumpfy]

You're right. its been a few years since i did serial data transmission; BUT, the system IS asynchronous. Hence you will see timing errors and faulty decoding on the LSB.
I remember years ago we had a HP 3000 computer sending data all over a campus style layout. Our section was at the end of a 500 metre run of pvc insulated multipair cable. The baud rate on that system was 9600. The cables were driven with a really low impedance line driver and for all the years the system ran, I was NEVER aware of data errors. We had dumb terminals connected and the thing ran just fine.
I still think the timing is the problem in your case and when you get the data rates tuned together, I believe your problems will be over.

 

[Nigel Goodwin]

You're right. its been a few years since i did serial data transmission; BUT, the system IS asynchronous. Hence you will see timing errors and faulty decoding on the LSB.

The whole point of RS232 is that it re-synchronises after every byte (that's what the start and stop bits are for), unless your timing is out by a considerable margin then you won't see any faulty LSB problems.

If his timing is out that far, then he's got a problem somewhere.

Incidentally, 9600 baud is flawless on a PIC even using the internal RC oscillator, it's not terribly critical.