> > At 115k the first line *always* drops several of chars *before* the first > > CRLF. Never the same chars. The rest of the screen is almost always > > flawless, drops a few here and there, only about 2-3% of full screens have > > an error. But I can induce a few more drops by making Win 'do something' > > such as switching to other windows. ............. > You've already shown that system loading effects the error rate. Obviously > that's not a hardware problem. (There may still be one, however. Write a > loop to dump the same character continually and look at everything with a > scope.) I think that the advice you are getting from a number of people is correct and that the problem is almost certainly a Windows one BUT be wary of ever eliminating any cause with certainty :-) - aim instead for a probabilistic estimate. Conclude that a hardware problem is almost certainly not occurring but realise you can still be fooled. That way your brain can mull over in the background the small possibilities which MAY just happen to be what's really occurring. (Many people's brains appear to do this quite well :-) ). While it is almost certain that you are not having a rate related hardware problem there may be mechanisms by which this can occur. eg In this case every time the driver makes a switching transition it may draw significant extra charge from the high voltage reservoir (depending on IC design). More transitions equals lower reservoir voltage. If this is the case then there will be a certain number of transitions per second above which your levels will start to drop significantly. The mix of characters and RS232 receiver decision levels will then affect the result. You can *virtually* eliminate this as a possibility by using, as suggested above, a scope: 1 - Look at voltage levels of the RS232 line with a scope. Do they drop with speed or character mix. Look at the reservoir voltages. Do they change? 2 - Send the same character repeatedly. Do you still get the same errors. Try a best case and worst case character* . Does the result change? Sync the now unchanging character on a scope. Do you EVER get any variations in the pattern. (Sanity check: Program the sender to send 1 different character per say 10,000 characters - does this show on your scope?). The driver device in use will presumably have a maximum specified data rate (and these can vary over several decades of speed depending on type) - presumably you are not exceeding the speed spec at maximum rate. * Worst case character is arguably $AA as it contains a transition at every possible bit edge. A sequence of these sent continually with 1 stop bit produces a steady square wave at the baud rate and is impossible to synchronise correctly with certainty by a UART which encounters the stream after its start. (Which in fact ALMOST doesn't matter as the output result will produce $AAs where-ever you sync it and an error will occur only AFTER the last $AA has been sent!). Consider adding a second stop bit for test purposes (or a small delay of less than 1 extra bit between characters). An end to end data stream can be hard to regain sync on once it is lost. Odds are that it's not the hardware. But a suitably small amount of paranoia can save you from the "Well. I KNOW it's not the hardware" fatal trap. While I'm here - the comments on where to return the pump capacitors to proved much more interesting and complex than may have been expected at first glance. Many of the answers given were right enough in their context but somewhat less than rigorous in the widest sense (including ones by both myself and Olin). It was stated by various people that the startup time both does and doesn't depend on where the cap is returned to. The "doesn't" argument assumed that the cap had to charge from 0 to say 10 volts at startup regardless of whether the return was 0 or 5 volts. In fact, IF the main power supply rises from 0 to 5 volts much more rapidly than the pump voltage rises, it will "carry" both ends of the capacitor to 5 volts and then the pump can charge it the rest of the way. In this case, the startup time will be reduced by returning the cap end of the +ve cap to 5 volts. I don't think startup time is liable to be significant in all but the most borderline of designs but it's worth noting that any decision that relies on such timing needs to have all the assumptions on which it is based explicitly identified. Re correct value but right value of capacitor. A non polarised capacitor is liable to be superior to a polarised one but a polarised one is liable to be entirely OK here except at the extreme limits of operation. usually the manufacturer will (probably) spec the caps so that something else will fail first. Any modern non polarised cap is liable to be OK as a reservoir. The pump caps are somewhat more sensitive to characteristics than the reservoirs as they take switch the entire pump energy rather than just smoothing the variations. Again, use of a 'scope will tell you whether things areas they ought to be. Russell McMahon -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu