Disc reader project -- quick status update
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
> 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