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.
Didier ------------------------ Sent from my BlackBerry Wireless thingy while I do other things... -----Original Message----- From: Brooke Clarke <[email protected]> Date: Thu, 15 Apr 2010 08:24:37 To: Discussion of precise time and frequency measurement<[email protected]> 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. http://www.prc68.com/I/comp.shtml#Nixie Have Fun, Brooke Clarke http://www.PRC68.com 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<[email protected]> > Date: Thu, 15 Apr 2010 13:42:00 > To:<[email protected]> > 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 -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
