Disc reader project -- quick status update

Eric Smith eric at brouhaha.com
Wed Dec 9 15:41:22 CST 2009

Al Kossow wrote:
> There is no need to record every value if it is only a binary signal, you
> can store the delta time to the next transition. This is the 
> difference on
> a logic analyzer between 'state' and 'timing' modes. In 'state' mode, you
> sample and save every signal at each event. In 'timing' mode, a high 
> resolution
> clock is used to measure the durations of each signal.
Not all logic analyzers store delta times when operated in "timing 
mode".  That's an optimization that seems very worthwhile, but if you 
look at actual logic analyzer specs, many of them even in timing mode 
will only record for a fixed number of sampled determined by the depth 
of their buffer.  :-(

In principle, storing timing deltas rather than full samples could be 
useful in state mode also, but I don't think I've ever seen an analyzer 
that does that.

The only consistent interpretation of "state mode" vs. "timing mode" is 
that state mode samples on a clock signal provided by the target 
hardware, while "timing mode" samples on a clock internally generated in 
the logic analyzer.
> Another problem is even though it is using saturation recording, the 
> media may have
> flaws, or the head may clog due to shed, causing pulses to drop out. 
> Data recovery
> has to cope with the fact there may be pulse dropouts, sometimes 
> requiring the
> recovery program to 'wiggle' the head across tracks to try to rub the 
> clog off of
> the heads.
Interesting.  That's another argument for controlling the stepper motor 
directly, and using microstepping.  I had considered that as a way to 
read disks with non-standard TPI.  You still have to have a narrow 
enough head to accomodate the track width, but it should work to let you 
read 100TPI disks in a 96TPI drive, or vice versa.


More information about the cctech mailing list