Searching \ for '[EE]: RS232 error. Erroneous asumptions.' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'RS232 error. Erroneous asumptions.'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: RS232 error. Erroneous asumptions.'
2000\07\14@142053 by Robert Rolf

picon face
"Peter L. Peres" wrote:
> Dan Michaels wrote:
> >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???].
> Your chances are about zero.

But Ammerman says that he has it working so you are obviously in
error. You'll see why later in this note.

> First, the crystal used is 18.432 if at all.

I must beg to differ. I have used at least two dozen different
serial port cards over the lifetime of the machines in my care.
The VAST majority of those with separate UART chips (8250, 16550)
use 1.8432Mhz xtals since they use the UART oscillator circuit.
Would you like me to send you a scanned image of one so that you
can read the crystal markings? If at all?

A few have used the cheaper 18.432Mhz you mention, with a 7490
divider before the UARTS to get a base of 1.8432MHz. They HAVE
to use the correct base rate or the comms software will break.
Others use 24Mhz so that the FDC has an appropriate clock,
and then they divide by 13 to get 1.846153Mhz which is .16% high over
1.8432Mhz. As another poster said 'something close enough' for
normal serial work.

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

No, it is  .01%, an order of magnitude difference.

> Few people know that the Windows OS runs the system clock from the
> crystal, not from the CMOS clock. Anyone having systems on for a longer

Technically it runs the system clock from the TOD timer tic
Heavy system loading can cause that interrupt to be missed, and time
lost. The CMOS clock, OTOH, free runs and is unaffected by system
loads. If you can trim it, it is the better choice for obtaining TOD.

> 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

Sorry. Pure Bull.

> 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

The results are scary because the system CMOS time is usually MUCH
WORSE than the system crystal. The CMOS clock is usually not trimmed
(the early machines sometimes had a trim cap but it was rarely set in
production). As I noted before, whatever crystal was cheapest was
usually installed, without regard to it's loading requirements.
This leads to very bad timing.

Having to support 64 odd machines one quickly finds out just how bad
CMOS clocks are. Thank ?? for NTP.

> discussed in another thread that 1sec/day requires 5 ppm, 20 times

See a very old post of mine that points at Dallas Semi's app note
about the importance of correct crystal loading to get good (accurate)

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

And there are a number of software shims that you can get for Wintel
machines that will do the same. Just look for 'accurate PC time'
or the like. They will learn the error in your system clock and
inject corrections as needed.

Accurate time nut.

-- hint: The list server can filter out subtopics
(like ads or off topics) for you. See

2000\07\16@135147 by Peter L. Peres

picon face
Robert, you are right, 100ppm is 0.01%, serial cards do need 1.8432 MHz
for base clock or they break the standard divider ratios, but they use 24
or 18.432 MHz crystals and divide whenever possible, instead of 1.8432,
the CMOS clocks are not that bad however, unless your motherboards are
really really odd cheap clones. I am not an accurate time nut but I DID
bother to replace the original loading cap with a 3-12pF trimmer at least
twice where it mattered. The method I stated to determine the accuracy of
the system clock (with an idle system - so no interrupts are missed)
stands valid.  Assuming no shims, and a well checked writstwatch (quartz)
you can determine the deviation to at least 10 ppm without too much fuss,
in 3 days or so.  This is the deviation of the master system clock, not
the CMOS ! Then, you can try and replace the canned oscillator for another
one and hope for better results (or spend ~$80 for a TCXO and be sure of
results). You can't always use a software shim. Too many shims on the same
systems make it shimmy, so the first shim (the so-called os) is bad enough
imho ;-)


-- hint: To leave the PICList>

2000\07\16@205600 by Dan Michaels

Peter Peres wrote:
>stands valid.  Assuming no shims, and a well checked writstwatch (quartz)
>you can determine the deviation to at least 10 ppm without too much fuss,
>in 3 days or so.  This is the deviation of the master system clock, not

BTW, anyone wanting to calibrate their RTCs or just set their
watch can checkout:

-- hint: To leave the PICList>

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