Jinx, Point taken. I was just thinking of a way to perform a quick and dirty test to see if timing were the problem. And this is probably the way I would have done it. But as you say, the difference probably wouldn't be obvious from an observers point of view, so it would most likely be a waste of time. In that case, I would look at the signal with a scope. Of course, I don't know whether the original poster has a scope or not, so that may not be the answer either. In any event, it was just a suggestion off the top of my head that made sense at the time. In retrospect though, I see your reasoning and must admit you make a good point. With the amount of knowledge, and willingness to help, that is available on this list, I'm sure the OP will get to the bottom of his dilema, and in short order. Regards, Jim > > >> And that's exactly the point. If this works and it takes longer to >> see an error, then it follows that the timing is the culprit, and >> means can be taken to correct that problem. > > Jim - I appreciate the logic, and it's too nice a day to be quibbling, > but as the OP is using a crystal he should be able to work it out > mathematically **. "longer" is not that long on the scale of one byte > at 9600 baud. I should have said "the error will take longer to happen" > rather than see, and the difference, even if you dropped from 9600 to > 300, would probably not be detectable by the eye as eg s/w drops > out. Unless you were actively looking for an error difference, changing > the baud rate may not appear to be changing the failure symptom > > ** assuming the output from the PC is an accurate and reliable 9600 > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist