123 Main Street, New York, NY 10001

Vibration & Condition Monitoring: IEPE, Edge FFT & RS-485

← Back to: Industrial Sensing & Process Control

Central idea: Vibration & Condition Monitoring is only reliable when the entire evidence chain is controlled and provable—from IEPE excitation and low-noise AFE/ADC, through anti-alias filtering and clock/sync, to edge FFT/envelope features with timestamps, counters, and versioned parameters. The goal is not “more algorithms,” but repeatable health indicators backed by waveforms, logs, and minimal fixes that can be verified in the field.

H2-1. Mission, Reader Fit, and “Evidence Chain” Definition

This page defines vibration & condition monitoring as a verifiable measurement chain: the system must prove that the sensed waveform is real, correctly sampled, and analytically trustworthy—not just “a sensor + FFT”.

The goal is to build a chain that outputs evidence fields alongside features, so field issues can be triaged by measurement integrity first (bias headroom / aliasing / clipping / sync) before algorithm tuning.

What “good” must guarantee
  • SNR & dynamic range that match the target frequency band and crest factor.
  • Anti-saturation behavior (predictable headroom; graceful gain plan; clip detection).
  • Controllable bandwidth with anti-aliasing consistent with the chosen sampling rate.
  • Sampling integrity (clock health + multi-channel alignment when needed).
  • Traceable timestamps for each analysis window and each transmitted payload.
Minimum evidence fields loggable
  • IEPE bias window + headroom status (open/short/saturation flags).
  • Clipping counters + peak/RMS per analysis window.
  • Sampling snapshot: sample rate, decimation, AA filter profile/version.
  • Clock status: PLL lock + drift/holdover indicator.
  • Feature provenance: algorithm version + parameter hash (windowing/envelope settings).
Engineering rule: if a “health index” fluctuates, the first checks are headroom, aliasing, clipping, and sync. Only after evidence fields are clean should analytics thresholds/models be adjusted.
Evidence Chain Map Measure → Prove → Analyze → Transport IEPE Input Bias window Headroom flags Analog Front-End Noise budget Gain plan ADC + Clock Clipping counters Clock status Edge Analytics FFT / Envelope Param version Transport + Traceability Ethernet Window timestamp Feature payload + counters RS-485 CRC / drop counters Trigger: raw snippet Rule: prove integrity before tuning analytics.
Figure: evidence chain blocks and the minimum loggable fields that make vibration analytics reproducible in the field.
Cite this figure: Copy figure citation

H2-2. Use Cases & Signal Requirements (Frequency, Dynamic Range, Channel Count)

Requirements must be quantified first. Vibration features only become trustworthy when the target frequency span, peak/crest factor, sampling plan, and synchronization level are explicit. This section converts application intent into parameters that drive AFE/ADC/filtering and the edge analytics pipeline.

Scenario ARotating machinery
  • Spectrum shape: strong 1× + harmonics, sidebands; bearing faults often appear in envelope spectrum.
  • Critical integrity risks: aliasing that moves sidebands; clipping that fabricates harmonics; channel skew that breaks coherence.
  • Typical outputs: peak list (1×/harmonics), sideband spacing, envelope peaks with confidence score.
Scenario BReciprocating / impact
  • Signal shape: transients and broadband energy; high crest factor dominates gain planning.
  • Critical integrity risks: saturation during impacts; “features-only” payloads that cannot be audited without snippets.
  • Typical outputs: RMS/peak/crest factor, kurtosis, triggered raw snippets for forensic review.
Scenario CStructural resonance
  • Spectrum shape: narrow peaks (modes); comparisons depend on consistent frequency response.
  • Critical integrity risks: channel-to-channel mismatch (gain/phase); timestamp-only alignment when phase coherence is required.
  • Typical outputs: resonance peak tracking, bandwidth/Q estimate, multi-channel relative phase (when synchronized).
Minimum input formfill-before-design
  • Target band: fmin / fmax (Hz), plus any “must-keep” tones or defect bands.
  • Peak & crest: expected peak g (or peak-to-peak) and crest factor for transient headroom.
  • Sampling: sample rate (Fs), window length (time or N points), and allowed decimation steps.
  • Channels & sync: channel count; phase-coherent vs timestamp-aligned requirement.
  • Throughput: features-only vs “features + triggered snippets” transport budget.
Design implication: each requirement line maps to a control knob—AA filter corner ↔ Fs, gain steps ↔ crest factor, and sync level ↔ multi-channel diagnostics.
Requirement → Sampling → Analytics Turn use-case intent into parameters and evidence outputs Requirements Sampling Plan Analytics Freq band fmin / fmax keep tones / bands Amplitude peak g / p-p crest factor Channels Nch sync level Fs & window sample rate (Fs) window length (N / ms) AA & decimation AA filter profile decimation steps Sync & timestamps phase-coherent? window timestamp FFT peak list / bands confidence fields Envelope bearing bands param snapshot Health features RMS / peak / CF kurtosis / index
Figure: how scenario intent becomes sampling parameters, then analytics outputs with provenance and confidence fields.
Cite this figure: Copy figure citation

H2-3. IEPE Constant-Current Excitation: Compliance, Bias Headroom, Fault Modes

IEPE sensing is a two-wire bias + AC signal system. A constant-current source powers the sensor’s internal buffer, while the vibration waveform rides on a DC bias level. When compliance or headroom is insufficient, the chain can output “plausible” spectra that are physically incorrect. This section defines the minimum evidence fields that prove the IEPE link is healthy.

Field question 1Signal shrinks / distorts
  • Likely root cause: bias headroom is consumed (compliance limit or analog saturation).
  • What to measure: IEPE bias voltage against the valid window; check saturation/headroom flags.
  • First fix: restore compliance margin (reduce excitation current, reduce drop in protection path, shorten cable, or adjust input loading).
Field question 2Noise increases after cable change
  • Likely root cause: cable capacitance and shielding/grounding alter HF roll-off and common-mode coupling.
  • What to measure: noise floor (band-limited RMS) and 50/60 Hz indicators; compare A/B with the same sensor.
  • First fix: correct shield termination and impedance; avoid protection capacitance that loads the input at high frequency.
Field question 3Open / short / miswire detection

Fault detection should be based on bias-window state and excitation current state. The most dangerous mode is compliance-limited distortion, where the link is not fully open/shorted but still produces invalid waveforms.

Fault signatures
  • Open: bias rises toward high limit; unstable bias window.
  • Short: bias collapses low; current enters limit/foldback.
  • Miswire: bias sits in abnormal range; AC amplitude unusually low.
  • Saturation: bias appears “normal” but waveform shows flat-top distortion; harmonics become artificial.
  • Drift: slow bias shift or noise-floor rise with temperature or cable movement.
Minimum evidence fields
  • iepe_bias_voltage + iepe_bias_window_state (low/normal/high).
  • iepe_headroom_flag (compliance margin / saturation).
  • iepe_current_setting + iepe_current_state (normal/limit/foldback).
  • iepe_fault_code (open/short/miswire/saturation/drift).
  • noise_floor_rms and hum_50_60_indicator for cable/ground diagnostics.
Rule: if the bias window is not proven healthy, spectra and envelope results should be marked low confidence regardless of algorithm quality.
IEPE Two-Wire Bias + AC Signal Compliance & headroom determine waveform validity Constant-Current IEPE CC I setting I state Cable C (capacitance) Shield / ground IEPE Sensor Internal buffer Bias level AC output Input Zin Protection Waveform Validity Headroom ceiling Headroom floor DC bias Healthy: AC on bias Compliance-limited: flat-top Insufficient compliance → distortion Evidence bias window current state Cite this figure Copy citation
Figure: IEPE constant-current excitation with bias headroom limits; compliance shortage creates flat-top distortion that must be flagged by bias-window evidence.
Cite this figure: Copy figure citation

H2-4. Analog Front-End Architecture: AC Coupling, Protection, Gain Plan, Noise Budget

The analog front-end is where “measurable” becomes accurate and repeatable. A robust AFE must control low-frequency behavior (AC coupling), protect against miswire and transients without destroying bandwidth/phase, and implement a gain plan that prevents clipping while preserving small-signal resolution.

AC couplingcorner selection
  • Trade-off: keep meaningful low-frequency content while suppressing bias drift and slow offsets.
  • Evidence: high-pass profile ID plus a drift indicator computed per window (mean / trend).
  • Design rule: coupling corner should be explicit and tied to the use-case frequency band.
Input protectionparasitics matter
  • Risk: protection capacitance/leakage shifts bandwidth and phase, altering spectra and coherence.
  • Evidence: front-end bandwidth profile and (when available) frequency-response calibration version.
  • Design rule: protection should be staged so that the measurement path does not inherit large parasitics.
Gain planavoid clipping + keep ENOB

Gain must be treated as a recorded state, not an implicit analog detail. Without gain-state provenance, the same machine can produce different feature values that cannot be reconciled in the field.

  1. Define headroom for peak/crest factor; reserve margin so transients do not saturate the AFE or ADC.
  2. Create gain steps (ladder) that cover the expected dynamic range with minimal step count.
  3. Log every step: gain step ID, clipping counters, and per-window RMS/peak statistics.
  4. Stabilize switching: use hysteresis/freeze so gain transitions do not inject false modulation.
Noise budget (must be explicit)
  • Sensor source sets a baseline; AFE input-referred noise should not dominate in-band.
  • AFE noise + ADC quantization should be stated as a budget, not adjectives.
  • Measurement proof: a stable in-band noise floor across time and gain steps.
Evidence fields (minimum set)
  • rtinoise_uVrms (or band-limited noise_floor_rms).
  • clip_count + clip_flag per window.
  • gain_step_id + gain_change_count.
  • hp_corner_profile + dc_drift_indicator.
  • frontend_bw_profile (AA/response profile linkage).
Noise Budget + Gain Staging Ladder Repeatability requires noise proof, clipping proof, and gain provenance Budget stack (in-band) Sensor output baseline noise + signal AFE contribution input-referred noise HP corner profile ADC quantization ENOB / noise floor Evidence: rtinoise • clip_count • gain_step_id Gain ladder G0 high headroom G1 balanced G2 small-signal focus G3 max sensitivity low risk mid risk higher highest Log: gain_step_id • clip_count • window RMS/peak Cite this figure Copy citation
Figure: noise budget stack and gain ladder; repeatable analytics requires logged gain state and clipping/noise evidence per window.
Cite this figure: Copy figure citation

H2-5. Anti-Aliasing & Bandwidth Control: Filters That Match Your Analytics

Anti-aliasing is not a filter “topic”; it is a data validity gate. When out-of-band energy folds into the analysis band, spectra can show stable peaks that are not physically present. The system must bind the analog bandwidth to Fs / decimation and preserve channel-to-channel consistency, otherwise multi-channel comparisons and envelope results become untrustworthy.

SymptomPeak “moves” with Fs
  • Cause: AA corner does not track the effective sampling rate; aliasing folds a real out-of-band peak into the band.
  • Evidence: fs_hz + decimation_ratio + aa_corner_profile_id; flag mismatch if profiles are not bound.
  • First fix: freeze Fs/decimation, then validate AA profile; peaks that relocate with Fs are treated as alias suspects.
SymptomChannels disagree
  • Cause: inconsistent amplitude/phase response across channels (AA and front-end bandwidth variations).
  • Evidence: channel_response_profile_id per channel; freq_response_cal_id summary for consistency proof.
  • First fix: enforce the same response profile set across channels; downgrade confidence when profiles differ.
Envelope-ready bandwidthHF band + clean folding

Envelope analytics requires a defined high-frequency band that carries modulation. If AA or decimation causes folding, envelope spectra can produce “clean” peaks that are artifacts. Envelope confidence must incorporate alias/clipping evidence and the active band profile.

Minimum evidence fields
  • fs_hz + decimation_ratio (effective sampling).
  • aa_corner_profile_id + aa_profile_version (bound to Fs).
  • config_mismatch_flag (AA vs Fs/decimation mismatch).
  • channel_response_profile_id + channel_mismatch_flag.
  • envelope_band_profile + envelope_param_hash + envelope_confidence.
Verification deliverables
  • Production / calibration: frequency-response sweep summary linked by freq_response_cal_id.
  • Runtime binding: AA profile and effective Fs share a versioned configuration record.
  • Confidence policy: any mismatch marks FFT/envelope outputs as low confidence.
Rule: alias control is a configuration contract. If Fs/decimation changes without the bound AA profile, the spectrum is not admissible evidence.
Aliasing: Out-of-Band Folds Into Band AA weak • Fs low • Decimation mismatch True spectrum Frequency In-band Out-of-band peak AA corner Observed spectrum (after sampling) Frequency In-band Folded peak AA weak Fs low Decimation mismatch Evidence fields fs_hz aa_profile decimation version mismatch flag Cite this figure Copy citation
Figure: aliasing occurs when out-of-band energy folds into the analysis band; preventing “ghost peaks” requires AA/Fs/decimation binding and versioned profiles.
Cite this figure: Copy figure citation

H2-6. Low-Noise ADC & Clocking: ENOB, THD, Aperture Jitter, Multi-Channel Sync

“Low-noise ADC” is only meaningful when expressed as a selection ruler for the intended analytics. ENOB/SNR controls small-signal feature credibility, THD protects harmonic-based diagnostics, and aperture jitter consumes high-frequency SNR. For multi-channel diagnostics, the timebase and synchronization mode define whether phase/coherence results are admissible.

ENOB / SNRsmall signals
  • Why it matters: early faults often appear as subtle band-energy or peak changes; noise floor drift breaks health indices.
  • Evidence: band-limited noise_floor_rms and an SNR/ENOB profile reference.
  • Policy: unstable noise floor → downgrade feature confidence even if FFT looks “clean”.
THDharmonic truth
  • Why it matters: harmonic patterns (gear mesh, rotational harmonics) must reflect physics, not converter nonlinearity.
  • Evidence: thd_indicator linked to calibration; always interpret together with clip_count.
  • Policy: clipping or saturation disqualifies harmonic interpretations for that window.
Aperture jitterHF SNR loss

High-frequency analytics is limited by clock timing uncertainty. As the highest effective frequency increases, the allowable jitter becomes tighter. A practical selection approach is to classify the clock as low / medium / high jitter and bind that class to the maximum effective band.

Selection rulers (engineering)
  1. Max effective frequency → choose a jitter_class that preserves HF SNR for that band.
  2. Peak g + gain plan → set ADC full-scale and headroom; track clip_count per window.
  3. Window length + bandwidth → set throughput; select payload_mode (features-only vs snippets).
  4. Multi-channel need → choose sync_mode (timestamp-aligned vs phase-coherent).
Minimum evidence fields
  • noise_floor_rms + snr_estimate + enob_profile_id.
  • thd_indicator + clip_count.
  • clock_source_id + pll_lock_status + jitter_class.
  • sync_mode + channel_skew_estimate + timebase_health.
  • window_length_ms + payload_mode.
Rule: high-frequency credibility depends on clock class. If pll_lock_status is not healthy, HF features should be marked low confidence.
Clock Jitter Consumes HF SNR (Concept) Low jitter degrades slower at high frequency Effective SNR vs Frequency Higher Frequency → Effective SNR Low Mid High Low jitter clock High jitter clock HF SNR loss increases Clocking & Sync Chain Clock source clock_source_id PLL / timebase pll_lock_status jitter_class ADC sampling ENOB / THD clip_count Multi-channel sync sync_mode skew timebase_health Cite this figure Copy citation
Figure: clock jitter reduces effective SNR increasingly at higher frequency; logging clock class, PLL health, and sync mode makes HF analytics auditable.
Cite this figure: Copy figure citation

H2-7. Edge Analytics Pipeline: Windowing, FFT, Envelope, Kurtosis, Health Index

Edge analytics must be auditable. Every FFT peak, envelope peak, kurtosis jump, and health-index alarm must be tied to the window’s input conditions (gain, clipping, alias risk, timestamp quality) and to a reproducible algorithm configuration (version + parameter snapshot). Without this provenance, field results cannot be reproduced or trusted.

Pipeline contractinputs → evidence → outputs
  1. Windowize: define window length/overlap and timestamp semantics (start/center), then compute per-window quality fields.
  2. Preprocess: detrend/DC remove and gain-step normalization; record preprocessing mode and parameter hash.
  3. FFT: apply a window function and compute spectrum peaks; record resolution and window function ID.
  4. Envelope: apply band-pass → envelope extraction → low-pass → envelope FFT; record band and method IDs.
  5. Features: compute RMS/peak/crest/kurtosis and derive a health index with baseline/threshold provenance.
Preprocesscomparability
  • Purpose: make windows comparable across time and gain steps; avoid treating bias drift as low-frequency energy.
  • Risk: inconsistent detrend/normalization creates false trends.
  • Evidence: detrend_mode_id, dc_remove_mode_id, gain_step_id, preproc_param_hash.
FFTleakage & peak truth
  • Purpose: stable peak lists for trending and diagnosis; leakage control is a validity requirement.
  • Risk: window choice and resolution alter apparent sidebands/harmonics.
  • Evidence: window_function_id, fft_n, fft_bin_hz, spectrum_peak_list, noise_floor_rms.
Envelopebanded + guarded
  • Purpose: detect modulation signatures; requires a defined HF band and clean sampling conditions.
  • Risk: bias/alias/clipping can create “clean” but invalid envelope peaks.
  • Evidence: envelope_band_profile, envelope_method_id, envelope_param_hash, envelope_peak_list, envelope_confidence.
Health indexedge-only
  • Purpose: turn features into a decision with baseline + threshold provenance.
  • Risk: index drift caused by noise floor drift or configuration changes.
  • Evidence: baseline_id, threshold_profile_id, drift_comp_mode, decision_reason_code.
Minimum per-window evidence (must log)
  • Identity: window_id, window_start_ts, window_length_ms.
  • Quality: clip_count, noise_floor_rms, timestamp_quality_flag, gain_step_id.
  • FFT: spectrum_peak_list (Top-N: freq/amp/snr), fft_bin_hz, window_function_id.
  • Envelope: envelope_peak_list (Top-N), envelope_band_profile, envelope_confidence.
  • Stats: rms, peak, crest_factor, kurtosis, health_index_value.
  • Provenance: algorithm_version, param_snapshot_hash (preproc/fft/envelope).
Rule: any window lacking param_snapshot_hash or key quality flags (clipping/alias/timestamp) is not admissible for root-cause analysis.
Envelope Analytics Flow (Edge) Band-pass → Envelope → Envelope FFT with evidence gates Pipeline Input window gain_step_id clip_count ts_quality Band-pass band_profile alias guard Envelope method_id param_hash Envelope FFT peak_list confidence Sensitive to faults bearing modulation impacts / looseness Sensitive to errors bias alias clipping Cite this figure Copy citation
Figure: envelope pipeline from band-pass to envelope FFT; outputs must be guarded by evidence fields (bias/alias/clipping/timestamp) and versioned parameters.
Cite this figure: Copy figure citation

H2-8. Data Transport: Ethernet vs RS-485, Payload Design, Timestamping & Determinism

Transport is part of the evidence chain. The link type determines whether the node can deliver continuous window features, on-demand raw snippets for traceability, and reliable timestamp quality. This section defines when RS-485 is sufficient, when Ethernet becomes necessary, and how payload modes and counters turn “field issues” into measurable facts.

RS-485 fits whenlow bandwidth
  • Use case: long runs, point-to-multipoint, robust physical layer, limited maintenance needs.
  • Payload: features-only windows (stats + peak lists + quality flags).
  • Evidence: packet_counter, crc_error_count, drop_counter; payload_mode must be logged.
Ethernet required whentraceability
  • Use case: multi-channel high-rate windows, remote diagnostics, and triggered raw snippets.
  • Payload: features + raw snippet on trigger for forensic reproduction.
  • Evidence: retransmit_count (if applicable), drop_counter, timestamp_quality_flag, update_capability_flag.
Two payload modesbandwidth vs evidence
Mode A — features-only
  • Send: stats + spectrum/envelope peak lists + quality flags per window.
  • Best for: continuous monitoring under tight bandwidth.
  • Must include: algorithm_version + param_snapshot_hash for reproducibility.
Mode B — raw snippet on trigger
  • Send: short waveform snippet plus the window’s parameter snapshot.
  • Trigger: health_index threshold, envelope anomaly, alias risk, or clipping events.
  • Must include: snip_trigger_reason, snip_length_ms, param_snapshot_hash.
Timestamping & determinism (edge)
  • Timestamp quality flag: locked / free_run / holdover (records whether the local timebase is trustworthy).
  • Drift record: clock_drift_ppm_est (or drift_class) when free_run/holdover is active.
  • Transport counters: packet_counter, drop_counter, crc_error_count, retransmit_count (if supported).
  • Determinism marker: payload_mode + window_id linkage ensures missing packets are detectable and explainable.
Rule: if drop_counter or crc_error_count rises, or timestamp_quality_flag is not locked, health-index alarms must include a transport/timebase caveat.
Two Payload Modes (Edge) Mode A: features-only • Mode B: raw snippet on trigger Mode A — Features-only Window features stats • peaks • quality flags algorithm_version param_snapshot_hash Low bandwidth continuous monitoring Mode B — Raw snippet on trigger Trigger HI threshold • anomaly • quality Waveform snippet snip_length_ms Traceable reason_code + param snapshot Transport + Evidence Counters RS-485 robust • long run Ethernet throughput • service Counters + timestamp quality packet/drop • crc/retry • ts_quality Cite this figure Copy citation
Figure: payload mode A (features-only) minimizes bandwidth; mode B (raw snippet on trigger) preserves traceability. Transport counters and timestamp quality complete the evidence chain.
Cite this figure: Copy figure citation

H2-9. Power, Isolation, Grounding, and Ruggedization (Sensor Nodes in the Real World)

Real-world sensor nodes fail the evidence chain in predictable ways: rail ripple can appear as low-frequency drift or stable mains hum peaks; grounding and shield termination can form loops that inject 50/60 Hz and slow bias wander; temperature and mechanical environment can create repeatable drift signatures. This section turns those “environment” issues into loggable quality evidence, not guesswork.

Power couplingLF drift • 50/60 Hz
  • How it shows up: slow baseline wander, 50/60 Hz peaks (and harmonics), and window-to-window instability during load events.
  • Why it matters: it contaminates RMS/health baselines and can create “stable” spectral peaks unrelated to mechanics.
  • Evidence fields: rail_ripple_rms (or pp), uvlo_event_count, brownout_flag, power_event_reason_code.
Grounding & shieldingloop avoidance
  • How it shows up: mains hum energy increases, channel mismatch, and low-frequency drift that follows installation changes.
  • Why it matters: a ground loop can mimic periodic “fault” energy and destabilize envelope confidence.
  • Evidence fields: shield_termination_mode, chassis_bond_status, isolation_boundary_id, ground_loop_suspect_flag.
Temperature driftsignature
  • How it shows up: gain/bias drift and gradual noise-floor lift; often correlates with temperature ramps or self-heating states.
  • Why it matters: health thresholds drift unless temperature and drift indicators are recorded and compensated at edge.
  • Evidence fields: temperature_c, temp_rate_c_per_min, gain_drift_indicator, bias_drift_indicator.
Ruggedizationevidence impact
  • Focus: only what directly affects the vibration chain: connector intermittency, cable shielding continuity, and enclosure bonding.
  • How it shows up: intermittent opens, bias window excursions, and step-like changes in noise floor.
  • Evidence fields: open_short_flag, bias_window_status, self_test_result_code.
Minimum “environment quality” log set
  • Power: rail_ripple_rms (or pp), uvlo_event_count, brownout_flag, power_event_reason_code.
  • Grounding: shield_termination_mode, chassis_bond_status, isolation_boundary_id, ground_loop_suspect_flag.
  • Temperature: temperature_c, temp_rate_c_per_min, gain_drift_indicator, bias_drift_indicator.
  • Self-check hooks: self_test_result_code, open_short_flag, noise_floor_rms (same definition as analytics).
Rule: when ground_loop_suspect_flag is set or rail ripple events coincide with anomalies, FFT/envelope alarms must carry a quality caveat and confidence downgrade.
Ground Loop & Isolation Boundary Bad: loop injection • Good: clear boundary + single-point shield Bad (Loop) Sensor shield AFE/ADC signal GND Chassis / Earth signal shield bonded shield bonded Loop Hum / LF drift False peaks Good (Boundary) Isolation boundary Analog side Digital side Sensor shield MCU comm AFE/ADC Chassis / Earth single-point shield Evidence shield_mode boundary_id hum_flag Cite this figure Copy citation
Figure: grounding mistakes create loops that inject mains hum and low-frequency drift; a clear isolation boundary and single-point shield termination improves evidence credibility.
Cite this figure: Copy figure citation

H2-10. Calibration & Self-Test: From Production to Field Re-Validation

Long-term reliability comes from a repeatable calibration and self-test loop. Production calibration establishes gain/phase/frequency-response baselines. Field self-test verifies wiring integrity and noise-floor health. Calibration data must be protected with versioning and integrity checks, and every analytics window must bind to a calibration ID and parameter snapshot so firmware changes do not silently shift health indicators.

Minimal calibration setproduction deliverables
  • Gain baseline: gain_cal per gain step (or gain_step_id mapping) with a calibration_id.
  • Channel alignment: phase_delay_cal summary (skew/phase consistency evidence for multi-channel comparisons).
  • Frequency response: freq_response_cal_summary (key points or band summary) for in-band amplitude/phase consistency.
Minimal self-test setfield validation
Integrity checks
  • Open/short/miswire: bias window + input status → open_short_flag.
  • Noise-floor self-check: noise_floor_rms vs baseline range; flag drift.
  • Optional injection: fixed-tone or short sweep (if supported) for response sanity.
Self-test evidence
  • self_test_id, self_test_timestamp, self_test_result_code.
  • open_short_flag, bias_window_status, noise_floor_rms.
  • inject_test_enabled, inject_profile_id (if used).
  • self_test_confidence.
Calibration data protection (device-level)
  • Integrity: cal_data_crc; reject corrupted calibration data.
  • Versioning: cal_data_version, cal_profile_version, calibration_date.
  • Compatibility: firmware_version + algorithm_version + cal_fw_compat_matrix_id.
  • Rollback: rollback_policy_id (retain last-known-good calibration slot).
Rule: every analytics window must include calibration_id + algorithm_version + param_snapshot_hash. If the trio is incompatible, set calibration_stale_flag and require re-validation.
Calibration & Self-Test Loop (Device) Production baseline → Runtime binding → Field re-validation 1) Production cal calibration_id gain freq resp cal_data_crc 2) Runtime windows window evidence algorithm_version param_snapshot_hash bind calibration_id 3) Field self-test self_test_result open/short noise floor self_test_id Decision & actions compatibility check cal_fw_compat_id calibration_stale_flag re-validation required actions re-test • re-cal • rollback Cite this figure Copy citation
Figure: production calibration creates versioned baselines with CRC; runtime windows bind cal_id + algorithm version + parameter hash; field self-test confirms integrity and noise floor; incompatibility triggers re-validation or rollback.
Cite this figure: Copy figure citation

H2-11. Validation & Debug Playbook (Waveforms + Logs You Must Capture)

The fastest field debug path is to disprove chain failures before tuning algorithms. Classify anomalies in a fixed order: IEPE headroom → clipping → aliasing → sync/clock → transport → parameters. Each step below defines exactly what to capture and which evidence fields must be saved.

Step 1IEPE headroom / bias window
  • Goal: rule out IEPE compliance/bias headroom collapse that shrinks or distorts the signal.
  • Capture: bias_min/bias_max over the anomaly window, open/short flags, and (if available) excitation current monitor.
  • Fail signature: bias approaches rails or leaves the valid window, correlated with amplitude drop or distortion.
  • Next action: log a headroom_fail_reason_code and continue to Step 2; do not interpret FFT/envelope peaks as mechanical yet.
MPN examples (IEPE excitation / input monitoring)
AD8244 (instrumentation amplifier), OPA140 (low-bias JFET op amp), LT3092 (programmable 2-terminal current source) as a building block for constant-current excitation (discrete approach), INA826 (INA option).
Step 2clipping / saturation
  • Goal: rule out clipping that creates false harmonics, inflated kurtosis, and unstable envelope peaks.
  • Capture: a raw waveform snippet (triggered Mode B), clip_count/overrange flag, peak-to-fullscale ratio, and gain_step_id.
  • Fail signature: non-zero clip_count or visibly flattened peaks; spectrum shows harmonic “ladder” uplift.
  • Next action: reduce gain / increase headroom; repeat the same window conditions before proceeding.
MPN examples (PGA/ADC overrange visibility)
AD8250 (programmable gain instrumentation amplifier), ADS127L01 (high-resolution delta-sigma ADC with diagnostics options), LTC2500-32 (high-resolution ADC family option for precision capture).
Step 3aliasing check
  • Goal: confirm whether “ghost” peaks are folded energy from out-of-band content.
  • Capture: two A/B runs with different sample rates or AA profiles; save fs_hz, aa_profile_id, and peak_list (Top-N).
  • Fail signature: suspicious peaks move when fs_hz changes, or vanish when AA profile is tightened.
  • Next action: lock fs_hz to the AA profile and record the binding as a configuration version.
MPN examples (anti-alias filtering building blocks)
LTC1564 (active filter / lowpass building block family), ADA4807-1 (high-speed low-noise op amp often used in AA stages), OPA1612 (low-noise audio/precision op amp usable for certain filter bands).
Step 4clock / sync integrity
  • Goal: ensure multi-channel phase/coherence conclusions are valid.
  • Capture: timestamp_quality_flag (locked/free_run/holdover), channel skew/phase summary, and clock lock status.
  • Fail signature: phase difference drifts between channels under identical conditions; timestamps show quality downgrade.
  • Next action: gate coherence features by sync quality; do not diagnose based on phase until stable.
MPN examples (clocking / synchronization)
AD9545 (jitter cleaner / clock generator family), Si5341 (jitter attenuating clock), LMK00334 (clock buffer/distribution).
Step 5transport loss / CRC
  • Goal: rule out missing/corrupted windows caused by the link.
  • Capture: packet_counter, drop_counter, crc_error_count, retransmit_count (if any), plus window_id continuity.
  • Fail signature: counters rise with anomalies; window_id gaps or timestamp discontinuities.
  • Next action: mark results with transport_caveat; trigger Mode B snippets for reproducible forensic review.
MPN examples (Ethernet / RS-485 PHY)
DP83825I (10/100 Ethernet PHY), KSZ8081 (Ethernet PHY option), SN65HVD1781 (robust RS-485 transceiver), ADM2587E (isolated RS-485 transceiver).
Step 6algorithm parameters (last)
  • Goal: only after the chain is clean, verify parameters and provenance for reproducibility.
  • Capture: algorithm_version, param_snapshot_hash, band/profile IDs, and calibration_id binding.
  • Fail signature: parameter mismatch between devices; firmware update changed param hash without re-validation.
  • Next action: enforce calibration_stale_flag + self_test_required_flag when incompatibilities are detected.
MPN examples (secure storage / logging primitives)
ATECC608B (secure element for identity/integrity), W25Q64JV (SPI NOR flash for logs), MB85RS64V (FRAM for robust parameter snapshots).
Save these 10 evidence fields (minimum)
1) window_id
Window identity for continuity checks and cross-references.
2) window_start_ts
Timestamp of the window (define start vs center consistently).
3) gain_step_id
Gain state used for that window; required for comparing features.
4) bias_window_status
Bias validity (or bias_min/bias_max) to prove IEPE headroom.
5) clip_count
Overrange indicator; any non-zero value invalidates many feature claims.
6) fs_hz
Sampling rate to verify aliasing conditions and comparisons.
7) aa_profile_id
Anti-alias/filter profile bound to fs_hz; required for reproducibility.
8) timestamp_quality_flag
locked/free_run/holdover (or equivalent) to gate coherence conclusions.
9) transport_counters
packet_counter + drop_counter + crc_error_count (+ retransmit_count if supported).
10) algo_provenance
algorithm_version + param_snapshot_hash + calibration_id binding.
Rule: if any step fails (headroom/clipping/alias/sync/transport), mark the window as non-admissible for root-cause claims until re-tested.
Validation & Debug Flow (Evidence-First) Headroom → Clipping → Aliasing → Sync → Transport → Params Anomaly detected (window_id) save snippet if possible Classification steps 1) Headroom bias_window_status 2) Clipping clip_count • gain_step_id 3) Aliasing fs_hz • aa_profile_id 4) Sync/Clock timestamp_quality_flag 5) Transport drop • crc • counters 6) Params (last) algo_version • param_hash • cal_id Outcome: root-cause class + quality caveat (if any) Cite this figure Copy citation
Figure: fixed-order debug flow that prevents premature “algorithm blame”. Each step is tied to an evidence field that must be captured and stored.
Cite this figure: Copy figure citation

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

H2-12. FAQs (Accordion) + FAQPage JSON-LD

These FAQs stay strictly inside the device-side evidence chain. Each answer follows the same 3-part template: Short answer (1 sentence), What to measure (2 checks: waveform/fields), and First fix (the minimum change to prove the cause).

FAQ Answer Pattern (Evidence-First) Symptom → What to measure → First fix (+ provenance) Symptom What to measure First fix “Health index jumps” quiet waveform “Ghost peaks” impossible freq “Events missing” RS-485 / Eth Waveform + fields bias / clip / fs AA profile / counters param hash / cal ID A/B comparisons change Fs / filter check peak moves then trust analytics Minimal change gain / headroom AA profile match snippet on trigger Provenance algo_version param_snapshot_hash calibration_id Cite this figure Copy citation
Figure: every FAQ answer is forced back to measurable evidence fields (bias/clipping/Fs/AA/counters/hash) and a minimal first fix for proof.
Cite this figure: Copy figure citation
1
Signal looks quiet but the health index fluctuates — noise floor drift or windowing? Maps to H2-4 / H2-7

Short answer: Most “quiet but unstable” health scores come from a drifting noise floor or inconsistent window settings, not real vibration changes.

What to measure:

  • Track noise_floor_rms (same definition every time) and compare it against a baseline over temperature/time.
  • Log window length / overlap / window function plus the active gain_step_id per window.

First fix: Freeze window parameters as a versioned profile, then re-run a stable test and confirm whether noise_floor_rms still drifts.

MPN examples: OPA1612 (low-noise op amp), ADS127L01 (precision ADC).
2
Sudden distortion after a cable change — IEPE compliance or capacitive loading? Maps to H2-3 / H2-4

Short answer: If distortion started right after a cable swap, suspect IEPE headroom loss or cable capacitance loading before suspecting analytics.

What to measure:

  • Record bias_min/bias_max (or bias_window_status) during the same vibration level and check for rail proximity.
  • Compare in-band noise floor and amplitude with the old cable at the same gain_step_id.

First fix: Restore headroom (lower gain or raise compliance margin) and validate bias stability; only then revisit filters or features.

MPN examples: LT3092 (current source building block), INA826 (instrumentation amplifier).
3
Peaks appear at impossible frequencies — aliasing or a resampling bug? Maps to H2-5 / H2-7

Short answer: If the suspect peak moves when you change sampling conditions, it is almost always aliasing rather than a “mystery fault.”

What to measure:

  • Run an A/B test with different fs_hz and log aa_profile_id for each run.
  • Compare the Top-N peak_list; alias peaks shift predictably with Fs, while true mechanical peaks stay put.

First fix: Bind Fs to a matched AA profile and lock it as a configuration version; only then audit resampling code paths.

MPN examples: ADA4807-1 (AA driver op amp), LTC1564 (active filter building block).
4
Bearing envelope band disappears at high speed — band-pass corner or clipping? Maps to H2-5 / H2-7 / H2-11

Short answer: High-speed cases often lose envelope content because clipping destroys modulation, or because the band-pass no longer covers the effective resonance region.

What to measure:

  • Check clip_count and inspect a raw snippet for flattened peaks during high-speed operation.
  • Log the active envelope band-pass profile (corner IDs) and confirm it still matches the resonance band.

First fix: Eliminate clipping first (gain/headroom), then retune the envelope band-pass profile and re-validate with the same operating speed.

MPN examples: AD8250 (PGA/INA), ADS127L01 (precision ADC).
5
FFT shows strong 50/60 Hz lines — ground loop or rail ripple coupling? Maps to H2-9 / H2-11

Short answer: Persistent 50/60 Hz lines usually indicate grounding/shielding mistakes or rail ripple coupling, not a true mechanical signature.

What to measure:

  • Log shield_termination_mode, chassis_bond_status, and whether ground_loop_suspect_flag is set.
  • Correlate hum energy with rail_ripple, uvlo_event_count, or other power-event markers.

First fix: Correct the isolation boundary and shield termination (single-point policy), then retest before applying notches or algorithm changes.

MPN examples: ADM2587E (isolated RS-485, isolation concept example), OPA140 (precision front-end op amp).
6
Two channels disagree in amplitude — gain step logging or calibration mismatch? Maps to H2-4 / H2-10

Short answer: Channel disagreement is usually traceability failure—different gain steps or mismatched calibration IDs—before it is a “sensor problem.”

What to measure:

  • Verify both channels logged the same gain_step_id and that no automatic range change occurred.
  • Compare calibration_id (and cal version/CRC) across channels and confirm identical response baselines.

First fix: Enforce per-window gain logging and a single calibration set for the device; only then interpret amplitude differences as real.

MPN examples: W25Q64JV (log storage), MB85RS64V (FRAM for snapshots).
7
High-frequency SNR is worse than expected — clock jitter or ADC front-end drive? Maps to H2-6

Short answer: If SNR degrades mainly at high frequency, clock quality and input-drive linearity are the first suspects, not FFT settings.

What to measure:

  • Measure SNR versus frequency and log the clock status (locked/holdover) or jitter-quality indicator if available.
  • Check ADC drive headroom: verify THD/overrange indicators and whether the AA/driver stage is within its linear region.

First fix: Stabilize the clock path and validate ADC drive conditions at the target frequency before re-tuning analytics thresholds.

MPN examples: Si5341 (jitter attenuating clock), LMK00334 (clock distribution).
8
RS-485 works but events are missing — payload too feature-only or trigger logic? Maps to H2-8

Short answer: “Missing events” on RS-485 is often a payload/trigger design issue—features-only packets may not carry enough proof for event classification.

What to measure:

  • Log the trigger decision: threshold hit, debounce state, and the feature values used at that moment.
  • Confirm whether a raw snippet was attached on trigger (or a “snippet requested” flag was raised).

First fix: Enable “raw snippet on trigger” (small, bounded) to validate that the trigger logic matches the waveform reality.

MPN examples: SN65HVD1781 (robust RS-485), ADM2587E (isolated RS-485).
9
Ethernet packets drop under load — buffer sizing or timestamping overhead? Maps to H2-8 / H2-11

Short answer: Drops under load are usually queue/buffer pressure or per-packet overhead (timestamping, logging), not “random Ethernet.”

What to measure:

  • Track drop_counter, crc_error_count, and any queue watermark/buffer-full indicator.
  • Compare CPU/ISR time spent on timestamping/logging versus payload throughput during the same window rate.

First fix: Increase buffering (or batch timestamps) and re-run the same load to confirm counters stabilize before changing analytics.

MPN examples: DP83825I (Ethernet PHY), KSZ8081 (Ethernet PHY option).
10
Health index shifted after a firmware update — parameter snapshot/versioning missing? Maps to H2-7 / H2-10

Short answer: If the score shifted after an update, suspect missing provenance (parameter snapshot + calibration binding) before suspecting a real mechanical change.

What to measure:

  • Verify algorithm_version and param_snapshot_hash are logged per window and match the expected profile.
  • Confirm the same calibration_id is still compatible (cal CRC/version check) with the new firmware.

First fix: Enforce stale-flag rules: if provenance mismatches, require re-validation/self-test before trusting health trends.

MPN examples: MB85RS64V (FRAM for param snapshots), ATECC608B (integrity/identity).
11
Open/short detection triggers falsely — bias window thresholds or protection leakage? Maps to H2-3 / H2-4

Short answer: False opens/shorts are commonly caused by poorly chosen bias thresholds, leakage in protection paths, or insufficient debounce—not a real wiring fault.

What to measure:

  • Log bias_min/bias_max around the trigger and capture the fault state history (debounce counters).
  • Compare the trigger rate versus temperature and input protection state to spot leakage-driven drift.

First fix: Tighten the bias window model and add robust debounce; confirm triggers disappear before changing analytics thresholds.

MPN examples: OPA140 (low leakage front-end), INA826 (INA option).
12
Why do raw snippets matter if FFT/features are already sent? Maps to H2-8 / H2-11

Short answer: Features cannot prove chain integrity—raw snippets are the only way to confirm clipping, aliasing, and transient shape when disputes happen.

What to measure:

  • Use a short triggered snippet to verify clip_count, bias stability, and whether the waveform matches the supposed event type.
  • Compare the same event with altered fs_hz/AA settings to prove (or dismiss) aliasing artifacts.

First fix: Implement a bounded policy: “snippets only on trigger or quality-fail,” so bandwidth stays low but evidence stays admissible.

MPN examples: W25Q64JV (log/snippet storage), DP83825I (Ethernet PHY).