HDD PRML Read Channel Tuning

PRML (Partial Response Maximum Likelihood) is the signal processing pipeline a hard drive uses to turn the analog voltage coming off the read head into a bit stream. EPRML extends the partial-response target so the same detector survives higher areal density. Both sit on top of a digital FIR equalizer whose tap coefficients, along with channel gain and per-head microjog offsets, are calibrated against the heads the drive was built with. Install a donor head stack during hard drive data recovery and those stored values describe heads that are no longer in the drive. PC-3000 Portable III and PC-3000 Express reach the adaptive parameters through vendor-specific commands, so the channel can be pointed at the heads actually installed. What no tool does is reach inside the Viterbi detector and relax a decision threshold. There is no such threshold.

What does PRML do inside the read channel?

A modern hard drive does not look for individual peaks. The slider flies a few nanometers above the platter, and the tunneling magnetoresistive (TMR) read element produces a continuous voltage waveform whose features overlap, because adjacent bits are written close enough together that their flux fields blur into one another. That blurring is inter-symbol interference, and it is the reason PRML exists.

The read channel performs the following sequence on every track read:

1. The preamp on the head stack assembly amplifies the head voltage and drives it across the flex cable to the controller IC on the PCB.
2. A continuous-time analog filter shapes the waveform toward roughly the partial-response target and an analog-to-digital converter samples it at the channel rate.
3. A digital FIR (Finite Impulse Response) equalizer multiplies a sliding window of recent samples by a vector of tap coefficients, producing equalized samples that match a known partial-response target (PR4, EPR4, or EEPR4).
4. A Viterbi detector consumes the equalized samples and walks a trellis whose edges represent possible bit sequences. For each edge it computes the squared error between the actual equalized sample and the sample value the channel model predicts for that edge.
5. The detector keeps only the survivor path entering each state; after a fixed traceback depth it commits the bit on the lowest-error path. That bit stream is what the drive's error correction layer then validates.

Two of those blocks differ from drive to drive. The FIR tap coefficients and the channel gain are calibrated against the readback signal a specific drive's heads produce, because that signal depends on the head, the platter substrate, the fly height, and the preamp trim. The trellis is not calibrated. It is fixed logic in the read channel silicon, and it carries no accept/reject threshold that anyone can loosen. Every adjustment a recovery tool makes happens upstream of the detector, in the signal handed to it. Where the calibrated values live is a Service Area firmware question, and the answer is vendor-specific.

Where does a drive store its per-head calibration?

Every vendor arranges this differently, and the vocabulary does not carry across brands. On Western Digital ROYL drives, Module 47 holds the microjog and servo adaptives and Module 0A holds the active head map; both live in the PCB ROM with shadow copies written on the platters. Seagate F3 drives keep their firmware as System Files in the Service Area, with the bootstrap code and the baseline adaptive parameters in the PCB ROM. Using WD module numbers on a Seagate drive, or the reverse, is a platform error rather than a synonym.

What matters for recovery is narrower than a full module map. Adaptive data is drive-specific and head-specific, it does not travel with a same-model donor, and it is not reachable through the standard ATA command set. That is why a bare board swap fails on a modern drive: the original ROM has to move to the donor board before the drive will initialize with its own calibration.

When PC-3000 reads those structures it is issuing Vendor Specific Commands that the controller IC accepts only after the family-specific unlock sequence, which is why PC-3000 can access firmware that consumer software cannot.

What happens to the Viterbi detector when SNR collapses?

The Viterbi detector is a maximum-likelihood detector. Its branch metric is the squared error between the actual equalized sample and the sample the channel model predicts for that edge. With a healthy signal that error is small on the correct edge and large on the wrong ones, so the survivor path follows the true sequence almost every time. Head degradation attacks that margin from three directions at once.

Read signal amplitude drops first. The AGC loop compensates until the equalized samples lose resolution at the bottom of the dynamic range and quantization noise starts to matter. Timing recovery suffers next, because weaker transitions give the clock recovery loop less to lock onto and the sample clock jitters against the true bit boundaries. Third, the noise coming off the head rises relative to the signal, and it is correlated with what is written on the track rather than white, which is not what a plain partial-response model assumes.

The squared errors on correct and incorrect edges become comparable. A noise spike is then enough to send the survivor path down a wrong branch.

Retuning helps here, and it helps in one specific way. On supported families PC-3000 can adjust the read-channel adaptives ahead of the detector, the FIR tap coefficients, the gain, the target response, and the drive's retry and timeout behavior, so equalized samples land closer to the target the detector expects. The detector makes fewer wrong choices on the same analog signal. No bits are invented and no decision rule is loosened. The channel stops discarding data the head was already reading.

Which of the firmware-side parameters are actually exposed is read-channel-specific. Some are firmware-tunable and some are fixed in the silicon, and it varies by platform, controller generation, and PC-3000 version. In this lab the channel-side work runs alongside Data Extractor imaging, with the DeepSpar Disk Imager handling per-sector timeouts and head scheduling when the bus is also unstable.

What does NPML add to the Viterbi detector?

PRML originally targeted PR4, a short response with a small set of expected sample values. EPRML extends the target to EPR4 or EEPR4, longer responses that fit the magnetic recording channel better as bits are packed closer together. NPML goes after a different problem. Media noise is not white; it correlates with the data pattern written on the track, and a detector that treats it as white throws away information it could have used.

None of that changes the recovery procedure. Detection architecture varies by controller generation, and vendors do not publish which drive ships which detector, so pinning a named family to a named architecture is a guess. The work is the same in either case: get the samples reaching the detector as close to its expected target as the head can support, then image what comes back.

How is read-channel failure isolated from mechanical, firmware, and helium-loss failures?

Marginal SNR versus head-platter contact

A drive with a marginal signal still reads. It returns data slowly, fails on some sectors, and responds to changes in the channel adaptives. A drive that has lost servo lock never gets that far: the actuator sweeps into the crash stop and resets in a loop, which is the sound people describe as clicking. A drive that never reaches operating speed is a third case again, covered under hard drive not spinning, because no head produces read signal while the platters are still. Channel work does not begin until the drive holds servo lock.

Service Area firmware corruption masking as decode failure

Translator, G-List, and MCMT corruption inside the Service Area presents to the host the way a failing head does: the drive enumerates and then returns unrecoverable reads across wide LBA ranges, or it does not enumerate. On Seagate F3 drives the separation is made at the F3 terminal, which runs at 38400 baud and prints diagnostic codes on a firmware exception. Modern F3 families ship that terminal locked, and it stays silent until PC-3000 applies a volatile RAM-resident Tech Mode unlock patch that restores diagnostic access. If the terminal responds and the firmware structures come back with translator errors rather than read failures, the problem is firmware-side, and channel work accomplishes nothing until the Service Area is repaired. Other platforms expose their own diagnostic paths. The ordering is what carries across, and it lives in how hard drive firmware works.

Helium-loss aerodynamic fly-height shift

Sealed enterprise drives are filled with helium, which is roughly one-seventh the density of air, 0.1786 g/L against 1.225 g/L, and slider aerodynamics are designed around that. Baseline clearance on a modern drive is a few nanometers, and thermal fly-height control heats a resistive element in the slider to protrude the transducers to an active magnetic spacing of one to two nanometers during a read. Air leaking in through a failed seal raises the internal gas density, the slider flies outside the window its firmware adaptives were calculated for, and the increased magnetic spacing drops signal-to-noise ratio steeply at the preamplifier. We perform helium recovery in-house at the Austin lab, including mechanical work in the 0.02 micron ULPA-filtered clean bench, helium refill, and matched donor head stack transplants. A lab refill is temporary by nature, because the factory seal is laser-welded and cannot be recreated, so the drive is repressurized long enough to clone to a fresh target and is then retired. Helium head-swap pricing is the $3,000–$4,500 tier.

Why can't ddrescue or HDDSuperClone tune the read channel?

ddrescue and HDDSuperClone are good at what they do, which is scheduling reads and keeping an honest map of what came back. Neither is a firmware tool. A retry from either one arrives at the drive as another read command for the same LBA, and the drive answers it with whatever its current configuration produces. How often to ask, how long to wait, and in what order are real controls and they matter. They stop at the interface.

HDDSuperClone PRO improves on ddrescue at the bus layer, where SCSI passthrough and direct I/O get around operating-system timeout behavior, and hddsupertool can issue a small number of vendor-specific commands for well-documented firmware conditions. Those are bus-level and firmware-bug-level fixes, and they are worth having. Vendor Specific Commands as a class are undocumented opcodes recognized by a particular controller IC and gated behind family-specific unlock handshakes; PC-3000 ships the unlock library and the vendor command sets together, and consumer tools ship neither. The detailed comparison lives in HDDSuperClone versus ddrescue.

Why does hammering a failing drive with retries make it worse?

Short answer: the damage is physical, not mathematical. Every retry is another pass of a damaged head over a damaged surface, and a drive's internal error recovery can spend a long time on one sector before it reports failure. The head and the media degrade. The channel calibration does not.

The FIR equalizer is adaptive. It runs a least mean squares loop that trims tap weights against the partial-response target, which is what lets a drive ride out slow drift: thermal expansion, zone-to-zone changes in linear density, small fly-height variation as the slider crosses the disk. That adaptation does not accumulate across sectors. The channel re-acquires gain, timing, and equalization from the preamble and sync field at the start of every sector, so a retry that finds nothing but noise leaves no poisoned tap set behind for the next read.

Wear accumulates instead. When a sector fails, drive firmware enters an internal error-recovery procedure that keeps working that sector well past the point a host would have given up, and through all of it the heads stay loaded over a surface that already failed to read once. That is where a marginal drive turns into a dead one.

Imaging hardware exists to cut that short. The DeepSpar Disk Imager aborts a hung read in the millisecond range rather than letting internal error recovery run its full course, and the sector goes on a list to revisit later instead. A host can cap that recovery time with ATA SCT Error Recovery Control on drives that implement it. On drives that do not, consumer cloning software has no way to stop the drive from grinding on the sectors that are already killing it. That, and not a corrupted calibration, is what makes a drive worse the longer an unattended clone runs.

Why do detector errors arrive in bursts rather than as single flipped bits?

Short answer: a maximum-likelihood detector commits to a path, not to individual bits. When it takes the wrong branch, the decoded sequence stays wrong until the trellis remerges with the correct path, so the errors land contiguously inside one sector rather than scattered across it.

That matters because error correction on a drive is built around a finite correction budget per codeword. Short error events fit inside the budget and never reach the host. A long one does not: the decoder fails the correction and the drive returns an Unrecoverable Read Error, even though the head physically retrieved a usable analog signal.

Older drives used Reed-Solomon block codes for that layer. Current drives use iterative soft-decision decoding, where the detector passes reliability information about each bit forward instead of a hard yes or no and the decoder works the sector over several passes. The budget argument survives the change of code. What decides whether a sector comes back is how much of the codeword the detector got wrong, and that is set by the quality of the samples reaching it.

Retuning the adaptives ahead of the detector attacks that quantity directly. Better-conditioned samples produce shorter and rarer error events, and codewords that were failing correction come back inside the budget. Nothing is reconstructed and nothing is guessed. The channel stops throwing away bits the head was already reading.

How does the DeepSpar Disk Imager protect a failing head during imaging?

Short answer: it takes the schedule away from the drive. The imager runs its own controller on the SATA interface, aborts a hung read in milliseconds instead of waiting out the drive's internal error recovery, suppresses the housekeeping the drive would otherwise run during imaging, and revisits the sectors it skipped in later passes.

The DeepSpar Disk Imager is a dedicated controller that asserts low-level control over the SATA interface. When a read hangs, it issues a hardware reset or a power cycle on its own clock rather than waiting for a host operating system or BIOS to notice the bus is stuck. Its read timeouts are set at millisecond granularity, which is the right order of magnitude: one rotation at 7200 RPM takes about 8.33 ms, so a timeout has to be long enough for the sector to arrive under the head and short enough to abort before the drive settles into a long internal retry.

Before imaging starts, the imager uses ATA commands to suppress the drive's own housekeeping: the SMART subsystem, read look-ahead, and automatic bad-sector reallocation. A degraded head should not be spending its remaining reads on background work while the extraction is running.

From there the strategy is scheduling, and it is configured per case rather than fixed. The easy area is read first and banked. A read that times out is logged and skipped rather than dwelt on, and the skipped ranges are revisited in later passes from the opposite direction, with different block sizes and retry limits. Heads are scheduled individually so a weak head is not carrying work a healthy head can carry. Throughput is not the point. A failing head has a limited number of reads left in it, and the schedule decides what those reads buy.

PC-3000 and DeepSpar are separate planes and they stay separate. PC-3000 talks to the drive's firmware and its adaptives. DeepSpar commands the interface: timeouts, resets, power cycling, and head scheduling. Neither passes its commands through the other, and the imager does not retune a read channel.

When does signal-processing intervention stop working and a head swap become unavoidable?

Short answer: while a head still returns a signal that responds to channel adjustment, the case stays on the imaging side. Once a head returns nothing across the sectors mapped to it, the decision is mechanical: stop imaging, open the drive in a 0.02 micron ULPA-filtered clean bench, transplant a matched donor head stack, and resume from there.

Read channel work solves one class of problem, which is that the analog signal coming off the head is usable and the stock configuration is discarding it. FIR and target adjustments, retry and timeout control, and multi-pass imaging all live inside that class. None of them recover data from a track whose magnetic layer has been physically removed, and none of them substitute for a head that is not reading.

The boundary shows itself in behavior rather than in a number. A head that reads its firmware structures and returns user data, even slowly and with errors, is worth tuning and imaging. A head that returns nothing across every sector mapped to it, or that will not hold a track, has stopped being a signal problem. Continuing to image it spends the rest of the drive's mechanical life for nothing and risks generating debris that takes the healthy heads with it.

When the boundary is crossed, the drive moves to the 0.02 micron ULPA-filtered clean bench described in cleanrooms versus laminar-flow benches for a head stack transplant. Detail on the procedure itself, including how the heads physically read and what a head crash destroys, lives in the linked references. After the donor heads are in, the workflow returns to this page: the adaptive parameters are handled for the heads now installed, the drive is checked head by head, and imaging runs through DeepSpar. All of that work is performed in-house at the Austin, TX lab, which takes mail-in drives from anywhere in the country.

How are adaptive parameters handled during a head swap?

A head swap replaces the patient drive's head stack assembly with one harvested from a matched donor. The donor heads have their own air bearing surface, their own preamp trim, and a slightly different fly height over the patient's platters, because the suspension is not the one the drive was calibrated around.

Per-head calibration is what the drive's adaptive parameters hold, which is why the job does not end when the stack is installed. On supported families PC-3000 reads the relevant adaptives and writes the set the drive should be using for the heads now in it. Which families are supported and which parameters are reachable depends on the platform and on the PC-3000 version. It is not a universal capability.

Verification is behavioral rather than numeric. The drive is asked to read its own firmware structures, then a representative range of user LBAs through Data Extractor, head by head. A head that reads gets imaged. A head that still does not read once the adaptives are in place is disabled in the head map, and imaging proceeds on the remaining heads with the understanding that whatever that head covered will be missing from the image.

All of this shrinks when the donor is closer. Same family, same firmware revision, same head map generation: donor matching is what keeps the post-swap work down, and it is why sourcing takes as long as it does.

What about when one head in the stack is much weaker than the others?

Mixed-strength stacks are ordinary on multi-platter drives: one head reads cleanly, two are marginal, one returns nothing. No setting makes the weak head match the strong ones, and pushing the channel toward the weak head degrades what the good heads were already returning. The answer is scheduling rather than tuning. Healthy heads carry the imaging first, at the imager rather than in firmware, and the weak head is worked last and alone with its own retry and timeout limits, once the rest of the drive is already banked. A head that returns nothing comes out of the head map.

How does the Service Area gate read channel access?

The Service Area holds the translator, the P-List and G-List, the SMART logs, and on WD ROYL drives the platter-resident shadow copies of the ROM modules that carry the head map and the servo adaptives. The drive has to read those tracks before the host LBA range exists. When the heads can read user tracks but not the SA tracks, which happens when the degraded head is the one covering the Service Area, the drive never finishes booting and the host sees nothing.

PC-3000 handles this with a hot-swap or a diagnostic-mode boot. In a hot-swap, a donor drive of the correct family is allowed to boot fully, loading firmware into RAM; a terminal command parks the heads via SLEEP; the donor PCB is then transferred to the patient HDA. The donor PCB now has firmware in RAM and reads the patient platters with the patient's heads. In diagnostic mode, the drive boots far enough to accept VSC commands without finishing the SA load, and the technician issues commands directly to read or rewrite Service Area structures.

Once the drive reaches a state where it accepts diagnostic commands, the channel-side work described above becomes possible. Before that point there is nothing to tune, because the drive cannot be addressed for imaging through any interface. Firmware repair and read channel work are sequential, not parallel.

Frequently Asked Questions