[time-nuts] lunatic fringe time standards

Didier Juges didier at cox.net
Fri Apr 16 17:37:48 UTC 2010

Hi Brooke,

The issue with a parallel bus is not quite the same because the bus has a clock signal to indicate when the data on the bus is supposed to be stable, eliminating the uncertainty around the time that the data changes, where the position encoders do not have such clock. But I understand your point.


------------------------ Sent from my BlackBerry Wireless thingy while I do other things... 

-----Original Message-----
From: Brooke Clarke <brooke at pacific.net>
Date: Thu, 15 Apr 2010 08:24:37 
To: Discussion of precise time and frequency measurement<time-nuts at febo.com>
Subject: Re: [time-nuts] lunatic fringe time standards

Hi Didier:

When working with high speed data, for example an IDE hard drive, where 
there are parallel data lines you get into the same problem as you have 
with a shaft encoder where there are parallel binary data lines.  In the 
case of the shaft encoder mechanical misalignment can cause huge errors 
at the transitions and in the hard drive jitter and time delays can 
cause similar problems.  I think that was one of the main motivations to 
go to a serial hard drive interface (SATA).

When in college I used a Johnson counter made from the first ICs from 
Fairchild, i.e. the 723 flip-flop and the 714 two input gate.  The 
beauty of the Johnson counter is that you can decode it's state with ten 
each two input gates.

Have Fun,

Brooke Clarke

Didier Juges wrote:
> I believe Gray code was invented to support absolute mechanical position encoders, where the speed of the electronics is high compared to the speed of the hardware being monitored. It eliminates the potentially large error between two positions since only one bit changes at a time. This is done at the expense of complicated logic, which goes against speed.
> I don't think Gray code has ever been used to implement fast electronic counters. That's what synchronous counters are for, and when synchronous counters are not fast enough, use a prescaler. It will just take more time to get the precision you need.
> Unless you need fractional Hz resolution at THz speed, a prescaler is the way to go.
> Didier
> ------------------------ Sent from my BlackBerry Wireless thingy while I do other things...
> -----Original Message-----
> From: Eugen Leitl<eugen at leitl.org>
> Date: Thu, 15 Apr 2010 13:42:00
> To:<time-nuts at febo.com>
> Subject: Re: [time-nuts] lunatic fringe time standards
> On Thu, Apr 15, 2010 at 07:30:27AM -0400, Bob Camp wrote:
>> Hi
>> I'm not 100% sure I understand exactly what you are thinking about setting up.
> This is completely theoretical at this point. Just the required geometry
> size would be prohibitive.
>> My guess is that the counter needs to run at the same THz speed as
>> the oscillator. That's pretty fast. I suspect that what ever you use,
>> speed / propagation delay in the counter it's self will be an issue.
>> That will get you back to either a ripple counter or a Johnson counter.
> Wouldn't you get large errors when you caught a ripple
> during readout? That wouldn't be a problem with a Gray code.

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

More information about the time-nuts mailing list