Serial IC

[using PIC internal osc for RS232]

IIRC you are quoting 'typical' data now, not worst case. Good enough
for a hobby project, and for a 1M+ units project that can afford
extensive testing, but not good for your night's rest when you have a
10k units project.
So how good a clock do I need to generate (or receive)
an RS-232 signal?

The specs say 1% for initial calibration (at 25C and 3.5V and
2% over 2.5V to 5.5V and 0C to 85C.

Is 2% good enough? That's 20% of a bit time if you have 10 bits
(10 is 8 rounded up to make handwaving like this simpler) with
no transitions to resync on. Double that if the other end is
off as far in the other direction and we are getting to an
"interesting" value.


The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
 
The specs say 1% for initial calibration (at 25C and 3.5V and
2% over 2.5V to 5.5V and 0C to 85C.

Is 2% good enough? That's 20% of a bit time if you have 10 bits
(10 is 8 rounded up to make handwaving like this simpler) with
no transitions to resync on. Double that if the other end is
off as far in the other direction and we are getting to an
"interesting" value.
There is some ~ 3% margin. But there are a lot of factors that 'eat'
from this margin:
- clock accuracy (on both sides!!!)
- a receiving UART samples at discrete moments only
- a receiving UART samples a fixed number of times in each bit cell
(often 3 or 5 times)
- drivers can have different H-t-L and L-t-H delays
- the cable will add some interesting (waveform-dependent) distortions

For myself I would not trust asynch communication with less than 1%
accuracy, unless I know the other side is accurate (crystal), the T
and Vcc are stable, and the user does not have my phone number.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
PICmicro chips, programmers, consulting
 
The specs for RS232, allow for up to 4% drift at both ends.
That would surprise me, with 8% clock difference the last bit cell can
be shifted almost one cell.

Exactly which spec are you referring to? The RS-232 specs I know do
not even hint at the format of the tranferred data.

Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
PICmicro chips, programmers, consulting
 
"Wouter van Ooijen (www.voti.nl)" <wouter@voti.nl> wrote in message
news:3f268ec7.351226216@news.xs4all.nl...
The specs for RS232, allow for up to 4% drift at both ends.

That would surprise me, with 8% clock difference the last bit cell can
be shifted almost one cell.

Exactly which spec are you referring to? The RS-232 specs I know do
not even hint at the format of the tranferred data.

Wouter van Ooijen
CCITT V5. This is based on the older RS232D specs, and gives timing
recommendations (as opposed to the signalling specs). Though the basic RS232
paperwork, only covers the signalling standards, they do give
recommendations for clock drift, and for 10bit data say this should be
better than 4%.
This is the whole 'point', that the worst case drift should not take the
sampling point outside the cell, allowing for the switching time (which is
also defined).

Best Wishes
 
Exactly which spec are you referring to? The RS-232 specs I know do
not even hint at the format of the tranferred data.

CCITT V5.
Can you check that again? I have a recent ITU-T/CCITT CDROM and V5
isn't even mentioned as an obsolete standard.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
PICmicro chips, programmers, consulting
 

Welcome to EDABoard.com

Sponsor

Back
Top