Read error correction in software

[Allison]

>
>Subject: RE: Read error correction in software
>   From: "Chuck Guzis" <cclist at sydex.com>
>   Date: Thu, 26 Jul 2007 12:50:27 -0700
>     To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 26 Jul 2007 at 6:40, dwight elvey wrote:
>
>> Your right, not too good on multiple errors.
>
>Actually, on MFM, not even that good for single errors.  Recall that 
>the CRC on a 256-byte sector is the 257th and 258th byte of the 
>sector.  So, if an MFM error throws the data stream off, you don't 
>even get a valid CRC to work with.  And MFM data errors can result in 
>data shifting and clock data "swapping".  It might have been a whole 
>'nother story had the convention been that the CRC precedes the data.
>
>I've got some ideas about simulating a PLL-type clock in my routines 
>developing bit cell "windows" instead of relying on the pulse-to-
>pulse spacing.  The latter, while being very adaptable to ISV-type 
>errors, is lousy for recovery of regular data errors.

If you implement a software PLL the key function is in the face of a 
missing pulse you keep the current clock rate and clock in a zero or 
or one as needed to fill the stream.  The usual analog PLL tend to have
an idle rate and lacking a error signal it will either retain the current
rate or hunt back to the center rate.  Since in a corrstly set PLL
the error rate and the centered rate are not widely seperated
drift is rarely a factor short term.


Allison