13 Jun
2010
13 Jun
'10
2:03 a.m.
On 13/06/10 02:21, Keith wrote:
OK, same as my "proof of concept" analyser then.
What I'm doing is a histogram analysis, followed by a peak-detect, and
then picking the centre points between the peaks as the thresholds.
Problem is, this only corrects for MSV. On a disc which has been written
with pre-compensation, this is (usually) fine. Without precomp, or on an
old disc which is suffering from bit-shift, it's a whole different ball
game.
You're
using fixed-position analysis? That is, "if the pulse was
between X and Y us after the last pulse, it was a 01" and so on?
I don't know what's it's technically called, but yes. I've read about these before. When you say the
drive motor doesn't
rotate at a constant speed, you mean that despite it having an average
of 300 rpm, that there is some speed up and slow down throughout a
single revolution?
That's ISV (Instantaneous Speed Variation). MSV and ISV are two
different things. ISV is usually caused by variations in friction in the
disc mechanism. MSV is a bit different -- that's a difference in the
average speed and varies on a per-drive basis.
A lot of older drives (Amstrad 3" drives in particular) used motors
which had a small speed-adjust screw. A single drive could be adjusted
by a few percent relative to another. On modern drives, the speed is
locked against a quartz crystal or a ceramic resonator, and is typically
much more accurate. There's still a several-digit-PPM variation between
drives though.
I've measured time between index pulses, and so
far
they appear to be 200.x ms.
200.0 is your target but some variation is normal. Hook up a frequency
counter with a serial or HPIB output and plot the time for each rotation
on a graph. It won't be a straight line...
Do you have your code up someplace? Verilog or VHDL?
I can't release the software source as yet, because it's part of my
final-year university project. The Verilog code is open, though, but I
haven't set the version control repository as public yet.
Thanks for all the links, they should be valuable.
I'm still working on
the basic concepts of a PLL. Once I get a better handle, I think writing
the code for a basic one should be within my reach.
Also look up Roman Black's Bresenham Timer algorithm --
http://romanblack.com/one_sec.htm
I've been thinking about how this looks like it could be used as a PLL
(you'd probably need two phase-accumulators, one driven by the incoming
data), but haven't really spent much time on implementation...
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/