Searching \ for '[EE]: RS232 error. By design.' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=rs232
Search entire site for: 'RS232 error. By design.'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: RS232 error. By design.'
2000\07\13@120034 by Robert Rolf

picon face
Please don't take this as a criticism. It's simply meant to point out
what happens when one tries to take a square peg and make it fit a
round hole. One has to look at the whole -system- in order to ensure
a successful design. Assume NOTHING!

Bob Ammerman wrote:
>
> Here is a real-life story about how PC serial port baud rates are _not_
> exact!

Of course they're not, especially when computed from 'common' crystal
rates like 2,4,8,10 Mhz. 9600bx16x13 =1.996800Mhz, a .16% error.
(Now you know why many uC's have a /13 choice for baud rate divisor).

> 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,

Actually it COULD if the clock were derived from an edge based
DPLL. Floppy disk controllers commonly extract 10 times that many
bits from an incredibly sloppy data stream. The key is that the
system be DESIGNED to recover that kind of a bit stream.
(E.G. Send 250 bits and use the first 10 to get PLL sync'd, or use
the frame time to compute a 'matched' bit rate clock (as you
ultimately did).

A typical UART is designed to resynchronize itself -every- character
(start bit). That's why it's called universal -asynchronous- receiver
transmitter.
You will note that the 'synchronous' implementations (USARTS) use a PLL
clock to ensure bit rate tracking, and a coding scheme that supports
it (no really long strings of one bit level allowed).

this
> will be about 30 times as sensitive to timing error as 8N1 communications.

Of course. Square peg, round hole. A UART wasn't designed to
handle really long bit stream streams that don't provide for
synchronization, software based or not.

{Quote hidden}

So you basically undersampled your data stream by ignoring Shannon's
criteria. You sampled your 'information' at the same rate it was
supplied, and not twice the rate as required by his law. That's one
reason why UARTS commonly use 16X sampling.

What I don't understand, is if you used an external 'high accuracy
clock', why you would have a problem with differing clock rates.

'Accuracy' and 'precision' are two different measurements. One
can have a highly precise WRONG clock rate or one can have a
'accurate' rate, which rate is known to some definable error bound
traceable to a standard. Engineers often use the terms interchangeably,
but they are NOT the same where metrology is concerned.
Basically, you may have a 'precision' of 1 part in 4096 (12 bit A/D)
but have an 'accuracy' of only 1 part in 256 (if you have a sloppy
reference voltage).

{Quote hidden}

Of course, since you didn't resynchronize your communications with any
bit
transitions that you found. Nor did you send a 'synch' stream to
allow a PLL clock to lockup to match the incoming bit rate (i.e.
-design-
for inaccurate clocking).

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

The system timer is NO better a clock than the one the UARTS use.
Your scheme worked because it presumably gave you a much finer clock
granularity. OR you were starting with matched clock rates so the
difference in bit rate was not a problem over the frame time.


> Bob Ammerman
> RAm Systems
> (contract developer of high performance, high function, low-level software)

Thank you for sharing your experience with us.

Robert

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\07\13@123234 by Dan Michaels

flavicon
face
Robert Rolf wrote:
>Please don't take this as a criticism. It's simply meant to point out
>what happens when one tries to take a square peg and make it fit a
>round hole. One has to look at the whole -system- in order to ensure
>a successful design. Assume NOTHING!
>
>Bob Ammerman wrote:
>>
>> Here is a real-life story about how PC serial port baud rates are _not_
>> exact!
>
>Of course they're not, especially when computed from 'common' crystal
>rates like 2,4,8,10 Mhz. 9600bx16x13 =1.996800Mhz, a .16% error.
>(Now you know why many uC's have a /13 choice for baud rate divisor).
>

Actually, Bob was talking about "PC's", not uC's. As I pointed
out yesterday, originally PC's used a 1.8432 Mhz xtal on the
serial cards, which when /(n*16) gave a *perfect* clock for std
baudrates. But Bob pointed out that he has found that not all
"PC's" necessarily use this xtal anymore, but derive the UART
clock off their *much faster* clocks - more like 133, or 200,
or 233, or 450 Mhz - which may not scale exactly.

- DanM
======

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\07\13@134854 by Bob Ammerman

picon face
See my comments marked **** below

Bob Ammerman

----- Original Message -----
From: Robert Rolf <spam_OUTRobert.RolfTakeThisOuTspamUALBERTA.CA>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Thursday, July 13, 2000 11:59 AM
Subject: Re: [EE]: RS232 error. By design.


> Please don't take this as a criticism. It's simply meant to point out
> what happens when one tries to take a square peg and make it fit a
> round hole. One has to look at the whole -system- in order to ensure
> a successful design. Assume NOTHING!

**** Don't you know it!

>
> Bob Ammerman wrote:
> >
> > Here is a real-life story about how PC serial port baud rates are _not_
> > exact!
>
> Of course they're not, especially when computed from 'common' crystal
> rates like 2,4,8,10 Mhz. 9600bx16x13 =1.996800Mhz, a .16% error.
> (Now you know why many uC's have a /13 choice for baud rate divisor).

**** Note: This is a PC, not a uC! The original PC serial card had a
'proper' crystal for baud rate gen. Current PC's often use whatever handy
frequency they have around.

> > 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,
>
> Actually it COULD if the clock were derived from an edge based
> DPLL. Floppy disk controllers commonly extract 10 times that many
> bits from an incredibly sloppy data stream. The key is that the
> system be DESIGNED to recover that kind of a bit stream.
> (E.G. Send 250 bits and use the first 10 to get PLL sync'd, or use
> the frame time to compute a 'matched' bit rate clock (as you
> ultimately did).

**** Can't do it: No guaranteed edges. The data could be all zeros or all
ones in this application.

> A typical UART is designed to resynchronize itself -every- character
> (start bit). That's why it's called universal -asynchronous- receiver
> transmitter.
> You will note that the 'synchronous' implementations (USARTS) use a PLL
> clock to ensure bit rate tracking, and a coding scheme that supports
> it (no really long strings of one bit level allowed).

**** Absolutely true.

> this
> > will be about 30 times as sensitive to timing error as 8N1
communications.
>
> Of course. Square peg, round hole. A UART wasn't designed to
> handle really long bit stream streams that don't provide for
> synchronization, software based or not.

**** Right. Unfortunately, I didn't design the system. I had to emulate a
piece of hardware (non-intelligent) built in the early 70's.

> >  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.
>
> So you basically undersampled your data stream by ignoring Shannon's
> criteria. You sampled your 'information' at the same rate it was
> supplied, and not twice the rate as required by his law. That's one
> reason why UARTS commonly use 16X sampling.

**** Actually I _was_ sampling at 2X. The highest possible frequency on an N
bit-per-second link is N/2 (ie: alternating 1's and 0's.

> 'Accuracy' and 'precision' are two different measurements. One
> can have a highly precise WRONG clock rate or one can have a
> 'accurate' rate, which rate is known to some definable error bound
> traceable to a standard. Engineers often use the terms interchangeably,
> but they are NOT the same where metrology is concerned.
> Basically, you may have a 'precision' of 1 part in 4096 (12 bit A/D)
> but have an 'accuracy' of only 1 part in 256 (if you have a sloppy
> reference voltage).

**** I stand corrected on this. You are precisely (or is that accurately)
right. :-)

> > 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.
>

> Of course, since you didn't resynchronize your communications with any
> bit
> transitions that you found. Nor did you send a 'synch' stream to
> allow a PLL clock to lockup to match the incoming bit rate (i.e.
> -design-
> for inaccurate clocking).

**** Again: not my choice - I had no control over the design.

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

> The system timer is NO better a clock than the one the UARTS use.
> Your scheme worked because it presumably gave you a much finer clock
> granularity. OR you were starting with matched clock rates so the
> difference in bit rate was not a problem over the frame time.

**** This is _not_ true. The system clock is defined to operate from a
specific clock rate crystal, and PC's tend to actually do that even today to
ensure that they maintain at least reasonably correct time-of-day.

>
> > Bob Ammerman
> > RAm Systems
> > (contract developer of high performance, high function, low-level softwa
re)
>
> Thank you for sharing your experience with us.
>
> Robert
>
> --
> http://www.piclist.com hint: PICList Posts must start with ONE topic:
> [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\07\13@142439 by Robert Rolf

picon face
Bob Ammerman wrote:

> **** Again: not my choice - I had no control over the design.

Those are always the hardest to design for.

{Quote hidden}

True enough, that once booted the PC timer does keep TOD advancing
correctly at 18.932? tics/second (what a -nice= number for a tic rate)
<G>. All because of the 14.31818Mhz 4x color burst crystal they start
with.

I don't suppose you remember DOS 6.22 and it's propensity to run
TOD clock -really- fast on some hardware (by more than a day and a half
per month). Fortunately one had to frequently reboot Winblows
so the TOD got reset from the CMOS clock. Maybe that's why Microsloth
recommends rebooting Winblows NT every 30 days (I KID YOU NOT! See
latest issue of Network computing for their review of Linux in the
Enterprise vs NT vs Novell. So much for 7x24x365).

And when was the last time you saw a CMOS clock that actually
ran at an 'accurate' rate? Some designer don't seem to understand
the significance of a 12pF load vs 6pF for the 32768Khz xtal. This
oversight will affect you if you try to use PIC Timer1 for a TOD clock.

My point remains, the system timer is NO BETTER A CLOCK THAN THE ONE
THE UARTS USE. They are BOTH crystal clocks, after all. The difference
is that the former allowed you to select a divider rate that gave you
a nearly -exact- match to your project's bit rate, while the latter uses
whatever clock rate is 'good enough' for the task at hand (async with
resyncing on every stop bit) and did -not- give you the -required-
degree of rate match. This system could (and obviously does) work
with mismatched bit rates (since it is highly unlikely that
your two crystals are perfectly matched), but the error has to be less
than one bit time over 240. As always, its about error budgets and
staying well within them.

Thanks for the enlightening dialog.

Robert

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\07\13@170049 by Bob Ammerman

picon face
Exactly. Luckily the designer of the other end of the link was aware of the
stringent timing and used a decent XTAL OSC that has hardly aged a day in
almost 30 years :-)

The 30-50ppm error I can hope for from a crystal works out fine (somewhere
about .01 bit time over the 240 bits (?)).

I'm not familiar with the DOS 6.22 fast-running-clock scenario. Any idea
what caused it?

The official (original PC) clock into the timer chip is:  1,193,181.6667 Hz
(from IBM docs believe it or not).

On division by 65536 we get :

PC tick rate is 18.206507... (more or less :-) )

Bob

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...