It depends on the test method and the characteristics of the receiver.

If you have a bit error of 0.94%, then over ten bits (start, 8 data,
stop) you have a bit that is off by nearly 10%.  For the sake of
discussion we'll assume that the bits are 0.94% too big.

Now let's assume an ideal receiver: it is perfectly timed, and samples
exactly once in the middle of each bit.  In this case your last bit,
being 10% off, is still sampled correctly.

Now let's assume a non-ideal receiver.  Let's say that its bit error
is 2%, and that it samples the middle 50% of each bit 3 times.  This
means that it takes three samples per bit - once at 25% of the bit
time, once at 50% of the bit time, and once at 75% of the bit time. 
This is used to decrease the effect of spurious noise.  We'll further
assume that its bit time is short by the 2% error.

After ten bits it's early by 20%, and you're late by 10%.  The
mismatch is 30%, well after the moment when it sampled its first bit.

Most receivers simply take the majority, and since two of the
receivers samples are still withint your bit time then it should be
fine.

But note that 2% is still considered a reasonable RS-232 signal.  What
if it's 4%?  That puts your signal right at the 50% sampling point,
and it's anybody's guess as to what got sampled.  What if your clock
is also pulled off frequency (temperature, caps, bad crystal, etc) and
while your calculations say you're off by only 1% you are actually off
by 1.5%?

Further, how does the receiver start clocking in bits?  Does it sample
for a start bit 16 times per bit time (as the PIC does) meaning that
it may start off with as much as a 6% error?  If it only samples 4
times per bit time (many bit banged receivers do this) then it may
start off with a 25% error!

0.94% is not too much error - it's actually very good.  I would look
at the receiver a little bit and see what its characteristics are.  I
would then take a look at the transceivers and transmission line.  If
you are using good rs-232 level converters and good wires then you may
be ok, but if you're practicing with just TTL between two devices and
a meter of wire it may be the problem.

Try to characterise the whole system.  When dealing with networking
and transmission stuff you can't treat everything else as a black box.

-Adam

On 5/2/06, Info <info@datech.se> wrote:
> Did some tests today and it worked fine at 38400 baud.
> 57600 baud and above failed miserabely.
> Used the code that Maestro generates, PIC18F458 at 40 MHz
>
> 38400 baud: the calculated speed error is  0.16%
> 57600 baud: is 0.94% error.
>
> Is 0.94% too much error?? Or why would it be so terrible result?
> (More than 50% of the echoed chrs were random)
>
> > > I've done 115,200 baud reliably on a 18F452 with a 18.43Mhz crystal
> > > using HiTech PICC, all interrupt driven.
> > > One thing to check is the accuracy of the frequency division for the
> > > UART generator.   I figured I could do 115K baud reliable with a 20Mhz
> > > crystal (about 3% error), but the EE in charge wanted to have an "exact"
> > > frequency division for baud rate accuracy.
> --
> 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