Hi

It's most commonly done with things like a Soekris 45xx series board. You don't need anything very exotic for the frequency conversion. The jitter in the PC is way worse than what the external chips will be creating.

The real question is - what is the "magic frequency" on the particular mother board you are going to modify? Once upon a time they all were a pretty predictable 14.xxx MHz. These days, who knows what's going in where…

Bob

On Nov 30, 2012, at 4:55 PM, Sarah White kuzetsa@gmail.com wrote:

It all depends on what clock your talking about. Any given PC probably has more than one oscillator onboard.
Generally there will be one for the CPU, one for the display circuitry, and probably one for the real time clock.

Presuming you are talking about the CPU clock, it should be fairly straightforward to find the oscillator package on the motherboard find the pin with clock output and feed your clock input there.

On Nov 30, 2012, at 16:59, Bob Camp lists@rtty.us wrote:

the actual RTC on modern (Intel based) PC's is driven from a standard
32,768 Hz crystal attached to the PCH. some of them are in incredibly small
packages now instead of the old tuning fork-in-a-can ones. peeling off the
load caps and crystal from the board would allow you plenty of spaces to
tack down a lead from an external synthesizer.

-Eric

On Fri, Nov 30, 2012 at 3:04 PM, bownes bownes@gmail.com wrote:

--
--Eric

Eric Garner

On 11/30/2012 6:30 PM, Eric Garner wrote:

Yeah, the one on the (Soekis) example was pretty small. So far none of
of the replies have indicated that anyone on here has experience beyond
an embedded system.

Mostly I started this thread because there have been a few with people
discussing implementing NTP on embedded microcontrollers, arduino, etc.
and I was thinking of doing it from the other side (turning a nice-ish
server into a rock-solid timekeeper)

Thanks so far everyone. Really impressed that I already managed to get
4x replies so quickly :)

I've never done it using to the RTC crystal, but I  do it quite frequently
in my Day Job to Ethernet controllers on those same pc mother boards.

-Eric

On Fri, Nov 30, 2012 at 4:10 PM, Sarah White kuzetsa@gmail.com wrote:

--
--Eric

Eric Garner

Hi

In the case of the Soekris, it was not the real time clock that we all played with. THe clock you fiddle is the CPU clock. The system is running FreeBSD or Lunix, so it's a cut above a typical embedded system. A RTOS (like Windows CE) will indeed do a bit better with a good CPU clock. Anything like conventional Windows will still have issues, even with a good clock.

Bob

On Nov 30, 2012, at 7:10 PM, Sarah White kuzetsa@gmail.com wrote:

In this case, you're not looking for the RTC but rather the clock that drives the COU, which is what drives the system clock.  On most systems, the RTC is read only at startup and is not used once the system is running.

John

On Nov 30, 2012, at 6:30 PM, Eric Garner garnere@gmail.com wrote:

On Nov 30, 2012, at 7:10 PM, Sarah White kuzetsa@gmail.com wrote:

Sarah, when I was designing and protoyping the ClockBlock, I did interface it with a standard mobo (don't recall the specifics).  As someone else pointed out, the process is basically:

1. Find and remove the oscillator that drives the CPU, likely something between 33 and 100 Mhz in modern systems.  It's not the 32.768 kHz crystal (if there still is one; I think it's actually built into thr RTC chip these days).

2. Figure out which pin is the output of the oscillator module.

3. Figure out the proper drive voltage (most easily based on the supply voltage of the oscillator).

4. Hook the ClockBlock output to the signal pad where the oscillator used to be via small-diameter coax cable such as RG-174, connecting the coax shield to ground on the board and using a series resistor if you need to drop the signal voltage below the 3.3V minimum that the ClockBlock can provide via its voltage-select jumper.  Some math and/or experimentation may be involved; the goal is to get enough signal to drive the board, without exceeding the safe Vin rsting of whatever devices the clock is driving.

5. Set the ClockBlock jumpers for the proper clock frequency.

Have fun!

John

On Nov 30, 2012, at 7:42 PM, John Ackermann  N8UR jra@febo.com wrote:

Read "CPU".  Stupid iPad keyboard.

OK, I'll bite.  Why?

Jim

frequently in my Day Job to >>>Ethernet controllers on those same pc mother
boards.

On Fri, Nov 30, 2012 at 4:10 PM, Sarah White kuzetsa@gmail.com wrote:

--
--Eric

Eric Garner

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

On 11/30/12 4:58 PM, John Ackermann N8UR wrote:

I was wondering.. Clock Oscillator Unit? Cryptic Obfuscated Unknown?

On 11/30/2012 7:54 PM, John Ackermann N8UR wrote:

John :)

Ok, wow, thanks!

I couldn't have asked for a better answer to my specific question than
one from the designer of the module itself (and more or less saying, and
confirming "yes, I've done this in testing")

Slightly unrelated but...

Any chance you could recommend a minimalist set of tools that would be
helpful for poking around so I could make sure things are wired up right
/ signaling as desired, etc?

Please don't say "logic analyzer" or "oscilloscope" because if that sort
of thing is mandatory, I'll just give up now.

I took a basic electrical engineering course nearly 20 years ago, and
have worked on a few simple controllers and even modified a computer
motherboard or two, so this won't be my first venture into such things.

... I'm just currently without ANY tools. (Not counting the dremmel
rotory tool for doing acrylic fingernails, and/or various repair &
tooling, cutting, and sanding of things that would take too long by hand)

... Well mostly none. The only decent tool I have on hand is a soldering
iron with a variable control / stand to adjust power and to have
somewhere to sit it while it warms up (also, there's a position on the
stand which is handy for holding the iron stationary so I can tin wires)

Guess that's all for now. Thanks everyone :)

P.S. Probably not doing anything like this for at least a month anyway.
Still need to sock away enough budget for "cheap computer to modify" and
the clock block itself (or some other appropriate frequency synthesizer)

P.P.S This might be my last post of the night. Friend's birthday is
today / have a party to finish getting things ready for.

On 11/30/2012 7:58 PM, John Ackermann N8UR wrote:

I use MessageEase on my android smartphone. The standard keyboard, the
errors I frequently got, and some of the REALLY BAD / embarrasing
auto-correct problems that resulted were causing me much grief.

Works on: Android / iPhone / Windows / Pocket PC / Palm OS

They even tested it with "project glass" typing in mid-air too.
(google's wearable, headmounted mobile computer platform)

Explanation video...  http://youtu.be/26ayS-Ita6g

Free (for android at least) and it supports multiple languages. I've
only been using it for a few months (and I rarely text and almost never
email from my phone) and I'm currently up to 30 words per minutes last I
checked.

On Fri, Nov 30, 2012 at 04:24:38PM -0600, shalimr9@gmail.com wrote:

For what it is worth, for many generations now all major CPUs

have had kernel software readable nanosecond level time of day time
stamping counters that are clocked from the incoming clock to the CPU
chip and run continuously and steadily without skipped or added ticks
whatever the CPU is doing.  And in addition to these time stamping
counters, most all CPU chip sets also include "real time clock"
interrupts which again are  driven off of continuously counting counters
referenced to the clock input to the CPU and can be programmed to
interrupt ever n ticks of the master clock - regardless of CPU activity.

Obviously while servicing the real time clock interrupts is

usually a very high priority, depending on how the OS works and what
privileges real time priority apps have occasionally a real time
interrupt can be serviced so slowly that another one happens before it
is cleared.  Some OS real time clock handlers attempt to spot these
cases and adjust their idea of time to compensate.

Any OS based PLL driven by time stamping 1 PPS timing interrupts

WILL see some jitter in its time stamps due to bus and internal CPU
latencies and use of interrupt off intervals to protect against race
conditions. This noise is unavoidable and does depend on CPU load and
even  how fast the CPU clocks are set to run at any instant (modern CPUS
dynamically adjust clock rate in various areas of their logic to
conserve power and reduce heat).

So for a very fine control a hardware based 1PPS event time

stamper will provide greater accuracy and less jitter, especially if it
is driven by a high accuracy external clock source locked to some time
reference.

But of course it IS  useful to clock the CPU with an accurate

clock as that then means the internal CPU time stamp counter and real
time tick interrupt is ticking at a known rate - starting from some
epoch that can be eventually calibrated over time - and multiple 1 PPS
ticks - within a few ns or so of 1 PPS GPS or other similar time.

If the CPU clock is unstable and wanders around with time,

temperature, power and fan activity it then becomes necessary - as the
timing 1PPS PLLs built into many modern kernels do - to try to measure
its frequency error and drift and estimate the error phase between it
and true time. If the CPU clock  is locked to a reference, this is not
as hard a thing to do as the only relative unknown is when exactly the
zero epoch on the counter occurred.

--
Dave Emery N1PRE/AE, die@dieconsulting.com  DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
celebration of what could have been, but wasn't and is not to be now either."

Hi

The problem just the clock it's also the operating system. If it's not designed with timing in mind (= it's an RTOS at some level) then you will have sloppy timing. Counters can help, but they are not the entire solution. If your email (or anti-virus or ...) program can pop up and monopolize the cpu for a chunk of a second (as in 10's or 100's of ms),  precision timing isn't going to work very well. There's only so much you can do after the fact. If the pps edge was supposed to go out 27 ms ago, and you only got control back now, you are out of luck.

Bob

On Nov 30, 2012, at 9:19 PM, David I. Emery die@dieconsulting.com wrote:

On Fri, Nov 30, 2012 at 09:58:29PM -0500, Bob Camp wrote:

No doubt that you get into a sort of philosophic meaning of 

what-really-is-now relativity here... if parts of the kernel know what
time it is quite precisely but other parts and most user programs are
only loosely aware of and only able to react to it post facto by large
and jittery intervals, what is the meaning of microsecond or even ns
level OS time sync ?

Most modern kernels *internally* have at least some degree of

fairly serious real time high priority tight deadline stuff going on -
and API hooks for accessing it available - the degree to which this is
exposed and visible to or usable by user space threads varies a lot, and
correctly using this stuff always requires pretty deep skill and
thought.  Not for the faint of heart or inexperienced.  Very easy to
make subtle errors that cause bugs that happen only once every few
hundred or even many thousands of hours.

And pretty obviously the more control and access the user (eg

applications programmers) get and use the less likely it is that some
combination of separately developed and architected applications and a
particular kernel running on particular hardware will handle all of this
right ALL the time.  Emphasis here on ALL, it usually works most of the
time but making it essentially never fail is really really hard.  And
many of those failures result in things like deadly embrace lockups
which can cause everything to stop or rare conditions in which apparent
causality and temporal coherence completely inverts and things which
"cannot happen" happen exposing all kinds of reasonable but not
quite bulletproof assumptions.

--
Dave Emery N1PRE/AE, die@dieconsulting.com  DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
celebration of what could have been, but wasn't and is not to be now either."

On Fri, Nov 30, 2012 at 8:39 PM, David I. Emery die@dieconsulting.comwrote:

What is "sloppy timing"?  If about 10 microseconds of error is "sloppy"
then you are right.

None of the effects you describe need to cause a problem.  Even on a
non-RTOS the limiting factor is the uncertainty in the interrupt latency.
The way it works is that the PPS interrupts the CPU and then inside the
handler a hardware counter is sampled and stored and that is it.  Nothing
else needs to occur in real time.

Quite a few people are able to run NTP serversand keep there system clocks
for small (uSecs) error from UTC.    But now the question is if an
application program can us the clock .without some error  I think it can.
A simple example is a program that time stamps data.  It waits for data
then when it comes in reads the system clock then tags the data with the
sampled clock.  The problem is if the CPU is taken away.  One way to
detect a problem is to read the clock twice and check for a deta time of
more than a few nanoseconds.  Then if you read the data between those to
clock samples you will know the clock was acuratly sampled.

Chris Albertson
Redondo Beach, California