At 01:51 PM 7/11/00 +1000, Tony Nixon wrote:
>Hi all,
>Does anyone know what a maximum error percentage would be for reliable RS232?
>Is there a spec on this?

Exceeding 10% error in timng is fatal, but that error includes error in
timing on the other end.
I've always felt that the error budget should be split, and I try to not go
over 1% on my end, because I want my stuff to work ALL the time.

I've "heard" 10% of frequency. However I've also met devices which
could not cope with more than about 5% in one particular direction.
I vaguely recall a specification ... but if it exists it also implies
that there are implementations which do not comply. ;-}

At 03:29 PM 7/11/00 +1000, you wrote:
>G'day Tony,
>
>I've "heard" 10% of frequency. However I've also met devices which
>could not cope with more than about 5% in one particular direction.
>I vaguely recall a specification ... but if it exists it also implies
>that there are implementations which do not comply. ;-}

The 10% comes about in that if you're 10% off on bit timing, then by the
end of 10 bits, you're off by a whole bit.
Fatal error.

The receiving device also has it's own idea of what 9600 baud (or whatever)
is, and may be of by a suprising amount.

You can calculate it yourself, but (I think the max is ~ 5%) but that is
for both sided together PLUS any unaccuracy due to edges, cable capacity
and such. To be on the safe side I would suggest =< 1% for sender and
receiver each. There is an RS-XXX standard for I think 'start-stop
tranmission data quality' that gives some figures for a few classes of
devices. I have it at work, not here at home.

There is no error specification for RS-232. You have to calculate your
acceptable error and stick with that.

You can safely assume that all RS-232 receivers test the bit within the middle
third of each bit time. Given ten bits, this means that the stop bit must still
be valid through the middle third of the signal:

___ ___ ___ ___ ___ ___ ___ ___ ___ ___
\___X___X___X___X___X___X___X___X___/ X___
T T T T T T T T T
This means that the longest your entire ten bits can take to transmit will make
the stop bit start right at the beginning of the middle third of where the real
stop bit should be, and the shortest will end the stop bit at the end of the
third of where the stop bit should be.

A full 10 bits at 9600 is 1.042mS. The beginning of the test period for he stop
bit is at 9 1/3 bits, or 972 uS. The end of the test period for the stop bit is
9 2/3 bits, or 1.007mS.

The shortest frame of data (all ten bits) you can have and still have a valid
stop bit according to the receiver specified above is 1.007mS. The longest
frame of data will send 9 bits of data in 972uS, completeing the full ten bits
in 1.08mS. The following table shows the error (in percent) for each of the
above scenarios:

Now, this is under the assumption that the receiver tests the bits within the
middle third of each bit (almost universally true for hardware UARTs, iffy for
software (bit-bang) UARTs), and also that the receiving UART is running at
exactly 9600 bps.

If, however, the receiver is off by as much as the above percentages, then you
would still be ok as long as the receiver tests each bit in the middle of the
bit exactly, rather than within the middle third of the bit. Most hardware
UARTS will take 1 or three tests right in the middle of the bit, so if they are
3% too slow, and you are 3% too fast, then you would still have a very good
chance of being heard correctly, but I wouldn't bet my product on it. If you
are communicating with a computer, you can pretty much assume they are working
within 1%, and testing at the middle of each bit, meaning you could have a
greater than 4% error. But you should know that someone, somewhere will use
your product without a computer, and will wonder what's wrong when it doesn't
work.

Ideally one would try to stay below 2% if one has to have any significant error
at all. For any commercial product (unless there are specific reasons for doing
so) you can and should stay below 1%. For hobbyist projects and one-offs, up to
6% is probably fine, but I wouldn't like it.

From this table it is easy to see why the often quoted 1.5% is used, as it is
assumed half of the error could be at one end, and half at the other end of the
link. This error allowance includes all sources of error, i.e. crystal from
which baud rate is generated, inaccuracies in the baud rate divider ( check the
spec sheet - because integer dividers are used and some ratios are non-integer
there are errors) as well as rounding of the wave forms under long line
conditions.

If you have less than 1.5% error at your end, then all should work
satisfactorily.

Hrm, this implies that to communicate without regard to clock accuracy
one could reduce to one bit per word, and then the receiver could
determine the rate by measuring a start bit time ... is there a name
for this form of protocol?

James Cameron wrote:
>
> Hrm, this implies that to communicate without regard to clock accuracy
> one could reduce to one bit per word, and then the receiver could
> determine the rate by measuring a start bit time ... is there a name
> for this form of protocol?
>

I don't know how you can measure the start bit time if the 1st and or
subsequent data bits are the same state.

This only works if the start bit is followed by the opposite line state for
a little while. Actually, you would not be restricted to a single bit per
word:

The line is idle (say a 0 on the input).
Send a start bit (a 1) for time N.
Send a dummy bit (a 0) for time f(N), where 'f' is a function of N. For
example f(N) = N or f(N) = N/2.
Send a group of data bits (1 or 0) for g(N) time each, where 'g' is another
function of N.
Return the line to idle.

The old Commodore 64 (and others??) used an asynchronous floppy disk drive.
I don't remember all the details but I remember that it used a certain
number of characters in a certain sequence that would not be possible in a
data sequence. This was how it determined the beginning of a track. This may
not be entirely relevant because the speed was fixed but there may be some
parts of the algorithm which may be pertinent.

>> Hrm, this implies that to communicate without regard to clock
>> accuracy one could reduce to one bit per word, and then the
>> receiver could determine the rate by measuring a start bit time
>> ... is there a name for this form of protocol?

I've almost always heard it called "auto baud".

> I don't know how you can measure the start bit time if the 1st
> and or subsequent data bits are the same state.

In asynchronous serial communications, the stop bit forces
a transition at the leading edge of the start bit.

For it to work properly, there has to be a transition at the
trailing edge of the start bit. So the low order bit of the
first character sent (the one used to measure the start bit
width) has to be a 1. Conveniently, the US ASCII character
carriage return has this property.

There also has to be some mechanism to reenable the automatic
baud rate detection when the transaction, session, time limit,
or whatever is complete.
Lee Jones

The percentage of error that can be tolerated is 10% MAX in the
best-case-scenario. This value is arrived at by dividing one bit
time by the total word time. In the case of a standard UART this
means 1/(1+8+1)=10% since there is one start bit, 8 data
bits, and 1 stop bit. Note that if you add a parity bit, then
you get 1/11, or 9%.

But that is best-case scenario. In the real world you would want
to at least keep the error to less than 5%, since there are also
timing errors that can creep in at the *other* end as well.

You will be in excellent shape if you can produce timing to within
1%. This is easily handled by the built-in UARTs, and is also
readily attainable with either isochronous code (equal-timed code),
or interrupt driven code.

Crystals are excellent. Ceramic resonators are also quite good
and I have never had a problem with them in UART applications.
RC timing is not a good idea, since the timing is too dependant
on temperature and other factors.

Tony Nixon wrote:
>I don't know how you can measure the start bit time if the 1st and or
>subsequent data bits are the same state.

You measure the time of the whole character (knowing the protocol and the
character !) and discard it. The next chaacter will be received correctly.
The data source should use pacing when sending initial training chars.
Terminals pace after '\r' by default ....

James Cameron wrote:
>Hrm, this implies that to communicate without regard to clock accuracy
>one could reduce to one bit per word, and then the receiver could
>determine the rate by measuring a start bit time ... is there a name
>for this form of protocol?

I don't understand your wording exactly but there are two ways to use
clock recovery: with bit stuffing and without. The second method requires
a good PLL. Floppy disks retrieve serial data like this afaik. Basically
each transition in the input stream is used to sync a PLL that runs at a
multiple of the baud rate (eg. 16 times or more). 32 times looks good
because of the achieved error range (~3% f.s.). See my other posting. Any
protocol based on such a scheme is called a 'self clocked transmission
protocol' afaik.

The other more brute force system is called autobauding and applies to
normal serial data (RS232) where the transmitter sends a certain number of
well-known characters and the receiver uses the patterns to select or tune
the baud rate before transmission continues. Serial terminal driver code
in hosts knows how to do this f.ex. (based on '\r' s sent by impatient
users at terminals).

David van Horn wrote:
>Exceeding 10% error in timng is fatal, but that error includes error in
>timing on the other end.

I am under the strong impression that 3% total is the limit for 8N1.
Because the last known reference is the start of the start bit, and one
needs to read within the center 33% of the stop bit. That's 9.5 bit times
ahead and allowed range is 9.3 to 9.6 So the total timing error should be
0.3/9.3 bit times or better. 0.3/9.5 = 0.03157 ~= 3%. So each end should
be 1.5% or better accurate. Did I oops something here ? Apropos, accuracy
needs to be even better for 8O1. And this brings us to the 'almost right'
baud rate obtained by using the dividers in PICs and other micros with
UARTs...

BTW 508 and 509 code that implements auto speed tuning for RC clocked
operation and RS232 comms requires the same accuracy in the timing tuning
code. Been there...

At 08:07 PM 7/12/00 +0300, you wrote:
>David van Horn wrote:
> >Exceeding 10% error in timng is fatal, but that error includes error in
> >timing on the other end.
>
>I am under the strong impression that 3% total is the limit for 8N1.
>Because the last known reference is the start of the start bit, and one
>needs to read within the center 33% of the stop bit.

Depends on the uart. Some sample at or around center, some oversample and
average.
10% is fatal, 5% may be fatal, less is better :)

> > I don't know how you can measure the start bit time if the 1st
> > and or subsequent data bits are the same state.
>
> In asynchronous serial communications, the stop bit forces
> a transition at the leading edge of the start bit.
>
> For it to work properly, there has to be a transition at the
> trailing edge of the start bit. So the low order bit of the
> first character sent (the one used to measure the start bit
> width) has to be a 1. Conveniently, the US ASCII character
> carriage return has this property.

This is why Hayes commands start with "AT", enables baud, parity, and
wordlength detection. Has nothing to do with "ATtention". ;)

Peter Peres wrote:
>Tony Nixon wrote:
>>I don't know how you can measure the start bit time if the 1st and or
>>subsequent data bits are the same state.
>
>You measure the time of the whole character (knowing the protocol and the
>character !) and discard it. The next chaacter will be received correctly.
>The data source should use pacing when sending initial training chars.
>Terminals pace after '\r' by default ....
>

Tony,

I pretty much agree with Dave Van Horn, and others, that the worst
case scenario that might just *barely* work is 10% error - meaning no
more than 5% error on each end - transmitter and receiver. Personally,
in situations like this, I try to apply a rule of thumb of allowing
*at least* a 2:1 safety margin over worst case - or 2.5% here.

You will notice from the PIC datasheets that using the built-in
UART, you get nominal errors to 3% or so with most xtals shown
[ignoring cases with > 5%]. The UARTs only give < 1% in certain
cases - not many.

Similar to what Peter indicated, I have the host send several
CR [0Dh] characters, and I cycle the chip thru a series of SPBRG
divider values until it recognizes a valid CR. This is essentially
a 10-bit timing check, rather than just the start bit. It rarely
fails, except in some cases at 3.57 Mhz [don't know why ?????????]

I have also found that the chip will normally boot ok with many xtal
values that are within a couple % of those shown in the table, eg,
1.024, 4.09, 4.9152, 19.6 Mhz, etc, so this adds another 2% or so
to the errors given in the table.

Actually, that's what ATtention means. When a user enters 'AT' into
their modem and transmits it, it is saying to all listeners on the
line to "Hear this and adjust thyself, More is on the way". It's a
reserved starting symbol for the Hayes modem language, if you will.

>
> > > I don't know how you can measure the start bit time if the 1st
> > > and or subsequent data bits are the same state.
> >
> > In asynchronous serial communications, the stop bit forces
> > a transition at the leading edge of the start bit.
> >
> > For it to work properly, there has to be a transition at the
> > trailing edge of the start bit. So the low order bit of the
> > first character sent (the one used to measure the start bit
> > width) has to be a 1. Conveniently, the US ASCII character
> > carriage return has this property.
>
> This is why Hayes commands start with "AT", enables baud, parity, and
> wordlength detection. Has nothing to do with "ATtention". ;)
>
> --
> http://www.piclist.com hint: To leave the PICList
> RemoveMEpiclist-unsubscribe-requestKILLspammitvma.mit.edu

> I pretty much agree with Dave Van Horn, and others, that the worst
> case scenario that might just *barely* work is 10% error - meaning no

10% error would mean a discrepancy between sender and receiver of half the
bit time after only 5 bits, so the receiver would sample half of bit 5 and
half of bit 6 to determine the next bit. Chance of success very small, even
when then receiver oversamples N (N large) times and applies a majority
vote. Such an ideal receiver could tolerate and error of just *under* half
a bit cell after ~ 9 bits (1 start + 8 data, 10 when the receiver checks
parity, even more when it checks stopbits). So roughly half a bit error
after 10 bit times => 5 % TOTAL discrepancy, that is: sender error +
receiver error + fuzzy edges + etc. So being fair to both sides 2 % each
when your cable is ideal, 1 % each when it is not so ideal and you want to
keep some noise tolerance.

Wouter wrote:
>> I pretty much agree with Dave Van Horn, and others, that the worst
>> case scenario that might just *barely* work is 10% error - meaning no
>
>10% error would mean a discrepancy between sender and receiver of half the
>bit time after only 5 bits, so the receiver would sample half of bit 5 and
>half of bit 6 to determine the next bit. Chance of success very small, even
>when then receiver oversamples N (N large) times and applies a majority
>vote. Such an ideal receiver could tolerate and error of just *under* half
>a bit cell after ~ 9 bits (1 start + 8 data, 10 when the receiver checks
>parity, even more when it checks stopbits). So roughly half a bit error
>after 10 bit times => 5 % TOTAL discrepancy, that is: sender error +
>receiver error + fuzzy edges + etc. So being fair to both sides 2 % each
>when your cable is ideal, 1 % each when it is not so ideal and you want to
>keep some noise tolerance.
>

Take a look in the SPBRG table - you're sure gonna have a lot
of trouble getting 1% using the PIC UART with anything other
than a 16 Mhz xtal.

As I mentioned last time, I've used lots of different baudrates
with lots of different xtals, with average error rates of 2-3%,
and haven't had any trouble - but then, I never use cables longer
than 12 feet [about 4M], ie, two 6' cables thru a switchbox.

>
>Take a look in the SPBRG table - you're sure gonna have a lot
>of trouble getting 1% using the PIC UART with anything other
>than a 16 Mhz xtal.

Which is why they make crystals in even multiples of baudrates.
4.096 8.192 16.384...

>As I mentioned last time, I've used lots of different baudrates
>with lots of different xtals, with average error rates of 2-3%,
>and haven't had any trouble - but then, I never use cables longer
>than 12 feet [about 4M], ie, two 6' cables thru a switchbox.

The thing is, it's a shared error budget. You never know how much the other
guy is using up.

Wouter wrote:
>Dan wrote:
>> I pretty much agree with Dave Van Horn, and others, that the worst
>> case scenario that might just *barely* work is 10% error - meaning no
>
>10% error would mean a discrepancy between sender and receiver of half the
>bit time after only 5 bits, so the receiver would sample half of bit 5 and
>half of bit 6 to determine the next bit. Chance of success very small, even
>when then receiver oversamples N (N large) times and applies a majority
>vote. Such an ideal receiver could tolerate and error of just *under* half
>a bit cell after ~ 9 bits (1 start + 8 data, 10 when the receiver checks
>parity, even more when it checks stopbits). So roughly half a bit error
>after 10 bit times => 5 % TOTAL discrepancy, that is: sender error +
>receiver error + fuzzy edges + etc. So being fair to both sides 2 % each
>when your cable is ideal, 1 % each when it is not so ideal and you want to
>keep some noise tolerance.
>

Yes, the really fun thing about this is once you finally sit down and
put it on paper, then you can come up with 2nd, 3rd, and maybe 4th
answers that each contradict the previous one.

For 8N1, you would ideally be sampling the last "data" bit, ie bit
#9 of 10, exactly in the middle, or 8.5 bit times after the start
bit began.

With a slow clock, you could sample as late as 9.0 bit times after
start before you had an assured error. So, .5/9.0 = 5.5%. Splitting
this between sender and receiver gives 2.75% max on each end [about
1/2 of my last answer <<<<<<<:-() = many dunce caps]. And a 2:1
safety margin would require selecting error < 1.5%. Botta bing.

Probably the reason the PIC UARTs work at all, given all the errors
present in the SPBRG table, is because the "host" computer uses a
xtal selected to "exactly" match the UART being used - giving very
little error on "that" end - so the PIC end has lots more latitude.
This must be why my Monitor chip will work with so many different
baudrates and xtal frequencies - the PIC is fuzzy, but the PC is
rock solid in the middle.

And looking in the h.w. book shows that PC serial cards have
classically used a 1.8432 Mhz xtal - exactly 16 * 115200, and
all other "std" baudrates follow exactly too, with ZERO clock
error.

OTOH, what about PIC to PIC serial comm? If both PICs use the
same xtal frequency and the internal UART, then both will have
the identical baudrate error, however bad - even 20%, and the
little network will work ok. But if you network PICs with
different xtals, or with others that uses bit-banging instead
of the internal UART - then life may be more uncertain. Yes?

Dave VanHorn wrote:
>>
>>Take a look in the SPBRG table - you're sure gonna have a lot
>>of trouble getting 1% using the PIC UART with anything other
>>than a 16 Mhz xtal.
>
>Which is why they make crystals in even multiples of baudrates.
>4.096 8.192 16.384...
>

Yeah, I can always make my baudrates spot on, but then my
1 usec timer is only 976.56525 nsec long. Which is the worst
evil? [I choose #1].
===========

>>As I mentioned last time, I've used lots of different baudrates
>>with lots of different xtals, with average error rates of 2-3%,
>>and haven't had any trouble - but then, I never use cables longer
>>than 12 feet [about 4M], ie, two 6' cables thru a switchbox.>
>
>The thing is, it's a shared error budget. You never know how much the other
>guy is using up.

Yeah, I solved this problem in my last msg. The PC is always spot
on, due to using a nice 1.8432 Mhz xtal, so it lets my PIC get
away with baudrate suicide [figuratively speaking].

>
> >Which is why they make crystals in even multiples of baudrates.
> >4.096 8.192 16.384...
> >
>
>Yeah, I can always make my baudrates spot on, but then my
>1 usec timer is only 976.56525 nsec long. Which is the worst
>evil? [I choose #1].
>===========

Here is a real-life story about how PC serial port baud rates are _not_
exact!

I had an application that required receiving an async serial data stream of
an unusual structure: 1 start bit + 240 data bits + 2 stop bits. Obviously
no hardware UART in the world is going to handle that. Also obviously, this
will be about 30 times as sensitive to timing error as 8N1 communications.

Well, I built a bit-banged UART based on a PC platform (actually an embedded
PC product). I needed a high-accuracy clock for sampling the input signal
(which I brought in through the CTS signal on COM1). Instruction cycle
counting was out of the question (with caches, poor documentation, etc.).

After a bit of thinking, I realized that if I programmed the UART to operate
at 9600 baud, 6 data bits, 1 start bit and 1 stop bit, that it would be
ready for a new character every 8/9600 of a second, or 1/1200 of a second
(my desired baud rate). So I just kept the transmitter supplied with dummy
characters (which I just let fall of the end of the TX wire), and every time
it was ready for a new one, I sampled the input on the CTS signal.

Well, everything worked pretty well on a desktop machine I started with, but
when I tried using the real hardware I started getting all kinds of comms
problems. I tried a bunch of different machines with varying levels of
success.

Well, to make a long story short, the problem is that the various PC's were
using various clocks for the baud rate. In fact, it seems that common design
practice these days is to find some 'close' frequency on the motherboard
that can be divided down to something approaching the correct input
frequency for the UART chip. I way errors of as much as 0.2%, which were
more than sufficient to kill my communications.

I solved my problem by recoding, basing my timing on the system timer chip
instead of the UART.

Bob Ammerman wrote:
........
>Well, to make a long story short, the problem is that the various PC's were
>using various clocks for the baud rate. In fact, it seems that common design
>practice these days is to find some 'close' frequency on the motherboard
>that can be divided down to something approaching the correct input
>frequency for the UART chip. I way errors of as much as 0.2%, which were
>more than sufficient to kill my communications.
>

Shoot, I guess you just can't rely on anything these days.
Leave out the 1.8432 Mhz xtal and save 23 cents. Sounds
like this might be a booby trap likely to be found when
using notebook PCs, and PCs with everything integrated onto
the motherboard. Life goes on.

> As I mentioned last time, I've used lots of different baudrates
> with lots of different xtals, with average error rates of 2-3%,
> and haven't had any trouble - but then, I never use cables longer
> than 12 feet [about 4M], ie, two 6' cables thru a switchbox.

And probably a PC on the other side that has only a very small error - did
you ever try two pics with errors +3% and -3%?
Wouter

Wouter wrote:
>> As I mentioned last time, I've used lots of different baudrates
>> with lots of different xtals, with average error rates of 2-3%,
>> and haven't had any trouble - but then, I never use cables longer
>> than 12 feet [about 4M], ie, two 6' cables thru a switchbox.
>
>And probably a PC on the other side that has only a very small error - did
>you ever try two pics with errors +3% and -3%?

Yeah, I addressed the PC probably having a perfect clock issue
in my email yesterday - [I now assume all 4 of my PCs - old 16Mhz
386 notebook, P100 notebook, 486-33 PC, and Pentium200 Pc all
have perfect clocks - ie, all use 1.8432 Mhz xtal on the UART
- what's the chance of that???].

And I also brought up another possibility - if you have 2 PICs
and they both use the same xtal value and both use the internal
UART, then both should also have the "same" clock error.
And they should work ok in a small network, no matter how large
the error actually is - both running 8640 bps, -10% for instance,
should still be ok.

HOWEVER - if you connect one of these error-monkeys to a
different uC, or a PC, then you have a problem.

My suggestion for such applications is not only to use accurate timing, but
also to use a DPLL receiver. One that looks for bit edges where it expects
them to be, and adjusts its timing when it detects the edges to be off. When
your data is guaranteed to have edges every now and then, you can receive
telegrams of any size.

Note by the way that with symbols of that size, even weak edges can upset
the timing, making the product flakey with long cables or wireless transmission.
The inherent adjustment of a DPLL can fix a lot of problems.

A DPLL would be great if I could ensure edges at any reasonable interval. I
cannot because I don't control the protocol. Luckily I know:

1: the sender is using an accurate (and precise) crystal controlled clock in
a room temperature environement.

2: I am using an accurate (and precise) crystal controlled clock in a room
temperature environment.

3: Time moves at the same rate everywhere in the universe ( :-) )

So... I luck out.

In fact, in this application a DPLL would probably be a _bad_ idea because
the data is fed thru 202 style (FSK) modems which can really shift the edges
around quite a bit on the detector side. Thus, the detector could get
easily confused and off frequency.

So, I just watch for the start bit, guess where it's middle is, and start
sampling away at one-bit-time intervals.

btw: In the real-world application I get almost perfect comms over (100?)
miles of phone wire.

Your chances are about zero. First, the crystal used is 18.432 if at all.
Second, untrimmed crystals 'computer grade' are 100 ppm at best and two of
these could be 100 ppm each in the opposite direction. 100 ppm is 0.1%.

Few people know that the Windows OS runs the system clock from the system
crystal, not from the CMOS clock. Anyone having systems on for a longer
time and not using clock synchronization finds this out soon enough.

Which leads to a good way to check the accuracy of the system clock w/o
tools. Let the machine run for 2-3 days, after setting the CMOS time
precisely to your wristwatches time (assumed to be fairly well checked and
accurate). Then calculate the deviation in percent from the new system
(not cmos !) time indication. The results will be scary. We have already
discussed in another thread that 1sec/day requires 5 ppm, 20 times better
than a standard untrimmed crystal, so the machine will lose or gain about
10 to 20 seconds per day ... at least ! Linux and other Unices know about
this and resync the clock (and calculate the deviation by themselves for
smooth correction).

Sure 8O1! Why not? I've used this several times. Once, however I got badly
hosed by it (yes, another story :-) ):

We had a system in which we had to transmit 8O1 data over an early
(Hayes?/Motorola?) AT modem. I forget the bit rate and modulation scheme,
but this was one of those modems (like nearly all modern modems, btw) that
convert the data stream to sync between the modems.

Unfortunately, whoever designed this modem decided that 10 bits was the
longest async word that it would have to deal with.

It took us a _very_ long time to figure out what was going on when we got
_many_ parity errors on the receiving end of the link.