Solar Array Drive Assembly (SADA): Drivers & Monitoring
← Back to: Avionics & Mission Systems
A Solar Array Drive Assembly (SADA) drive is not just a motor controller—it must deliver precise, smooth motion with fault-tolerant safe states and evidence-rich telemetry for long-life operation in space. This page explains the power stage, current/position sensing, protection, redundancy, and verification methods that turn “it can rotate” into “it is launch-ready.”
Solar Array Drive Assembly (SADA): Drivers & Monitoring
A Solar Array Drive Assembly (SADA) is the motion-control subsystem that points a spacecraft’s solar array with repeatable angle/velocity, predictable power and thermal behavior, and flight-verifiable health telemetry. In practice it combines a motor drive (stepper or BLDC), position feedback (encoder or resolver), and current/temperature monitoring so faults can be contained and the mechanism can be placed into safe hold/stow modes.
Motor drive electronics
Encoder / Resolver interfacing
Current & temperature monitoring
Fault flags & safe states
Scope boundary: This page focuses on SADA motor-drive electronics, encoder/resolver interfacing, and current/temperature monitoring.
Spacecraft power-bus architecture, TT&C protocols, timing networks, and crypto are out of scope here.
What SADA is and what it must guarantee
A SADA is not “just a motor driver.” It is a mission-critical pointing actuator that must deliver measurable guarantees: controlled angle/velocity, stable low-speed behavior, bounded power/thermal load, contained faults, and flight-verifiable observability.
Engineering guarantees (what must be provable)
- Pointing repeatability: angle error stays bounded across temperature, load, and lifetime contributors (backlash, quantization, drift).
- Low-speed smoothness: torque ripple and micro-motion are controlled to avoid jitter, chatter, and limit-cycle behavior.
- Predictable power draw: phase current and bus power remain within planned envelopes for each mode (slew, settle, hold, stow).
- Thermal containment: measured temperatures correlate with dissipation so derating and safe-state triggers are defensible.
- Fault containment: overcurrent/overtemperature/feedback loss lead to a bounded response (disable, safe hold, or controlled stow).
- Observability: telemetry provides enough evidence to distinguish mechanism effects from electronics/control issues (current/angle/temperature snapshots).
- Redundancy readiness: (if used) A/B channel behavior is diagnosable; switchover conditions and results are logged.
Practical reading tip: every guarantee above should map to at least one measurable signal (angle, current, temperature, bus voltage, fault flags) and one verification test.
Common pitfalls (what breaks projects late)
- “It spins” is treated as success: no acceptance definitions for jitter, thermal margin, or fault behavior.
- Mechanics vs electronics not separated: stiction/backlash is misdiagnosed as “driver instability,” wasting iteration cycles.
- Telemetry is too thin: without time-aligned current/angle/temperature snapshots, root cause becomes guesswork after TVAC or deployment.
System partition: mechanics vs electronics vs flight software
Most SADA “it jitters / it drifts / it overheats” failures are diagnosed slowly because responsibilities are mixed. A reliable partition turns symptoms into a short list of candidate root causes—and defines what telemetry must exist to prove each hypothesis.
Three-layer partition (who owns what)
- Mechanism: backlash, friction/stiction, end-stop behavior, structural thermal warp. These dominate low-speed micro-motion and repeatability.
- Electronics (this page’s core): PWM/commutation, current regulation, sensing accuracy, protection thresholds, fault containment, and telemetry evidence.
- Control software: motion profiles (slew/settle), limit enforcement, filtering, mode transitions (e.g., safe hold/stow triggers and sequencing).
A useful boundary rule: mechanics explains “load,” electronics explains “how torque is produced and measured,” software explains “how commands become trajectories.”
Measurable vs inferred (what telemetry can and cannot tell you)
- Directly measurable: angle (encoder/resolver), speed (derived), phase/bus current, bus voltage, FET/board/motor temperatures, fault flags.
- Inferred (needs evidence): stiction growth, backlash change, bearing drag, intermittent connector/brush events (if any), lubrication temperature sensitivity.
- Inference needs time alignment: “angle + current + temperature + fault snapshot” captured around events (start, settle, fault, retry).
Symptom-to-cause fast triage (engineering heuristics)
- Jitter increases mainly with temperature: suspect mechanism friction change or sensor front-end drift; verify via current rise and angle lag correlation.
- Ripple locked to PWM frequency: suspect sampling timing, current-sense bandwidth, or dead-time effects; verify with phase-current ripple magnitude.
- Angle error spikes only at mode switches: suspect profile limits or transition logic; electronics must log mode-change markers and pre/post snapshots.
- Overcurrent trips during start only: suspect stiction/end-stop; tune blanking with evidence (peak current, angle movement, temperature).
Goal: reduce “driver instability” guesses. Each statement above requires telemetry that can prove or falsify it.
Motor choice for SADA: stepper vs BLDC in space use-cases
Motor selection in SADA is primarily a control-and-evidence decision: which option can deliver low-speed smoothness, safe holding behavior, and diagnosable telemetry with acceptable sensor dependency.
Quick decision rules (drive-side boundaries)
- Choose stepper + microstepping when ultra-low-speed pointing and micro-motion stability dominate, and a simpler “torque by commanded phase current” model is preferred.
- Choose BLDC + FOC when continuous rotation, efficiency, and lower steady dissipation dominate—and high-quality position feedback is available and monitorable.
- When sensor dependency must be minimized, stepper solutions can tolerate weaker feedback loops, while BLDC solutions typically require reliable position/velocity signals for low-speed smoothness.
- When fault isolation must be decisive, prioritize architectures that can prove outcomes via telemetry (angle + phase current + temperature + fault flags) under each mode.
A useful engineering check: if the design cannot prove “commanded torque produced expected angle change” using telemetry, selection risk remains high regardless of motor type.
Low-speed smoothness (why jitter happens and what the drive can control)
- Stepper microstepping: smoothness depends on how accurately phase currents follow sin/cos targets. Ripple sources include current-chop ripple, quantization, dead-time effects, and sensing bandwidth limits.
- BLDC at very low speed: commutation ripple is dominated by electrical angle accuracy and current-loop behavior. Field-oriented control (FOC) can reduce torque ripple by making phase currents behave like a continuous vector—if feedback quality is maintained.
- Telemetry evidence: low-speed issues should correlate with phase-current ripple, angle micro-oscillation, and temperature rise (dissipation), not only with mechanical hypotheses.
Power-off holding and safe hold (boundary statement)
- Stepper: holding behavior often benefits from intrinsic detent/holding torque, but the “hold” requirement must still be defined and verified (angle drift, power draw, thermal impact).
- BLDC: holding typically needs an explicit strategy (electrical braking/locking or other means). This page does not prescribe the mission policy, but it requires a defined safe state and proof signals.
- Verification focus: “power removed” scenarios must be linked to measurable outcomes (angle retention, fault flags, thermal response before shutdown).
Sensor dependency and diagnosability
- Stepper: can be open-loop or weakly closed-loop, but must detect missed-step risk using consistency checks (commanded current vs observed angle change).
- BLDC: usually depends strongly on position/velocity feedback, especially for low-speed FOC. Loss or corruption of feedback must map to a bounded response (derating or safe state).
- Design outcome: selection should reflect what can be monitored and proven in flight—not only bench performance.
Power stage & gate-drive architecture (what matters, what breaks)
The power stage is where SADA performance becomes measurable: current regulation, sensing fidelity, protection speed, and fault-reporting granularity define both pointing quality and diagnosability under stress.
Stepper stage: dual H-bridge and two-phase current modulation
- Core requirement: phase currents must track microstepping targets; any sensing delay, bandwidth limit, or blanking choice will directly change torque ripple.
- Key observation points: I_phase (A/B), V_bus, and T_fet are the minimum set to prove whether ripple is electrical (PWM/sense) or load-driven (mechanism).
- Failure surfaces: dead-time and chop ripple can create low-speed micro-oscillation; inadequate protection response can turn stiction into thermal runaway.
BLDC stage: three-phase bridge with current sensing trade-offs
- Core requirement: current sensing must support the control mode (FOC or commutation) and must remain trustworthy during PWM switching.
- 1-shunt vs 2-shunt vs 3-shunt: fewer shunts can reduce BOM and simplify routing, but can reduce observability in certain PWM intervals; 3-shunt offers the most complete per-phase evidence for diagnostics.
- Design outcome: choose the sensing topology that can prove phase imbalance, open/short indications, and current-ripple sources using telemetry.
Gate driver and protection criteria (selection checklist)
- Gate-drive capability: enough drive strength for switching loss targets without excessive EMI; stable behavior across temperature.
- Dead-time control: too large increases torque distortion and loss; too small raises shoot-through risk. The setting must be validated with current ripple evidence.
- Protection set: fast OCP/short-circuit response, overtemperature response, and undervoltage lockout (UVLO) behavior that matches safe-state policy.
- Blanking & filtering: prevent false trips while preserving protection speed; tuning must reference start/stiction events.
- Fault granularity: fault flags should distinguish OCP/OT/UVLO and (where possible) phase faults to support root-cause from flight logs.
A practical requirement: protection actions should produce a traceable “why” (fault flag) plus “what happened” (I/T/V snapshot) so flight evidence is actionable.
Current control: microstepping, torque ripple, and EMI trade-offs
“It moves” does not mean “it is stable.” Low-speed jitter, audible whine, and EMI are often the same problem seen through different lenses: phase current is not following the intended waveform, or sampling/update timing injects repeatable errors.
Stepper chain: microstep targets → chopping current loop → torque ripple
- Microstepping target: the drive defines a sin/cos phase-current table so commanded torque changes smoothly with angle.
- Chopping current loop: PWM + current sensing forces phase currents to track the target. Timing choices determine whether the sensed current is “truth” or “switching artifact.”
- Main ripple sources (drive-side): quantization (table/ADC/PWM), dead-time distortion (voltage vector error), and sampling delay or poor synchronization (measuring near switching edges).
- What to prove in telemetry: phase-current ripple should correlate with micro-jitter in angle/velocity and with any temperature rise from switching loss.
BLDC drive-side current control (without control-theory overload)
- Current-loop bandwidth: too low produces lag (torque does not follow), too high amplifies noise and can reduce stability margin. The usable range is set by sensing quality and sampling latency.
- PWM frequency: affects acoustic bands, switching loss, and how much “clean sampling window” exists inside each PWM period.
- Sampling synchronization: sampling must avoid switching transients and must align with the control update point to prevent repeatable torque modulation.
- Low-speed jitter risk: at very low speed, any electrical-angle uncertainty or timing error appears as commutation ripple unless the drive can maintain consistent current vectors.
Practical mitigations (actions that can be verified)
- Trajectory shaping: limit acceleration and jerk so the current loop is not forced into repeated saturation or mode switching during settle.
- Filtering with discipline: apply filtering only where it does not destroy phase margin; validate by checking whether ripple and jitter reduce without new limit cycles.
- Sample/update alignment: place current sampling in the stable region of the PWM cycle and keep the control update at a consistent phase reference.
- Acceptance evidence: reduced I_phase ripple, reduced angle micro-oscillation, fewer false protection trips, and acceptable temperature rise.
Boundary statement: this section explains drive-side causes and knobs; EMC compliance test methods and standards are intentionally out of scope.
Position feedback: encoder vs resolver, and the front-end that decides accuracy
Position feedback is not only a sensor choice; it is a signal-chain choice. The front-end (conditioning, conversion, and fault detection) determines angle noise, drift, and whether feedback failures are detectable before they become motion instability.
Selection boundary (what matters for SADA stability)
- Encoders: digital transitions and link integrity dominate. Jitter, missing edges, and EMI-induced errors can produce angle spikes that directly create low-speed torque modulation.
- Resolvers: excitation + sin/cos analog signals + synchronous demodulation dominate. Amplitude/phase errors and cable effects must be tracked, but fault detection can be engineered explicitly.
- Drive outcome: the best choice is the one that provides stable angle/velocity plus actionable fault flags under the expected EMI, cable, and temperature conditions.
Encoder concerns (drive-side, protocol-agnostic)
- Jitter and edge integrity: timing uncertainty becomes angle noise; repeated micro-noise appears as low-speed jitter and audible artifacts.
- Missing edges / bursts: intermittent loss produces discontinuities that can force protection actions or produce torque steps.
- Evidence to log: angle spike counters, edge-error indicators (if available), and correlation with current peaks and mode transitions.
Boundary statement: interface protocols are not detailed; the focus is on how edge quality and EMI affect angle stability and fault evidence.
Resolver chain (why it is common and what defines accuracy)
- Signal flow: excitation → resolver sin/cos → analog front-end (gain + anti-alias) → ADC → RDC (sync demod) → angle/velocity.
- Accuracy drivers: amplitude imbalance and phase error translate into angle error; temperature drift and cable impedance changes shift amplitude/phase unless monitored.
- Fault detection: amplitude low/high, saturation, loss-of-lock, and phase-error thresholds should generate fault flags usable by the drive’s safe-state logic.
Front-end checklist (what to demand from the chain)
- Input bandwidth + anti-alias: enough margin for excitation and modulation products without passing switching noise into the ADC.
- Noise and dynamic range: supports low angle jitter while keeping headroom for cable-induced amplitude variation.
- Synchronous demod timing: demod reference must be stable; timing mismatch is a direct angle-error generator.
- Fault coverage: open/short indications, saturation detection, amplitude/phase monitors, and loss-of-lock flags.
Health monitoring: what to measure (current, temperature) and what it proves
Telemetry is evidence. Current and temperature are not collected “because they exist,” but because they can prove load state, control stability, thermal stress, and whether anomalies are electrical, mechanical, or sensor-related.
Current features: peak, mean, RMS, and ripple (each implies a different story)
- I_peak: captures transient stress (stiction release, end-stop impact, abrupt load step). Useful for event detection and fast protection validation.
- I_mean: tracks steady load baseline under comparable motion windows. Long-term drift is a strong proxy for friction or load change.
- I_RMS: correlates with heating burden (copper loss + switching loss projection). A better thermal predictor than mean alone when ripple is large.
- I_ripple: indicates current-loop timing/quantization/dead-time artifacts or unstable regulation. Growth in ripple often precedes audible whine and higher EMI risk.
Diagnostic rule: a rising mean suggests load/friction; a rising ripple suggests control/sampling timing or switching artifacts. The corrective action differs.
Temperature points: power devices, windings (or proxy), and board hotspots
- T_fet (power devices): proves switching and conduction stress. A fast rise suggests abnormal loss, insufficient derating, or protection gaps.
- T_coil (winding or proxy): proves copper heating burden and helps validate whether current increases are acceptable or damaging over time.
- T_board hotspot: provides context (environment + heat spreading). Useful to separate “ambient changes” from “device-local stress.”
Evidence logic: for similar current, higher temperature implies worsened thermal path or increased switching loss; for similar temperature, higher current implies load/friction shift.
Derived indicators (proxies that turn measurable signals into health trends)
- Phase resistance proxy: track estimated winding resistance change using current/temperature context during stable windows. Use as a trend indicator, not an absolute truth value.
- Friction trend proxy: compare I_mean under identical speed/acceleration profiles. Drift indicates evolving friction or mechanical load.
- Stiction/end-stop event markers: detect patterns like I_peak spikes + angle/velocity anomalies + rapid temperature slope change.
- Control instability marker: correlate I_ripple growth with angle micro-oscillation and any increase in false protection triggers.
IF / THEN / VERIFY (how to turn telemetry into an actionable diagnosis)
- IF I_mean drifts upward in comparable windows, THEN load/friction baseline likely changed; VERIFY angle tracking remains smooth and T_coil/T_fet slopes remain consistent.
- IF I_ripple increases without a mean increase, THEN timing/dead-time/sampling artifacts are likely; VERIFY correlation with PWM mode changes and angle micro-jitter.
- IF T_fet rises rapidly while current is moderate, THEN switching stress or thermal path degradation is likely; VERIFY duty-cycle conditions and fault-flag history.
Boundary statement: the focus is on evidence and mapping; system-level mission strategy and bus protocols are intentionally out of scope.
Fault protection & safe states: how SADA fails and how it should degrade
The highest-risk outcomes are uncontrolled motion, thermal damage, and non-recoverable lock-up. A robust SADA design uses layered protection: fast hardware protection, deterministic driver actions, and software policies that use evidence (telemetry + fault flags) to enter safe, recoverable states.
Layered protection (from microseconds to mission time)
- Hardware fast protection: overcurrent and overtemperature actions that respond faster than software can. These actions must set readable fault flags.
- Driver-level response: deterministic stop/disable/derate behaviors that prevent repeated stress cycles and preserve the ability to recover.
- Control policy: mode-dependent decisions (hold or stow) triggered by evidence: current/temperature patterns, angle anomalies, and fault flags.
Design intent: prevent “silent failures” by ensuring each protective action produces a traceable “why” (fault flag) plus “what happened” (I/T/V snapshot).
Common faults and how they should degrade (principles)
- Stiction / jam: rising I_mean or repeated I_peak spikes → derate torque/speed, then enter SafeHold if evidence persists.
- Feedback loss or angle jumps: encoder/resolver integrity issues → transition to Degraded (reduced dynamics) and then SafeHold if continuity cannot be proven.
- Power-stage short or severe overcurrent: hardware protection triggers → immediate stop and SafeHold; treat as non-retry until evidence indicates recovery is safe.
- Phase open / imbalance: per-phase current inconsistency → Degraded with limited torque; escalate if heating or instability grows.
- Temperature sensor anomaly: invalid or stuck readings → conservative derating and SafeHold unless alternative evidence supports safe operation.
Safe states (definitions without mission-specific details)
- Normal: full performance within validated limits.
- Degraded: reduced torque, limited speed/acceleration, reduced stress; used when anomalies exist but motion remains controllable and evidence is consistent.
- SafeHold: stop commanded motion and enter a bounded hold behavior that prevents runaway and limits heating.
- Stow: controlled, low-dynamic transition toward a known safe configuration. The page defines the principle, not the mission trajectory.
Anti-oscillation principle: prevent rapid toggling between Normal and Degraded using hysteresis and counters, guided by evidence quality.
Redundancy patterns: A/B channels, cross-strapping, and what to log
Redundancy is not “two copies.” It is isolation + arbitration + interlock + evidence. A/B channels only help if switching is deterministic, prevents back-feed, and produces logs that prove why the system switched and whether the result is safe.
Common SADA redundancy blocks (what is redundant and why)
- A/B drive channels: separate driver/bridge paths so a single channel fault can be isolated without losing control authority.
- Sensor redundancy: dual feedback chains or selectable front-ends so angle integrity can be re-proven after a fault.
- Supply-domain isolation: A and B power domains must prevent energy from one channel feeding the other during faults.
Scope boundary: this section stays within SADA drive/sensing/logging. Vehicle bus protocols and mission-level power architecture are out of scope.
Cross-strapping risks (why “one more wire” can reduce reliability)
- Back-feed: fault energy can return through unintended paths (body diodes, protection structures, shared nodes), causing both channels to misbehave.
- Ground bounce: switching or channel handover can shift references and create false thresholds in comparators, ADCs, or feedback integrity checks.
- False enable: the worst case is dual-drive (both channels simultaneously driving the same motor/phase). Interlock must dominate switching speed.
Design rule: interlock and isolation points are safety primitives; redundancy is built around them, not added on top.
Switching that is “actually usable” (criteria that can be audited)
- Reason code: every switch must carry a cause (OCP/OT, feedback invalid, angle jump, power anomaly, commanded test).
- Evidence snapshot: record pre/post windows of I/T/V, angle/velocity, and fault flags to prove the state transition was justified.
- Attempt counters: track consecutive retries to prevent oscillation and cumulative stress from repeated switching.
- Result verification: after switching, confirm angle stability and reduced abnormal metrics; otherwise escalate to SafeHold/Stow.
Event log fields (what to record so failures are explainable)
- Switch cause: reason code + threshold context (e.g., “T_fet_derate,” “angle_invalid,” “OCP_trip”).
- Protection trace: OCP/OT/UVLO and driver fault flags with timestamps.
- Motion evidence: angle error, angle jump counter, velocity deviation.
- Stability evidence: I_mean / I_peak / I_ripple (or equivalent) and the operating mode state.
- Thermal evidence: T_fet / T_board snapshots and temperature slope around the event.
- Anti-oscillation: retry_count and the active hysteresis/debounce state (principle-level).
Space environment design checklist: radiation, thermal, and lifetime
Designs that “work on the ground” can fail in space due to long-term parameter drift, single-event upsets, constrained thermal paths, and lifetime stress accumulation. This checklist focuses on what matters to SADA drive electronics: observable symptoms and mitigation categories.
Radiation: TID (drift) and SEE (events) — symptoms and mitigation categories
- TID drift (slow): parameter shifts can increase switching loss, change dead-time behavior, and bias ADC/RDC measurements. Symptoms often appear as gradually rising T_fet, changing ripple, or growing angle error.
- SEE events (fast): transient faults can flip configuration bits, create measurement spikes, or trigger abnormal current draw (including latch-like behavior). Symptoms appear as sudden angle jumps, fault-flag bursts, or abnormal I_peak.
- Mitigation categories: derating margins, sanity checks and periodic re-validation, hardened state machines, and evidence-based escalation to safe states.
Boundary statement: the section avoids detailed standards and test procedures; the focus is on drive-side behaviors and robust response categories.
Thermal: heat path, measurement points, and derating logic
- Heat path reality: power devices rely on a constrained conduction path (device → PCB → structure). Thermal headroom is often dominated by interface quality and local hotspots.
- Measure what separates causes: T_fet captures electrical stress; T_board captures environment + spreading; T_coil (or proxy) reflects copper burden.
- Derating tiers (principle): pre-warn → reduced torque/speed → SafeHold. Use hysteresis/counters to avoid oscillation and log each tier transition.
Lifetime: stress accumulation and trend thresholds
- Electrical stress: higher PWM frequency and higher ripple raise switching loss and heat cycling burden; choose operating points with evidence (I_ripple and T_fet stability).
- Thermal cycling: repeated temperature swings accelerate wear-out; track temperature slope and peak statistics, not just steady values.
- Trend thresholds: rising I_mean under identical motion windows suggests friction increase; rising I_ripple suggests timing/control degradation; rising T_fet for the same load suggests thermal path degradation.
- Action principle: trend-triggered Degraded is preferable to abrupt SafeHold; persistent or severe evidence escalates to SafeHold/Stow.
Verification plan: how to prove it works before launch
“Done” must be provable: stable control, correct protection, usable redundancy (no back-feed / no dual-drive), trustworthy telemetry, and logs that allow full post-event reconstruction.
Acceptance is evidence-driven (what “pass” means)
- Stability: angle/velocity follow the commanded profile without unexplained oscillation, drift, or jitter bursts.
- Protection: OCP/OT/UVLO and feedback-invalid paths trigger deterministic stop/derate transitions.
- Redundancy: A/B switching is interlocked, prevents back-feed, and never produces dual-drive conditions.
- Telemetry: current/temperature/angle measurements remain consistent and interpretable across environments.
- Logs: every abnormal event carries a reason code + pre/post snapshots + counters + result verification.
Evidence package requirement: for every test, capture (1) command profile ID, (2) state transitions, (3) I/T/V/angle snapshots,
(4) fault flags, (5) retry counters, and (6) post-switch verification outcome.
Phase 0 — test baseline (make results comparable)
- Define a repeatable profile set: angle sweeps, constant-speed holds, end-stop approach, and load-step sequences.
- Time-aligned logging: angle, I_phase, V_bus, T_fet/T_board, flags, and state must share one timeline.
- Calibration & sanity checks: current-chain and temperature-chain baselines recorded before each major campaign.
Goal: remove ambiguity so “different results” become diagnosable differences, not measurement artifacts.
Functional verification — prove controllability and observability
- Angle accuracy sweep: multi-point moves across the working range; verify angle error stays bounded and angle jumps map to reason codes.
- Speed stability hold: constant-speed segments plus small disturbances; verify stable velocity estimate and controlled I_ripple.
- End-stop handling: approach/stop logic must avoid sustained hard-stall heating; end-stop events must generate complete snapshots.
Stress & fault injection — prove graceful degradation
- Cold start: low-temperature startup and low-speed tracking; verify controlled retry limits and explainable reasons for any derate.
- Hot steady-state: long-run to thermal equilibrium; verify derating tiers are deterministic and non-oscillatory (with hysteresis/counters).
- Load-step disturbance: friction/inertia step equivalents; verify control does not destabilize and I_mean/I_ripple changes remain interpretable.
- Feedback loss injection: resolver/encoder invalid cases; verify safe fallback and no continued “blind drive” under invalid feedback.
Environment evidence — what to measure (without expanding into full system standards)
- TVAC: repeat the same profiles; compare drift in I_mean/I_ripple and temperature deltas (T_fet − T_board) over time.
- Vibration / shock: look for intermittent invalid feedback, sampling discontinuities, bursty flags, and timestamp integrity.
- EMC susceptibility (drive-side): quantify false trips, feedback error counters, and sampling-window consistency under aggressors.
Redundancy acceptance — make H2-9 verifiable
- Fault-triggered A/B switch: provoke OT/OCP/feedback-invalid; verify interlock dominance, no back-feed evidence, and post-switch stability.
- Commanded A/B drill: controlled switchovers; verify “no dual-drive,” capture snapshots, and validate result (angle stable, flags clear).
- Anti-oscillation: enforce retry_count limits and stable state transitions (Normal → Degraded → SafeHold as needed).
Example verification BOM (part numbers for prototype/fixture cross-check)
- Rad-hard gate drivers: Infineon IR HiRel RIC7S113 (high/low-side HV driver) :contentReference[oaicite:0]{index=0}, RIC74424 (dual-channel gate driver) :contentReference[oaicite:1]{index=1}
- Rad-hard GaN half-bridge driver: Renesas ISL73041SEH :contentReference[oaicite:2]{index=2}
- Rad-hard MOSFET examples: IR HiRel IRHNJ67234 :contentReference[oaicite:3]{index=3}, IRHNJ54130 :contentReference[oaicite:4]{index=4}
- Current sense amplifiers: TI INA901-SP :contentReference[oaicite:5]{index=5}, Analog Devices RH6105 :contentReference[oaicite:6]{index=6}
- Precision telemetry ADC (example): TI ADS1278-SP (rad-hardened 24-bit, 8-ch simultaneous) :contentReference[oaicite:7]{index=7}
- Resolver-to-digital (RDC): Frontgrade RDC5028C :contentReference[oaicite:8]{index=8}, DDC Class K RDC-19228S :contentReference[oaicite:9]{index=9}
- Radiation-tolerant MCU: Microchip SAMV71Q21RT :contentReference[oaicite:10]{index=10}
- Remote temperature monitor: TI TMP461-SP :contentReference[oaicite:11]{index=11}
These part numbers are representative examples for verification planning and fixture/BOM cross-check. Final selection depends on mission radiation level, temperature range, screening flow, and power stage ratings.
Verification matrix (human-readable)
Rows are test items; columns are proof points. A checkmark means the test must produce explicit evidence for that column.
| Test item | Stability | Protection | Redundancy | Telemetry | Logs |
|---|---|---|---|---|---|
| Angle accuracy sweep | ✓ | ✓ | ✓ | ||
| Constant-speed hold | ✓ | ✓ | ✓ | ||
| End-stop approach | ✓ | ✓ | ✓ | ✓ | |
| Cold start | ✓ | ✓ | ✓ | ✓ | |
| Hot steady-state run | ✓ | ✓ | ✓ | ||
| Load-step disturbance | ✓ | ✓ | ✓ | ✓ | |
| Feedback loss injection | ✓ | ✓ | ✓ | ✓ | |
| Protection thresholds check | ✓ | ✓ | |||
| A/B switch on fault | ✓ | ✓ | ✓ | ✓ | ✓ |
| Commanded A/B drill | ✓ | ✓ | ✓ | ||
| TVAC evidence run | ✓ | ✓ | ✓ | ||
| Vibration / shock evidence | ✓ | ✓ | ✓ | ||
| EMC susceptibility evidence | ✓ | ✓ | ✓ | ✓ | |
| Long-run trend logging | ✓ | ✓ | ✓ |
Request a Quote
FAQs (SADA drive electronics)
Each answer focuses on actionable evidence: what to measure, what it proves, and where to look next (mapped to H2 sections).
1) Why can stepper microstepping still jitter at very low speed, and how to tell if the cause is the current loop or the mechanism?→ H2-5
Low-speed jitter usually comes from (a) current-loop timing/quantization (PWM dead-time, sampling window, update delay) or (b) stiction/backlash in the mechanism. If the vibration is phase-locked to PWM/updates and repeats with identical electrical conditions, suspect the current loop. If it changes with direction, dwell time, or temperature and shows “stick–slip” bursts in current/angle, suspect stiction trends.
Evidence to log: I_ripple spectrum vs PWM, angle error bursts, repeatability under identical profiles.
2) Why does BLDC show more commutation ripple at ultra-low speed, and what does FOC fix vs not fix?→ H2-5
At ultra-low speed, any mismatch between electrical angle, current sampling, and PWM timing produces visible torque ripple. FOC can reduce ripple when phase currents are measured accurately and updated at the right instants, but it cannot “fix” noisy/invalid angle feedback, poor sampling placement, or dead-time distortion. If ripple grows when sampling windows shift or when angle validity degrades, the limitation is measurement/timing rather than the control concept itself.
Evidence to log: angle validity flags, sampling window alignment, I_phase ripple vs dead-time and update points.
3) Encoder or resolver—what is the practical engineering boundary for SADA applications?→ H2-6
The boundary is defined by robustness and diagnosability. Encoders are strong when the digital link remains clean and low-jitter; resolvers are strong when harsh EMI, long cabling, and wide temperature swings demand analog-domain fault detection and graceful degradation. Choose based on how feedback validity is proven (error counters/flags), how drift is tracked versus temperature, and how the system detects disconnect/saturation without relying on perfect digital integrity.
Evidence to log: invalid-feedback counters, jitter/edge-loss indicators, temperature-correlated angle drift.
4) How do resolver amplitude/phase errors and temperature drift turn into angle error in practice?→ H2-6
Resolver angle is computed from sin/cos signals after excitation, amplification, sampling, and synchronous demodulation. Amplitude imbalance skews the sin/cos ratio, phase shift distorts the demodulation reference, and temperature drift changes gain/offset in the AFE or the resolver itself. The result appears as offset, nonlinearity, or increased jitter—often temperature-correlated. Monitoring sin/cos amplitude ratio, phase consistency, and demodulation quality flags helps separate sensor physics from electronics drift.
Evidence to log: sin/cos amplitude ratio, phase consistency metric, temperature vs angle bias trend.
5) Where should current be sensed—single shunt or phase shunts—and what trade-offs matter most?→ H2-4 / H2-5
Phase shunts give direct per-phase current with simpler timing assumptions, which helps low-speed torque smoothness and precise protection decisions. Single shunt can work but depends on tight sampling windows and current reconstruction, which becomes fragile at low duty cycles, during transients, or when dead-time dominates. The “right” choice is the one that produces consistent I_mean and I_ripple evidence across profiles without driving nuisance trips or hiding real overload conditions.
Evidence to log: sampling coverage, reconstruction error indicators, nuisance-trip rate under the same motion profile.
6) How should overcurrent thresholds be set to avoid nuisance shutdown while still protecting the power stage?→ H2-8
Avoid a single “hard number.” Use a tiered approach: (1) fast hardware trip for catastrophic faults, (2) a controlled current limit or derate for short accelerations, and (3) a safe-state transition if the condition persists or repeats. Thresholds must be derived from measured I_peak distributions during normal worst-case moves and validated with injected faults. Every trip should log reason code plus pre/post snapshots to prove it was justified.
Evidence to log: I_peak histogram by profile, trip timestamps, state transitions, retry_count, snapshots (I/T/V/angle/flags).
7) How can stiction (stick–slip) be detected using current and angle telemetry?→ H2-7 / H2-8
Stiction is a pattern, not a single threshold: rising I_mean or repeated I_peak bursts while angle change stalls or lags the commanded trajectory, often followed by sudden release and an angle jump. Distinguish it from feedback faults by checking whether angle validity stays consistent while torque demand rises. Use counters for repeated stalls, correlate events with temperature, and escalate from Degraded to SafeHold when retries accumulate or heating accelerates.
Evidence to log: stall/angle-error counters, I_mean/I_peak trend, angle validity flags, temperature slope around the event.
8) Where should temperature be measured so it actually helps diagnosis (not just reporting)?→ H2-7 / H2-10
Use temperature points that separate causes: T_fet reflects electrical stress and switching loss, T_board reflects spreading and environment, and a coil proxy (or an equivalent load temperature) reflects copper burden. Diagnosis relies on comparisons under the same motion profile: if T_fet rises faster for the same I_mean, the thermal path or switching loss changed; if temperature rises with unchanged electrical behavior, the environment or conduction path dominates. Log both absolute values and slopes.
Evidence to log: T_fet − T_board delta, temperature slope, profile-matched comparisons across runs.
9) After an A/B redundancy switchover, how can it be proven that the switch was correct, and what must be logged?→ H2-9
A switchover is “correct” only if it is explainable and safe: the reason code matches the observed evidence, interlock prevents dual-drive, isolation prevents back-feed, and post-switch verification confirms stable angle tracking and cleared fault bursts. Logs must include cause, pre/post snapshots (I/T/V/angle/flags), retry_count, and a verification result field (pass/fail) so the system can escalate to SafeHold if the new channel does not restore stable behavior.
Evidence to log: reason code, interlock state, no-back-feed indicator, snapshots, and post-switch stability checks.
10) What are common causes of radiation-related “sporadic angle jumps” or “lockup-like” behavior in SADA electronics?→ H2-10
Typical categories are single-event upsets (bit flips in configuration/state), single-event transients (short spikes in sensing or logic), and latch-like abnormal current draw that forces a reset or shutdown path. Symptoms show up as sudden angle jumps, bursts of fault flags, or abnormal I_peak/T_fet behavior without a mechanical trigger. Mitigation is evidence-driven: sanity checks, hardened state transitions, bounded retries, and prompt degradation to a safe state when the evidence repeats.
Evidence to log: angle jump counter, flag bursts, current/temperature transients, reset/restore records with timestamps.
11) In TVAC, what phenomena are most valuable to monitor and archive for later diagnosis?→ H2-11
TVAC value comes from repeatable, comparable evidence. Run the same motion profiles and compare I_mean and I_ripple drift, angle stability metrics, and the temperature relationship between T_fet and T_board over time. Archive event logs with full timestamps and snapshots so anomalies can be correlated to thermal transitions. The most useful records are profile-matched before/after comparisons, not isolated “pass/fail” notes.
Evidence to log: profile ID, drift vs time, T_fet−T_board trend, and complete event snapshots during transitions.
12) What is usually missing when a system “can rotate” but is not yet “launch-ready” from an acceptance standpoint?→ H2-11
The gap is almost always the evidence package: proof of stability across corners, proof that protections act deterministically, proof that redundancy is truly usable (no back-feed / no dual-drive), and proof that telemetry and logs are trustworthy in environment runs. Launch readiness requires that every checkmark in the verification matrix corresponds to captured data, snapshots, counters, and post-action verification—not only a demo of motion.
Evidence to log: verification-matrix artifacts, raw data extracts, and reconstruction-ready logs for all injected faults and environment runs.
