Intent

Select a fan interface and drive topology that delivers stable low-speed behavior, predictable control response, and diagnosable faults in multi-fan server trays.

2-wire DC: voltage control vs chopping (and what breaks first)

• Voltage control: reduces the supply delivered to the fan. Simple, but low-speed stability is limited by the fan’s internal commutation and minimum operating point.
• Chopping / switching: modulates the average voltage with a switch. More efficient, but higher EMI and acoustic risk if frequency/edges land in sensitive bands.
• Low-speed dead zone: below a minimum voltage/duty, a fan may fail to start or oscillate. A practical drive profile uses spin-up boost followed by a controlled ramp-down to the target.

3-wire fans: tach is only useful if measurement is engineered

• Added value: tach/FG provides RPM truth and early health hints (intermittent drops, jitter, “almost stalled” behavior).
• Key implication: RPM quality depends on the measurement method (windowing, debouncing, low-speed handling). Poor measurement creates false stalls and unstable fan curves.
• Design rule: treat tach as a feedback signal that needs a quality gate (valid/invalid) rather than a single raw number.

4-wire PWM fans: control-supply decoupling (server default)

• Decoupled power vs control: the fan keeps a stable supply while PWM acts as a speed request. This improves low-speed behavior and reduces control-side power artifacts.
• PWM electrical expectations: many 4-wire inputs are designed for an open-drain style drive with a pull-up; mismatched push-pull signaling can increase noise or create contention.
• Minimum controllable region: below a minimum duty/RPM, the response becomes non-linear. Fan curves should respect a minimum duty and use controlled ramps.
• Spin-up profile: short boost on cold start improves start success, then a ramp back to target prevents acoustic spikes.

Multi-channel drive: isolation, staggering, and failure containment

• Integrated multi-channel controllers: consistent policy and unified telemetry; requires careful thermal design and single-point failure analysis.
• Discrete high/low-side per channel: strong isolation and flexibility; larger BOM and more tuning across channels.
• Staggered spin-up: avoid simultaneous current steps when many fans start or accelerate at once. Use channel sequencing + ramp limits within the fan domain.
• Failure containment: a short or stalled fan should trip and isolate locally, not collapse the entire tray’s fan rail.

Fan-domain protection (actions and what to log)

• Overcurrent / short: current limit → latch-off or timed retry. Log fault count and last trip timestamp.
• Reverse connection risk (service / modular trays): block reverse polarity and raise a clear fault flag.
• Hot-swap transients: soft-start and controlled ramp reduce connector stress and avoid tach false events during insertion.

Output — Quick selection matrix

The selection criteria prioritize predictable control and serviceability for multi-fan server trays.

Intent

Eliminate unstable RPM readings and false stall flags by engineering tach measurement as a quality-controlled signal, then applying a low-false-positive stall decision flow with bounded retries.

Tach signal model: pulses, PPR, and two measurement modes

• Pulses-per-revolution (PPR): determines how pulse frequency maps to RPM. Wrong PPR assumptions directly distort RPM.
• Period capture: measures time between pulses. Better at low speed, but sensitive to glitches and missing edges.
• Count-in-window: counts pulses in a time window. Responsive at high speed, but quantized and unstable at low speed if the window is too short.

Low-speed stability: windowing + debouncing + confidence gating

• Adaptive window length: extend the measurement window at low RPM to reduce quantization and avoid “0 count” swings.
• Debounce / minimum pulse width: reject short glitches that would create phantom RPM and false “alive” status.
• Quality gate: output both RPM and a tach_valid indicator. When tach_valid is low, stall logic should enter a suspect state rather than trip immediately.

Failure patterns (classify before acting)

• Tach missing: no pulses for a timeout. Causes include connector issues, fan failure, or overly aggressive filtering.
• “Alive but wrong” pulses: jittery or inconsistent periods, glitches, or noise coupling. Requires quality checks before using RPM.
• Intermittent drops: RPM dips and recovers. Often indicates marginal mechanics, backpressure changes, or unstable low-speed command regions.

Stall / locked-rotor decision flow (bounded, serviceable)

• Confirm time: require the tach fault to persist long enough to reject transient disturbances.
• Kick retry: apply a short spin-up boost to recover from near-stall, limited by retry count and interval.
• Fail-safe: isolate the channel (if supported), raise a clear fault, and allow redundancy compensation to take over.

The goal is predictable behavior: avoid oscillating between normal and fault states, and avoid endless retry loops that create acoustic and electrical disturbances.

Output — Stall detection parameter checklist (fan domain)

• PPR (pulses per revolution)
• Measurement mode (period / count / hybrid)
• Window length policy (fixed vs adaptive)
• Debounce / minimum pulse width
• Confirm time (fault persistence threshold)
• Kick PWM and kick duration
• Retry count and retry interval
• Escalation level (suspect → confirm → fail-safe)
• Logging fields (fault count, last fault time, last valid RPM)

Intent

Make vibration sensing operational: choose sensor placement, pick robust indicators, align spectra to RPM to reduce false positives, and convert signals into tiered maintenance actions that work with fan redundancy.

Sensors: what matters for fan-tray health

• Accelerometer vs IMU: for fan imbalance and bearing wear, an accelerometer is typically sufficient; an IMU can help when multi-axis context is needed, but adds cost and integration overhead.
• Bandwidth and noise floor: the useful band should cover RPM-related components (1×/2×) and nearby structural resonance bands; noise floor determines how early degradation can be detected.
• Mounting and axis orientation: rigid mounting near the fan tray structure is critical; a loose or compliant mount turns “installation” into the dominant signal source.

Indicators: RMS, peak, and RPM-aligned spectral peaks

• RMS (band energy): best for trend monitoring and tiered thresholds; stable across windows when configured consistently.
• Peak: sensitive to knocks, looseness, and rubbing events; requires confirmation time to avoid one-off false alarms.
• Spectrum peaks (1×/2×): strongest for attribution. 1× often maps to imbalance; 2× can indicate misalignment or structural effects, depending on mechanics.

A single metric is rarely reliable; a minimal robust combination is RMS (trend) + 1× alignment (attribution) + persistence over time.

RPM alignment: using tach to reduce false positives

• Step 1 — validate tach: use a tach quality gate (valid/invalid) so RPM is not derived from glitches.
• Step 2 — compute expected frequencies: f1 = RPM/60 and f2 = 2×RPM/60.
• Step 3 — align the spectrum: search energy within narrow windows around f1 and f2. Peaks that do not track RPM are more likely resonance or ambient vibration.
• Step 4 — require persistence: promote events only when alignment persists across multiple windows (prevents “one-frame” misclassification).

Maintenance tiers: convert signals into clear actions

• Watch: mild RMS rise, occasional 1× alignment. Action: log trend, increase observation frequency, no immediate fan speed escalation.
• Plan: persistent 1× alignment + upward RMS trend. Action: schedule replacement in a maintenance window; keep N+1 margin.
• Replace now: strong peaks, repeated shocks, or vibration correlated with intermittent RPM drops. Action: fail-safe escalation and redundancy compensation.

Tiering avoids “alarm storms” and unnecessary full-speed operation while still protecting thermals.

Output — Symptom → probable cause → recommended action

RPM alignment is the primary discriminator between fan-originated issues and ambient vibration/resonance.

Intent

Make temperature inputs reliable for fan control: place sensors with clear physical meaning (inlet/outlet/hotspot), manage time constants and filtering to avoid fan hunting, and explain why a cold inlet can still coexist with a hot hotspot.

Sensor types (high-level, fan-domain view)

• Digital temperature sensors: consistent calibration and easy integration; placement and thermal coupling dominate accuracy in airflow paths.
• NTC thermistors: fast and low cost; requires linearization and careful mounting to avoid reading “air” instead of structure.
• Remote diode (hotspot source): can represent risk points, but this page treats it as a generic hotspot input without board-level deep dive.

Placement strategy: what each point is meant to answer

• Inlet (baseline): tracks ambient intake changes and gross intake restrictions; typically slow to reflect workload spikes.
• Outlet (system trend): correlates with total heat and long-term cooling sufficiency; may lag local risk.
• Hotspot (risk): fastest indicator of local over-temperature; must be filtered and gated to prevent control oscillation.

Sampling & filtering: stabilize the control loop

• Time-constant matching: sensors have different thermal lag; mixing raw values can cause unstable fan demand.
• Filtering: moving average or first-order filters reduce noise but add delay; hotspot paths require careful balance.
• Step detection: detect rapid rises and apply temporary override (boost) without permanently raising noise levels.
• Validity checks: detect stuck-at, open/short, or implausible jumps; degrade gracefully instead of oscillating.

Airflow hints (fan-domain only)

• RPM is not airflow truth: backpressure and filter clog can reduce airflow even when RPM is high.
• Consistency checks: if RPM is high but outlet/hotspot continues rising, suspect restriction or recirculation in the airflow path.
• Action tie-in: use these hints to select safe fan curves and avoid misattributing a thermal issue to tach or vibration alone.

Output — Temperature placement checklist

• Location: inlet near true intake, outlet near exhaust path, hotspot at the risk zone (not in a dead-air pocket).
• Thermal coupling: ensure consistent contact to the intended medium (structure vs air); avoid floating sensors.
• Shielding from direct blast: prevent inlet sensors from being artificially cooled by local jets that do not represent bulk intake.
• Calibration consistency: account for sensor tolerances and mounting variance; verify cross-sensor plausibility.
• Sampling & filter settings: choose update rate and filter strength to avoid hunting; use separate filters per zone if needed.
• Fault handling: define behavior for open/short, stuck values, and sudden jumps (invalidate → substitute → alert).

Intent

Turn a fan curve into an executable, verifiable policy: stable temperature regulation without audible hunting, while protecting fan mechanics and minimizing unnecessary high-speed operation.

Curve strategies: LUT vs PID vs hybrid

• Lookup table (piecewise linear): widely used in servers because it is auditable and predictable. Requires hysteresis + ramp limits to avoid threshold hunting.
• PID (closed-loop): useful when the controlled temperature is well-defined and measurements are trustworthy. Needs output limiting and anti-windup to prevent oscillation under delays.
• Hybrid (feedforward + small closed-loop trim): uses a LUT for the main command and applies a limited trim for disturbances. This keeps behavior explainable while improving stability.

Anti-hunt toolkit: four mechanisms that make curves stable

• Hysteresis band: separate “enter” and “exit” thresholds so small temperature wandering does not cause frequent curve segment switches.
• Deadband: ignore tiny changes (ΔT) to avoid micro-updates that become audible PWM/RPM modulation.
• Minimum PWM / minimum RPM: prevent low-speed stall and tach instability; define a stable operating floor for the fan family.
• Ramp (slew-rate) limits: shape PWM changes over time to reduce acoustic spikes and mechanical stress. Use asymmetric ramps: faster up, slower down.

Ramp limits should cooperate with step detection: allow a time-bounded override for rapid hotspot rises, then return to smooth behavior.

Zone fusion: turning multi-sensor inputs into one command

• Zone max: safest for hotspot protection but can be dominated by one noisy sensor; requires validity checks and confirmation time.
• Weighted fusion: quieter and smoother, but can under-react to a true hotspot unless a priority override exists.
• Priority (hotspot override): run weighted fusion in normal conditions, then promote hotspot to priority control beyond a defined threshold.

Noise constraints (policy-level)

• Night mode: cap maximum PWM or tighten downward ramps to minimize audible transitions.
• Acoustic cap: flatten selected regions of the curve so normal workload variation stays within a predictable noise envelope.
• Emergency exception: allow temporary cap bypass only in high-risk states (e.g., Boost/Critical), and log the duration.

Output — Curve design parameters (config-ready table)

Intent

When cooling margin disappears, the system should move through explicit safe states—boost, degraded, critical, shutdown—using confirmation timers and recovery hysteresis to prevent thrashing. The goal is controlled behavior with clear logs and predictable outcomes.

Triggers (fan-domain view with confidence)

• Thermal: hotspot over threshold, outlet trend rising, or rapid temperature slope detected (highest priority).
• Fan health: tach missing, stall detected, fan absent/present mismatch, or repeated restart failures.
• Vibration tier: persistent RPM-aligned peaks or severe shocks; treat as predictive risk that tightens policies rather than immediate shutdown.

Actions by state (what changes, and why)

• Normal: follow H2-7 control policy (zone fusion + stabilizers).
• Boost: temporarily raise fan demand; allow a time-bounded ramp override for fast hotspot recovery; enable hotspot priority control.
• Degraded: keep service running with reduced margin; increase base airflow and issue an abstract throttle request upstream (no CPU mechanism details).
• Critical: enforce stronger protection (more aggressive boost + throttle request); require stricter recovery conditions.
• Shutdown (last resort): request an orderly stop when hardware risk is imminent and recovery is not possible within safe limits.

Anti-thrash safeguards (the difference between safe and noisy)

• Confirm time: require triggers to persist (sensor-dependent) before state entry; prevents one-sample spikes from escalating.
• Combined conditions: use “AND with guardrails” (e.g., hotspot high + outlet rising) to promote severe states.
• Recovery hysteresis + hold time: exit only after temperature is below a recovery threshold for a minimum duration; avoids bouncing.

A safe-state machine must be harder to exit than to enter; otherwise it oscillates under noise and delays.

Output — Derating strategy card (Trigger → Action → Recovery)

Keep trigger logic explicit and logs consistent so operational teams can reproduce and audit decisions.

Intent

Cover the core availability requirement in rack servers: keep thermals stable through a fan failure or hot-swap by combining grouped N+1 compensation, zone recomputation, and explicit fault-to-action mapping.

N+1 and grouping: compensate without “everything to max”

• Group-level uplift: when one fan in a group fails, uplift the remaining fans in that group first. This preserves acoustics better than a global uplift.
• Zone recomputation: re-evaluate zone fusion (max/weighted/priority) under reduced airflow margin; bias toward hotspot protection only when needed.
• State gating: if redundancy is lost and temperature trends worsen, escalate to a safer state (Boost/Degraded) rather than oscillating the curve.

Hot-swap flow (fan domain only)

• Present detection: debounce present transitions to avoid contact chatter creating false remove/insert events.
• Swap transient window: during insertion/removal, treat tach as invalid and suppress stall classification until stability is proven.
• Post-insert self-test: run a short spin-up phase, then require tach_valid across multiple windows before joining normal policy control.
• Return to policy: ramp back to the computed target (avoid abrupt drops that create audible steps).

Key rule: do not enter closed-loop decisions on a newly inserted fan until tach validity is established.

Fault coupling: consistent alarm level and deterministic actions

• Tach missing / invalid: classify only after confirm time; correlate with present transitions and low-speed conditions to avoid false stalls.
• Stall / lock: escalate after retries; apply a bounded re-kick (spin-kick) policy and log retry counters.
• Current anomaly (fan domain): separate short startup surge from persistent overcurrent; persistent cases should promote severity quickly.
• Vibration anomaly: treat as predictive risk; tighten policy and maintenance tiering, but do not jump to shutdown without thermal/health corroboration.

Output — Fault tolerance matrix (type × severity × action × log fields)

A good matrix separates transient behavior (swap/surge/noise) from persistent faults (stall/persistent overcurrent).

Intent

Make observability practical: connect the fan-control fast path (PWM/tach/sideband) with the slow management path (I²C/SMBus/PMBus semantics), define minimal telemetry that debugs most failures, and prevent log storms with dedupe and throttling.

Interface layers (what each path is responsible for)

• Fast path: PWM command, tach/FG feedback, and sideband (present/fault). This is where control stability and validity gating happen.
• Slow path: I²C/SMBus/PMBus-style registers for configuration, status, and telemetry snapshots. Use it for auditability and forensics, not for high-rate control loops.
• Event path: timestamped alarms and state transitions with dedupe and rate limiting to keep logs readable under fault conditions.

Recommended fields (organized as a diagnostic loop)

Alarm & event hygiene (avoid log storms)

• Dedupe: merge repeated identical alarms for the same fan and state; keep a counter and first/last timestamps.
• Rate limiting: cap events per time window; if exceeded, emit a summary record (count + window).
• Correlation snapshot: attach pwm_cmd, rpm_meas, tach_valid, temps, state to each promotion/demotion event.

Debug order (fast isolation path)

1. Start with pwm_cmd / rpm_meas / temp_snapshot: confirm the loop is coherent.
2. Then check tach_valid, stall_cnt, retry_cnt: determine whether the system is fighting a mechanical/electrical fault or a validity gate.
3. Finally evaluate vib_tier and alignment: only RPM-aligned persistent vibration should tighten policy or promote maintenance tiering.

This order isolates “command mismatch” before digging into deeper causes.

Intent

Provide an execution-ready workflow for engineering bring-up and field support. The playbook is organized as a bring-up ladder, a set of fan-domain validation cases (thermal/acoustic/EMI), and a 3-step triage method for the most common site issues.

Reference BOM (example part numbers for fan-domain builds)

These are representative, commonly-used devices for multi-fan control, temperature inputs, and vibration sensing. Exact choices depend on channel count, bus constraints, and telemetry needs.

Part numbers are provided as examples to make the playbook actionable. Validate footprint, channel count, and bus voltage for the target platform.

Bring-up ladder (single fan → groups → zones → redundancy injection)

• Stage A — Single-fan sanity: open-loop PWM steps → verify rpm_meas monotonicity and stable tach_valid. Then enable a minimal LUT curve with min_pwm and ramp.
• Stage B — Multi-fan grouping: drive a group with identical PWM; quantify RPM dispersion and confirm group uplift does not create audible hunting. Keep the loop stable before adding more zones.
• Stage C — Multi-zone fusion: introduce inlet/outlet/hotspot inputs; compare fusion rules (weighted vs max vs priority) under controlled disturbances. Confirm hotspot protection triggers only when required.
• Stage D — Redundancy & fault injection: remove a fan, force tach_missing, and inject stall/retry scenarios. Verify the system executes: group uplift → zone recompute → state escalation with clean, deduped logs.

Thermal validation (dynamic response, not only steady-state)

• Step load: apply a temperature-driving disturbance (real load or controlled heater). Pass if hotspot remains within guard bands and the system avoids repeated state flips.
• Airflow restriction: partial blockage / backpressure simulation. Pass if reduced airflow is handled as a trend (temps + RPM response) rather than being misclassified as stall.
• Fan removal: remove one fan (or one group member). Pass if N+1 compensation triggers within the expected time and logs capture the correlation snapshot once (no storm).
• Filter aging simulation: gradually reduce airflow (slow degradation). Pass if the policy tightens gracefully (no PWM thrash) and maintenance tiering can be raised without unsafe actions.

Keep this fan-domain: do not attribute failures to facility HVAC; classify them by local sensors and response coherence.

Acoustic stability validation (ramp & hysteresis prove-out)

• Threshold dither test: hold temperature near a curve breakpoint and add small ±ΔT disturbances. Pass if PWM/RPM do not “ping-pong” across breakpoints.
• Ramp comparison: compare “no ramp” vs “ramp-limited” profiles. Pass if ramp removes audible modulation while keeping thermal settling time acceptable.
• Night cap behavior: if an acoustic cap exists, pass only if Boost/Degraded overrides are deterministic (with hold time and clean recovery), not oscillatory.

EMI validation (fan-domain PWM, edge control, routing, local filtering)

• PWM frequency sweep: evaluate a small set of candidate PWM frequencies and check for tach corruption, sensor noise, or false stall triggers.
• Edge-rate control A/B: adjust drive strength / series resistor / buffering. Pass if EMI improvements do not degrade tach validity or thermal response.
• Routing & return path checks: keep high-current fan return loops separated from tach/sensor references; verify that moving the return reference changes false-alarm rates (a strong indicator of coupling).
• Local filtering: apply fan-domain beads/RC only where coupling is observed. Pass if alarms stabilize and telemetry remains consistent.

This section stays at the “knobs you can turn” level; it does not expand into full-system EMC compliance strategy.

Field debug playbook (common symptoms → deterministic triage)

Use the same three questions every time to avoid chasing secondary artifacts.

• RPM jitter / “hunting”: first confirm temperature inputs are stable and filtered; then confirm ramp + hysteresis + hold time are applied; finally confirm tach_valid is not flapping.
• False stall alarms: check present transitions and swap windows; confirm tach validity gates are suppressing classification during insertion/removal; then tune stall confirm time and retry spacing.
• Cold inlet but hotspot hot: validate hotspot sensor placement/credibility; verify zone priority and fusion rules; look for airflow restriction trends (not just instantaneous RPM).
• Vibration alarm but thermals OK: require RPM-aligned persistence before escalation; otherwise treat as environment/resonance and keep actions maintenance-grade.
• Log storm: validate dedupe and rate limiting; if state toggles frequently, return to input trust and hysteresis/hold design.

Output — Validation checklist (test → observe → pass/fail)

A checklist is only useful when each line item specifies what to observe and how to decide pass/fail.