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.
Eric