Set to 200°C but browning is inconsistent: should delta-T or heater conduction strategy be checked first?

First evidence: compare DELTA_T across sensors and capture I_HEATER with ZC_DET/HEATER_EN in the same window. Discriminator: large, persistent DELTA_T suggests airflow/sensor placement; stable DELTA_T with unstable heater current suggests power modulation. First fix: stabilize sampling away from switching edges and verify control resolution. Verify: repeated runs show tighter DELTA_T and more repeatable browning.

Temperature jumps right when heating starts: sampling window issue or ground/reference drift?

First evidence: align SAMPLE_WINDOW against the heater switching edge and capture RAIL_3V3/RAIL_REF simultaneously. Discriminator: a jump that always coincides with switching edges indicates sampling interference; a jump that follows rail/reference movement indicates power/return coupling. First fix: move sampling away from edge windows and harden the reference/return path. Verify: no repeatable step at heat enable.

Steam takes a long time to appear: water path issue or heating chain issue?

First evidence: confirm FLOW_STATE transitions (pump/valve enable to stable flow state) and then check I_STEAM rise with T_STEAM. Discriminator: missing flow transition points to supply/priming; valid flow without I_STEAM/T_STEAM response points to the heater chain. First fix: add a logged priming step and enforce evidence-based timeouts. Verify: latency becomes repeatable across cold starts.

Door is closed but a not-closed alert appears: mechanical, sensor, or EMI injection?

First evidence: inspect DOOR_OPEN/LOCK_POS glitches aligned to heater/steam/motor event markers and capture RAIL_3V3/RAIL_REF during those events. Discriminator: glitches only at high-load edges indicate EMI/power coupling; persistent misreads indicate mechanics or sensor alignment. First fix: debounce with consistency checks and harden the return path at the sensitive input. Verify: zero false alerts across stress cycles.

Oven / Steam Oven: Control, Sensing, Door Lock & Wi-Fi UI

Q: Temperature reads stable but food is undercooked/overcooked: probe location or model compensation?

First evidence: log ADC_RAW_CHx (raw codes) and observe channel recovery during door events and fan changes (FAN_TACH). Discriminator: channel-to-channel transient disagreement indicates non-representative probe placement; coherent movement with poor outcomes suggests compensation/estimation bias. First fix: re-anchor representative sensing points and constrain correction to validated regions. Verify: identical recipes show tighter outcome consistency.

Q: Relay clicks frequently and temperature ripples: resolution limit or poor tuning?

First evidence: record relay on/off cadence and temperature ripple amplitude with a common timebase. Discriminator: very short cycles with large ripple indicate coarse energy quantization; long cycles with overshoot/undershoot indicate tuning and hysteresis choices. First fix: select a cycle length matched to thermal inertia and relay limits, then tune gains around that cadence. Verify: fewer transitions and smaller ripple without longer warmup.

Q: SSR/triac overheats or leaks on: which two waveforms prove it fastest?

First evidence: capture I_HEATER (load current waveform) and the gate/command aligned to ZC_DET. Discriminator: current present when command is off indicates leakage or unintended triggering; missing current when commanded indicates drive/timing faults. First fix: validate zero-cross timing, snubber needs, and drive integrity under load; confirm rail stability at edge events. Verify: commanded conduction matches current half-cycle behavior across repeats.

Q: Steam output swings: false empty-water detection or unstable steam-heater power?

First evidence: log WATER_LEVEL (raw and state) and capture I_STEAM with T_STEAM through the same steam event. Discriminator: WATER_LEVEL state flips during pump/valve transitions indicates sensing disturbance; stable level with unstable I_STEAM indicates power modulation/drive issues. First fix: gate level decisions during noisy windows and stabilize steam power updates. Verify: repeat steam ramps show consistent I_STEAM and no false empty flags.

Q: More dripping or standing water: condensation path or control strategy? How can logs prove it?

First evidence: review DRAIN_LOG timestamps against steam/fan events and track FAN_TACH with DELTA_T recovery after door openings. Discriminator: dripping aligned to airflow changes suggests condensation relocation; dripping aligned to missing/late drain events suggests strategy and timing. First fix: enforce drain actions based on measured conditions and add event-stamped logs. Verify: repeated runs show fewer drip events with consistent drain logs.

Q: Door lock stuck or unlock fails: actuator current or position timing first?

First evidence: capture I_LOCK/V_LOCK during actuation and log LOCK_POS transitions with timestamps. Discriminator: current without position change indicates mechanical jam or weak supply; position toggles without real motion indicates sensor bounce or coupling. First fix: add a stability window before declaring locked/unlocked and log the first interlock that triggers a stop. Verify: high success rate across repeated lock/unlock cycles.

← Back to: Smart Home & Appliances

Key takeaway

A smart oven/steam oven is fundamentally an evidence-driven control system: multi-point temperature sensing and heater/steam power modulation must stay stable under airflow changes, door-lock safety interlocks, and UI/Wi-Fi load. Most “inconsistent cooking” issues can be isolated quickly by aligning sensor raw codes, heater/steam current, rail waveforms, and fault logs within the same time window.

H2-1 · Featured Answer Block (Extractable)

Smart Oven / Steam Oven: What It Is

This block is intentionally compact so search engines can extract a complete, engineering-accurate definition with clear boundaries.

A smart oven/steam oven is a multi-sensor thermal control system that modulates heater power and manages a steam subsystem in closed loop, protected by a door-lock and over-temperature safety chain, while UI and Wi-Fi operate concurrently. It excludes microwave and induction power trains, and typical faults can be isolated via raw sensor codes, drive timing, and event/fault logs.

Sense: sample multiple temperature points (and steam-related signals) with timing designed to avoid power-switching interference.
Decide: compute heater/steam commands per cooking phase using setpoint ramps and safety constraints.
Actuate: drive SSR/triac/relay and pump/valves; monitor current/temperature feedback for stability.
Protect: enforce interlocks (door lock, over-temp, fan failure, dry-fire) and record fault reasons for fast diagnosis.

Figure F0. Minimal overview: sensors → controller → actuators, with a safety chain that can override heater/steam execution at any time.

Cite this figure: ICNavigator — Oven/Steam Oven, Fig F0 (Control Loops Overview), [PAGE URL], accessed [DATE].

H2-2 · System Architecture & Signal Map

Architecture Decomposition into Measurable Signals

The fastest way to debug (and to design for stability) is to map each subsystem to measurable signals and to the user-visible symptoms those signals can prove or disprove.

Design intent: every later chapter must “return” to at least one signal in this map. When a symptom appears (uneven browning, steam delay, door lock errors, random resets), it should be diagnosable with a minimal pair of probes: (1) raw sensor/drive evidence and (2) a timing/log indicator.

Subsystem	Measurable signals (examples)	Common failure symptom
Temperature sensing AFE	Raw ADC codes per sensor (T1…Tn), sample timestamp, reference/offset status	Temperature jumps, drift correlated with heater switching, point-to-point inconsistency
Heater power stage	Zero-cross (ZC), triac/SSR gate timing, relay period, heater current proxy (I_HEAT)	Slow warm-up, overshoot/oscillation, buzzing, intermittent “no heat” or “leak heat”
Steam subsystem	Water level (WL), pump duty/current, valve state, generator current/temp (I_STEAM/T_STEAM)	Steam delay, unstable steam output, false “no water”, dripping/standing water
Door lock & interlocks	Door switch (DOOR_SW), lock position (DL_POS), actuator current, fault latch reason	Lock/unlock failure, false door-open alarm, mid-cycle stop, safety lockout
Airflow & fan	Fan PWM command, tach RPM (FAN_TACH), airflow/damper state (if present)	Uneven cavity temperature, hot spots, repeated over-temp trips during convection modes
UI & Wi-Fi coexistence	Backlight PWM, touch scan activity, Wi-Fi TX events, control-loop jitter, reset cause	Instability during interaction, worse temperature noise when online, random resets/reboots

Spatial physics becomes visible: point-to-point deltas are real cavity gradients, not just noise—fan RPM and door events change the delta dynamics.
Power switching interferes with sensing: triac/SSR transitions can inject noise into ADC references/grounds—sampling windows and routing matter.
Thermal inertia vs control resolution: relay period or coarse power steps can create limit cycles that look like “bad sensors” without timing evidence.
Steam adds a second closed loop: water-level states and dry-fire protection can change thermal response; the coupling must be observable in logs/signals.

Figure F1. System architecture and signal map. Each labeled tag is a candidate “first probe” for evidence-based diagnosis and validation.

Cite this figure: ICNavigator — Oven/Steam Oven, Fig F1 (System Architecture & Signal Map), [PAGE URL], accessed [DATE].

H2-3 · Multi-point Temperature Sensing AFE

Multi-point Temperature Measurement: Accuracy, Dynamics, Wiring

“Temperature mismatch” in an oven is a mixed symptom. It can be real spatial gradient (airflow/thermal mass) or a measurement artifact (ADC reference noise, sampling window, ground bounce, wiring leakage). The fastest path is to separate true ΔT from false ΔT using raw codes, timing, and heater-switch correlation.

First 2 Measurements (minimum probes)

#1 Log T_raw[i] (raw ADC codes per sensor) and T_filt[i] (filtered temperature) with a consistent sample index.
#2 Log heat_state / phase_window (relay period or triac/SSR switching window) to mark the noisy interval.

Two Discriminators (swap tests)

Swap channel: same probe → different ADC channel. If the drift/jump follows the channel, it is AFE/channel/timing.
Swap probe: same channel → different probe. If the drift disappears, it is probe/installation/self-heating.

Evidence pattern to look for: if ΔT_raw spikes only inside the phase_window while ΔT_filt hides it, the control loop may “see” false stability. If ΔT_raw changes with fan RPM/door events, it is more likely a physical gradient.

Error source	How it appears in evidence	Low-risk mitigation
Sensor tolerance	Stable offset between sensors even with heater off; swap-probe changes the offset	Probe binning; per-sensor calibration; specify tighter class where needed
Divider / excitation	Gain error vs temperature; offset varies with supply/reference	Low-TC resistors; ratiometric ADC/reference strategy; stable excitation
ADC reference / ground	Noise/jumps correlated with switching edges (phase_window); swap-channel follows channel	Move sample window; RC/LPF at ADC; reference decoupling; ground return control
Wire resistance / leakage	Slow drift with humidity/condensation; offsets differ by harness length	Twisted pair; shielding where needed; guarding/cleaning; connector sealing
Self-heating	Probe reads higher during steady sampling; heater-off vs heater-on baseline differs	Lower excitation; duty-cycled sampling; thermal coupling improvements

Figure F2. Timing concept: label the switching “noisy window” and keep temperature sampling windows outside it to reduce false ΔT.

Cite this figure: ICNavigator — Oven/Steam Oven, Fig F2 (Sampling Window vs Switching), [PAGE URL], accessed [DATE].

H2-4 · Heater Power Stage Control

Heater Power Modulation: Relay vs SSR vs Triac

Heater “weak heat”, overshoot, buzzing, or short relay life are rarely explained by one parameter. Evidence must separate control resolution vs thermal inertia from drive-path abnormality (missing conduction or leak conduction), using the command timing (HEAT_CMD), zero-cross (ZC), and a current/power proxy (I_HEAT).

First 2 Measurements (minimum probes)

#1 Capture HEAT_CMD (relay period, SSR enable, or triac phase angle) aligned to ZC when available.
#2 Capture I_HEAT (heater current proxy) to verify “command → real power”. Without I_HEAT, faults look identical.

Three fast discriminators

Cmd changes but I_HEAT does not: drive path / device / wiring issue.
Cmd and I_HEAT match but temp oscillates: resolution/period vs thermal inertia (limit cycle).
Cmd OFF but I_HEAT remains: leak conduction / SSR triac failure mode.

Relay period control: coarse power steps can create temperature limit cycles; relay life is tied to switching count.
SSR zero-cross control: lower EMI than phase control but still quantized by half-cycles; verify off-state leakage with I_HEAT.
Triac phase control: fine resolution but higher edge-related interference; sampling windows (H2-3) must avoid phase edges.

Method	What to log	Evidence-driven diagnosis clue
Relay (period)	Relay ON/OFF timestamps, period, temperature response	Oscillation frequency matches period → resolution vs thermal inertia; reduce period or add dithering/ramp
SSR (zero-cross)	Enable windows, ZC alignment, I_HEAT at OFF	I_HEAT persists when OFF → leakage/failure; I_HEAT missing when ON → drive path interruption
Triac (phase)	ZC jitter, firing delay, phase angle, I_HEAT waveform	Temp noise spikes at edges → sampling window/grounding; phase jitter → ZC detect or timing instability

Figure F3. Simplified view of three modulation strategies. Use the same evidence trio (ZC, HEAT_CMD, I_HEAT) to validate “command → power”.

Cite this figure: ICNavigator — Oven/Steam Oven, Fig F3 (Heater Modulation Strategies), [PAGE URL], accessed [DATE].

H2-5 · Steam Subsystem Control

Steam Generation & Water Path: Closed-Loop Control and Protection

Steam issues (delay, unstable output, dripping/condensation, “no-water” false trips) are resolved only when the steam loop is treated as an evidence-driven closed loop: water availability + generator power + protection chain + condense/drain behavior. The goal is to separate “water not reaching the generator” from “power not converting to steam” and from “protection limiting output”.

First 2 Measurements (minimum probes)

#1 Water-side evidence: log WL/FLOW (level/flow state or raw code) with PUMP_CMD and VALVE_STATE.
#2 Generation-side evidence: log I_STEAM (generator current/power proxy) with T_STEAM (generator temperature / over-temp switch).

Three-way Evidence Chain (time-aligned)

WL/FLOW timeline + I_STEAM/T_STEAM timeline + DRAIN_LOG timeline (condense/drain actions). If timestamps do not align, root cause cannot be proven.

Fast discriminators:
• WL OK + PUMP_CMD ON but FLOW weak → water path restriction, valve/hose blockage, or return-path interference.
• FLOW OK but I_STEAM low/interrupts → power-stage limitation, drive fault, or protection limiting output.
• I_STEAM high + T_STEAM rising fast → dry-fire / water not wetting the heater surface; protection should latch with a clear reason code.

Symptom bucket	What evidence should show	Typical isolation decision
Steam delay / weak steam	FLOW ramp vs I_STEAM ramp; time-to-first-steam proxy from I_STEAM/T_STEAM behavior	FLOW missing → water path; I_STEAM missing → power/drive; protection early → dry-fire
Unstable steam output	I_STEAM oscillation, WL/FLOW toggling, frequent protection entries	WL toggles → sensing/return-path; I_STEAM toggles → control limiting or drive intermittency
Dripping / pooling	DRAIN_LOG frequency, valve states, and cavity/drain events aligned to steam phases	DRAIN_LOG present but water persists → drain path restriction; no drain actions → strategy/trigger conditions
No-water false trips	WL/FLOW disagree with physical state; trip reason repeats in log under specific phases	Return-path / noise injection / condensation affecting sensing; add consistency checks across WL/FLOW/I_STEAM

Figure F4. Steam loop evidence map. Align WL/FLOW, I_STEAM/T_STEAM, and DRAIN_LOG on the same timeline to prove water-path vs power-path vs protection causes.

Cite this figure: ICNavigator — Oven/Steam Oven, Fig F4 (Steam Closed Loop), [PAGE URL], accessed [DATE].

H2-6 · Airflow, Fan & Cavity Uniformity

Fan, Ducting, and Cavity Uniformity: Verifiable Causes of Uneven Browning

“Same setpoint, uneven browning” is usually a controllable airflow + temperature-gradient problem. The correct approach is to treat cavity uniformity as an evidence relationship between FAN_TACH, ΔT(t) (multi-point temperature spread), and door events (recovery after opening). This separates real airflow/duct issues from sensing artifacts and drive instability.

First 2 Measurements (minimum probes)

#1 Log FAN_TACH (RPM from tach) with FAN_CMD (PWM/drive command) and mode markers.
#2 Log ΔT(t) using multi-point temperatures (T1..Tn) and mark door_event timestamps to extract recovery curves.

Two Key Discriminators

Tach stable but ΔT large: duct/damper geometry or sensor placement dominates (real gradient).
Tach jitter + ΔT jitter: fan drive supply/EMI/control-period coupling; investigate drive timing and power integrity.

Uniformity metrics: ΔT_peak (worst spread), ΔT_recover (door-open recovery time), RPM_stability (tach ripple).
Control clue: if ΔT oscillation frequency matches fan control period, the issue is likely in scheduling/drive timing rather than ducting.
Cross-check: if ΔT spikes align only with heater switching edges, revisit sampling windows (H2-3) and power modulation edges (H2-4).

Figure F5. Evidence layout for cavity uniformity. Align FAN_TACH with multi-point ΔT(t) and door-event recovery to isolate duct/placement vs drive instability.

Cite this figure: ICNavigator — Oven/Steam Oven, Fig F5 (Airflow & Uniformity Evidence), [PAGE URL], accessed [DATE].

H2-7 · Door Lock & Safety Interlock Chain

Door Lock, Interlocks, and Safety State Machine (Evidence-Based)

Door-lock failures (“stuck lock”, “door not closed false alarm”, “mid-run stop”) must be diagnosed as a safety chain event, not as a UI warning. The interlock chain is a hard constraint: once an unsafe condition is detected, heater and steam outputs must be cut and the system must log a reason code that can be proven with sensor timing and actuator electrical evidence.

First 2 Measurements (minimum probes)

#1 Position timing: log LOCK_POS (A/B if available) and DOOR_OPEN on the same timeline as the event.
#2 Actuator electrical: log I_LOCK and V_LOCK (or a supply/line-drop proxy) during lock/unlock attempts.
Required log: FAULT_CODE + LATCH_REASON for every stop/lockout.

Safety State Machine (minimal, enforceable)

BOOT_SELFTEST → IDLE_UNLOCKED → LOCK_REQUEST → LOCK_VERIFY → RUN_SAFE
Any safety input triggers FAULT_LATCH (cut outputs) then RECOVERY_GUARD (only allowed conditions can clear).

Fast discriminators:
• I_LOCK present but LOCK_POS no change → jam / weak actuator / supply sag (check V_LOCK).
• LOCK_POS toggles briefly (without door motion) → sensor bounce / wiring transient / debounce window mismatch.
• Mid-run stop with stable LOCK_POS → another interlock input (OverTemp/FanFail/DryFire) must be shown by LATCH_REASON.

Observed symptom	Evidence signature to confirm	Isolation / next action
Lock “stuck”	I_LOCK rises but LOCK_POS stays unchanged; V_LOCK droops under load	Actuator torque margin, mechanical friction, wiring/connector drop; require retry policy with logging
Door not closed false alarm	DOOR_OPEN toggles near fan/heater edges; LOCK_POS remains stable	Debounce consistency window; sensor placement; harness routing; ensure FAULT_CODE includes which input fired
Mid-run stop	LATCH_REASON shows which interlock input (OverTemp/FanFail/DryFire/etc.) fired first	Prove causality by ordering: input timing → cut outputs → alarm; never rely on UI-only trace
Cannot recover	Fault remains latched until recovery conditions satisfied; repeated re-trips have same reason	Define recovery guard rails; disallow automatic recovery for irreversible events (e.g., thermal fuse)

Figure F6. Door lock and safety chain must be provable: LOCK_POS/DOOR_OPEN timing + I_LOCK/V_LOCK + FAULT_CODE/LATCH_REASON.

Cite this figure: ICNavigator — Oven/Steam Oven, Fig F6 (Door Lock & Interlocks), [PAGE URL], accessed [DATE].

H2-8 · UI, Touch/Display & Tasking Impacts

UI Is Not “Just UI”: Power Ripple and Control-Loop Jitter Effects

Touch scanning, display refresh, and backlight PWM can disturb control stability through two coupling paths: electrical coupling (power ripple/ground bounce affecting ADC/reference) and time coupling (task preemption increasing control-loop jitter). The correct diagnosis requires jitter statistics and correlation to temperature ripple, not visual impressions.

First 2 Measurements (minimum probes)

#1 Control timing: log CTRL_DT and compute jitter_p95 / jitter_p99 for the temperature/steam control loop.
#2 UI activity marker: log BL_PWM (backlight PWM) and/or UI_REFRESH markers (frame/update events).
Correlate both against T(t) or ΔT(t) (multi-point spread).

Two Discriminators (electrical vs time coupling)

T ripple aligns with BL_PWM edges: power/ground coupling into sensing or references.
T ripple aligns with jitter_p99 spikes: scheduling/tasking interference shifting sample/PWM update windows.

Engineering rule of thumb: if UI activity increases and jitter_p99 rises while temperature ripple grows, the control loop is being disturbed by task preemption. If ripple appears even when timing is stable but aligns to BL_PWM, the dominant path is electrical coupling.

UI-related symptom	Evidence to collect	Most likely coupling path
Touch false triggers	Touch scan marker vs rail ripple vs heater switching windows	Electrical coupling + ground noise
Display flicker / backlight noise	BL_PWM frequency/edges vs temperature raw-code noise	Electrical coupling into AFE/ADC reference
UI stall causes temperature drift	CTRL_DT jitter stats + task runtime spikes + temperature oscillation	Time coupling (preemption / jitter)

Figure F7. UI activity can disturb control stability through power ripple (BL_PWM edges) and scheduling jitter (CTRL_DT). Correlate both to T(t)/ΔT(t).

Cite this figure: ICNavigator — Oven/Steam Oven, Fig F7 (UI/Tasking Coupling), [PAGE URL], accessed [DATE].

H2-9 · Wi-Fi / Connectivity Coexistence

Wi-Fi Coexistence: RF Activity → Measurement and Control Impacts

Connectivity issues that appear “network-related” often originate on the device: RF activity can inject transient load on rails and disturb ADC references, and RF tasking can shift sampling/update windows. The correct approach is to prove a minimum causal chain inside the oven: TX/scan/rejoin markers → ADC noise / temperature jumps → drop logs or reset cause.

First 2 Measurements (minimum evidence)

#1 RF activity markers: log TX_EVENT_CNT, TX_PWR_STATE, and SCAN/REJOIN events.
#2 Measurement stability: log ADC_NOISE (raw-code variance/pp) and T_JUMP events in the same window.
Required: DROP_LOG (disconnect/rejoin reason) and RESET_CAUSE (brownout/WD/etc.).

Key discriminator (avoid blaming the router first)

If “worse when connected” coincides with rail impedance / sampling window / ground return evidence (ADC_NOISE or T_JUMP aligned to TX/scan), the dominant root cause is device-side coupling—not Wi-Fi infrastructure.

Fast discriminators:
• TX/scan aligned with ADC_NOISE↑ and T_JUMP↑ → electrical coupling into sensing/reference (power/ground path).
• TX/scan aligned with CTRL_DT jitter spikes (from control timing stats) → scheduling coupling (sample/update drift).
• RESET_CAUSE = brownout/UVLO near RF peaks → rail dip is the first suspect.

Connectivity symptom	What evidence should show	Most likely device-side cause
Frequent disconnect/rejoin	DROP_LOG aligned to TX_PWR_STATE transitions; occasional rail dip or reset cause	RF rail transient + marginal supply impedance / ground return
Remote control “unstable”	Command latency bursts coincide with CTRL timing jitter and UI/RF activity	Scheduling coupling (preemption) shifting control windows
After OTA: more resets / drift	RESET_CAUSE shifts (WD/hardfault) or jitter stats worsen under RF activity	Device-side runtime load change (timing/memory), not cloud behavior

Figure F8. Device-side coexistence proof: TX/scan events can couple into rails or timing, producing ADC noise, temperature jumps, drops, or resets.

Cite this figure: ICNavigator — Oven/Steam Oven, Fig F8 (Wi-Fi Coexistence Evidence), [PAGE URL], accessed [DATE].

H2-10 · Power Tree & Ruggedness (Oven-specific)

Power Tree and Ruggedness: Why Heater/Steam/Motors Trigger Resets and Drift

Resets, sensor drift, and UI flicker often share a single root: large load transients (heater edges, steam start, motor start) cause rail dips and ground bounce, or expose insufficient isolation between logic and drive domains. This chapter treats ruggedness as evidence: rail waveforms + reset cause + ADC reference/raw-code stability, aligned to event markers.

Minimum Evidence Pack (must align in time)

#1 Rail waveforms: capture key rails during power-up, heater switching, steam start, motor start.
#2 RESET_CAUSE: brownout/UVLO vs watchdog/hardfault determines priority (power vs firmware load).
#3 ADC_REF / ADC_RAW: show reference drift or raw-code noise changes during the same events.

Most sensitive oven events

Heater edge (SSR/triac switching), Steam start (generator + pump/valve stack), Motor start (fan/pump tach ramp). Each event must be tagged in logs so rail and ADC evidence can be aligned.

Observed behavior	Primary evidence to confirm	Typical isolation direction
MCU reset on switching	MCU rail dip coincident with heater/steam/motor event; RESET_CAUSE=brownout	Supply impedance, inrush, sequencing; separate drive domain from logic
Temperature “drifts” under load	ADC_REF drift or raw-code noise increases during high-current events	Ground return and reference integrity; sampling window vs switching edges
UI flicker / touch issues	UI/BL rail ripple during drive events; BL PWM interacts with rail dip	Domain isolation and decoupling; avoid sharing noisy return paths

Ruggedness rule: any claim about resets/drift/flicker must point to at least one of the three proofs: rail waveform, reset cause, or ADC reference/raw stability—aligned to a named event (heater edge / steam start / motor start).

Figure F9. Oven power tree by domain. Tag heater/steam/motor events and align rail waveforms with reset cause and ADC reference/raw stability.

Cite this figure: ICNavigator — Oven/Steam Oven, Fig F9 (Power Tree & Ruggedness), [PAGE URL], accessed [DATE].

H2-11 · Validation & Field Debug Playbook (SOP)

Validation & Field Debug SOP: Symptom → Evidence → Isolate → Fix → Verify

This playbook turns the page into an actionable field procedure. Each SOP entry is constrained to two fast measurements, a hard discriminator, a first fix, and a measurable pass criterion. Every entry back-links to evidence points introduced in H2-2 to H2-10.

Minimal toolkit (fastest path to proof)

• 2–4 channel scope (or data logger) for rail + event alignment
• Current probe or shunt readback for heater/steam/lock/motor load signatures
• Firmware logs aligned by timestamp: RESET_CAUSE, FAULT_CODE/LATCH_REASON, CTRL_DT, TX_EVENT, ADC_RAW/ADC_NOISE, plus key events (heater edge / steam start / motor start).

Validation mindset

Any claim must point to one of three proofs aligned to a named event: rail waveform, reset/safety reason, or ADC/raw stability. Visual impressions (UI alerts, “seems like Wi-Fi”, “feels random”) are not pass criteria.

Top symptom	Back-link (evidence chapter)	Primary evidence tags
S1. Temperature mismatch across cavity	H2-3, H2-6	ADC_RAW_CHx, ADC_NOISE, DELTA_T, FAN_TACH
S2. Overshoot / oscillation	H2-4, H2-3	HEATER_EN, ZC_DET, I_HEATER, SAMPLE_WINDOW
S3. Slow heating / cannot reach setpoint	H2-4	I_HEATER, HEATER_EN, ZC_DET, PHASE/SSR_MODE
S4. Steam delayed / unstable output	H2-5	WATER_LEVEL, FLOW_STATE, I_STEAM, T_STEAM
S5. Water empty false alarm / dripping	H2-5	WATER_LEVEL, DRAIN_LOG, PUMP/VLV_EN, CONDENSE
S6. Door lock failure / mid-run stop	H2-7	LOCK_POS, DOOR_OPEN, I_LOCK, LATCH_REASON
S7. UI freeze / flicker affects temperature	H2-8	CTRL_DT, UI_REFRESH, BL_PWM, ADC_NOISE
S8. Connected mode worsens stability / OTA anomalies	H2-9	TX_EVENT, DROP_LOG, RESET_CAUSE, ADC_NOISE
S9. Reset when heater/steam/motor starts	H2-10	RAIL_WAVEFORM, RESET_CAUSE, ADC_REF/RAW, EVENT_MARK

Figure F10. Reusable SOP template: two measurements + discriminator + first fix + pass criteria, always aligned to event markers and reason codes.

Cite this figure: ICNavigator — Oven/Steam Oven, Fig F10 (Field Debug SOP Template), [PAGE URL], accessed [DATE].

S1 — Temperature mismatch across cavity (same setpoint, uneven browning)

First 2 measurements

#1 Log ADC_RAW_CHx for all temperature channels (raw code, not filtered) during steady heating.
#2 Log FAN_TACH and compute DELTA_T (max-min across sensors) vs time.

Discriminator

If DELTA_T tracks FAN_TACH changes or door events, airflow/cavity mixing dominates (H2-6).
If DELTA_T persists with stable fan speed and raw codes show channel-dependent bias, sensing/AFE dominates (H2-3).

First fix

• Validate sensor mounting and harness routing; isolate “channel vs probe” by swapping probes across channels (no calibration changes).
• If electrical noise appears on raw codes, tighten sampling window away from switching edges.

Verify pass criteria

• DELTA_T reduces and remains stable over a full bake cycle under identical load conditions.
• Raw-code noise and bias remain consistent after channel/probe swap test.

MPN examples (relevant blocks): ADC / multi-sensor AFE: ADS124S08 (TI), ADS1220 (TI), AD7124-4 (ADI) · Reference: ADR4525 (ADI) · Analog mux (if used): ADG704 (ADI), TS5A3359 (TI)

ADC_RAW_CHxADC_NOISEDELTA_TFAN_TACH Back-link: H2-3 / H2-6

S2 — Overshoot / oscillation (temperature hunts around setpoint)

First 2 measurements

#1 Capture HEATER_EN with ZC_DET (zero-cross) and I_HEATER (or shunt proxy) in the same window.
#2 Log raw temperature sample timing (SAMPLE_WINDOW) vs heater switching edges.

Discriminator

If temperature ripple aligns with switching edges and raw codes spike near turn-on/turn-off, sampling-window interference dominates (H2-3).
If switching waveform is clean but duty/phase updates are coarse or delayed, control resolution/strategy dominates (H2-4).

First fix

• Move sampling away from the highest dV/dt moments; freeze filter update during edge windows if needed.
• If using relay cycle control, reduce cycle length only within relay lifetime constraints; if using phase/SSR, validate resolution and update cadence.

Verify pass criteria

• Peak overshoot drops and oscillation amplitude decreases across repeated runs under identical ambient/load.
• Raw-code spikes near switching edges are reduced or eliminated.

MPN examples (heater control & sensing): Zero-cross opto: H11AA1 (Vishay) · Optotriac: MOC3063 (on/off zero-cross), MOC3052 (phase-capable) · Triac: BTA16-600 (ST) · Current sense: INA240 (TI), ACS712 (Allegro)

HEATER_ENZC_DETI_HEATERSAMPLE_WINDOW Back-link: H2-4 / H2-3

S3 — Slow heating / cannot reach setpoint

First 2 measurements

#1 Measure I_HEATER vs commanded mode (PHASE/SSR_MODE) across a full duty range.
#2 Verify ZC_DET integrity and HEATER gate signal timing against the mains period.

Discriminator

If gate commands change but heater current remains low or missing, power stage conduction is failing (device or wiring).
If heater current is correct but temperature rise is slow, thermal coupling/airflow dominates (hand off to H2-6 evidence).

First fix

• Validate SSR/triac conduction under load; check gate drive amplitude and timing around zero-cross.
• Validate relay contact behavior with cycle control; avoid overly short cycles for mechanical relays.

Verify pass criteria

• Heater current matches expected power command across modes; setpoint reach time improves repeatably.
• No missing half-cycles or unexpected conduction gaps on current waveform.

MPN examples (switching devices): SSR (module class): G3MB-202P (Omron, small-load), D2425 (Sensata/Crydom, higher-load class) · Triac: BTA24-600 (ST) · Relay (power class): G5Q (Omron)

I_HEATERPHASE/SSR_MODEZC_DETHEATER_EN Back-link: H2-4

S4 — Steam delayed / unstable output

First 2 measurements

#1 Log WATER_LEVEL/FLOW_STATE and pump/valve enables during steam start.
#2 Capture I_STEAM and T_STEAM (steam generator current + local temperature) during ramp.

Discriminator

If water flow states are correct but I_STEAM is missing/low, steam heater power stage dominates.
If I_STEAM is normal but steam response is delayed, water delivery/priming or cavity airflow dominates (cross-check with H2-6 evidence).

First fix

• Add a priming step with logged timing; ensure flow state transitions are debounced and time-stamped.
• If dry-fire protection is triggering, confirm the protection threshold uses a stable sensor window and not switching-noise artifacts.

Verify pass criteria

• Steam start latency becomes repeatable; I_STEAM ramp and T_STEAM rise show stable closed-loop behavior.
• No dry-fire or empty-water events during validated fill conditions.

MPN examples (pump/valve/steam sensing): DC motor driver: DRV8871 (TI), DRV8833 (TI) · Solenoid driver array: ULN2003A (TI/ST) · Capacitive level sensing (example): AD7746 (ADI)

WATER_LEVELFLOW_STATEI_STEAMT_STEAM Back-link: H2-5

S5 — Water empty false alarm / dripping / drain anomalies

First 2 measurements

#1 Record WATER_LEVEL raw signal (not only state) through pump/valve transitions; log DRAIN_LOG events.
#2 Capture pump/valve drive edges and any level-sense disturbance during those edges.

Discriminator

If “empty” triggers only during pump/valve edges, the dominant failure mode is sensing disturbance / return-path coupling.
If “empty” persists during steady state with stable edges, the dominant failure mode is sensor wetting/installation or real supply issue.

First fix

• Gate the level decision during high-noise windows; require persistence over a stable observation window.
• Improve drive/sense separation (return path and harness routing); ensure drain events are logged with timestamps.

Verify pass criteria

• False “empty” triggers disappear across repeated pump/valve switching sequences.
• Level raw signal remains bounded during drive edges; drain behavior matches expected logs.

MPN examples (level/drive protection class): TVS (example families): SMF5.0A, SMBJ5.0A · ESD (example): PESD5V0S1UL (Nexperia) · Solenoid/motor driver: DRV8876 (TI), A4950 (Allegro)

WATER_LEVELDRAIN_LOGPUMP/VLV_ENCONDENSE Back-link: H2-5

S6 — Door lock failure / “door not closed” false alarm / mid-run stop

First 2 measurements

#1 Log LOCK_POS and DOOR_OPEN transitions with timestamps around lock/unlock attempts.
#2 Capture I_LOCK and V_LOCK during actuation; record LATCH_REASON when a stop occurs.

Discriminator

If I_LOCK rises but LOCK_POS never changes, mechanical jam/weak drive/supply droop dominates.
If LOCK_POS toggles without physical action (especially near other loads), sensor bounce or coupling dominates.

First fix

• Add a strict verify window: LOCK_POS must remain stable for a defined time before RUN_SAFE is entered.
• Debounce DOOR_OPEN/LOCK_POS with consistency checks; ensure LATCH_REASON always identifies the first interlock input that fired.

Verify pass criteria

• Lock success rate is repeatable; no mid-run stops without a clear LATCH_REASON aligned to an interlock input.
• Sensor timing is stable under heater/steam/fan events.

MPN examples (lock actuator & sensing): Motor driver: DRV8871 (TI), TB6612FNG (Toshiba) · Hall switch: DRV5032 (TI), A3144 (Allegro) · Microswitch (class): V-15 series (Omron)

LOCK_POSDOOR_OPENI_LOCKLATCH_REASON Back-link: H2-7 (Fig F6)

S7 — UI freeze / flicker / touch anomalies affect temperature stability

First 2 measurements

#1 Log CTRL_DT jitter statistics (p95/p99) during UI activity and during a quiet baseline.
#2 Log BL_PWM and UI_REFRESH markers and correlate with ADC_NOISE or temperature ripple.

Discriminator

If temperature ripple aligns to BL_PWM edges with stable CTRL_DT, electrical coupling dominates.
If ripple aligns to CTRL_DT p99 spikes, scheduling coupling dominates (sample/update drift).

First fix

• Protect the control loop with a deterministic timing window; throttle UI refresh during critical control windows.
• If backlight PWM injects noise, adjust PWM placement and power routing; measure improvement in ADC_NOISE correlation.

Verify pass criteria

• CTRL_DT jitter tail (p99) returns to baseline; temperature ripple reduces under the same UI load pattern.
• UI flicker/touch errors no longer correlate with control instability.

MPN examples (UI-related power & touch/display): Backlight driver: TPS61169 (TI), MP3202 (MPS) · Touch controller (example): AT42QT1070 (Microchip), CAP1206 (Microchip) · Display controller (example): ST7789, SSD1306

CTRL_DTUI_REFRESHBL_PWMADC_NOISE Back-link: H2-8 (Fig F7)

S8 — Connected mode worsens stability / disconnects / OTA introduces anomalies

First 2 measurements

#1 Log TX_EVENT, TX_PWR_STATE, and DROP_LOG during the instability window.
#2 Log ADC_NOISE/T_JUMP and RESET_CAUSE in the same aligned timeline.

Discriminator

If ADC_NOISE/T_JUMP rises near TX events, device-side coupling dominates (power/ground or sampling window).
If RESET_CAUSE shifts to watchdog/hardfault after OTA with increased runtime load, timing/memory pressure dominates (device-side).

First fix

• Separate RF burst timing from critical sampling/update windows; add RF-aware “quiet windows” for sensing and control updates.
• Validate RF power domain decoupling and measure rail dip during TX peaks; reduce correlation between TX_EVENT and ADC_NOISE.

Verify pass criteria

• Drop/rejoin rate decreases; TX_EVENT no longer aligns with ADC_NOISE spikes.
• RESET_CAUSE no longer indicates brownout during TX peaks; OTA version maintains stable CTRL_DT stats.

MPN examples (Wi-Fi + power support): Wi-Fi SoC/module (example class): ESP32-WROOM-32, ESP32-C3 (Espressif) · Buck regulator: TPS62130 (TI), MP1584 (MPS) · LDO (quiet rail): TPS7A02 (TI), MIC5504 (Microchip)

TX_EVENTDROP_LOGRESET_CAUSEADC_NOISE Back-link: H2-9 (Fig F8)

S9 — Reset when heater/steam/motor starts (or UI browns out / flickers)

First 2 measurements

#1 Capture RAIL_WAVEFORM on MCU_3V3 and the most coupled domain (RF_VDD or UI/BL) at the exact event marker (heater edge / steam start / motor start).
#2 Record RESET_CAUSE and any pre-reset brownout flag; compare to the rail dip depth and duration.

Discriminator

If RESET_CAUSE indicates brownout/UVLO and rail dips coincide with the event marker, ruggedness/isolation dominates (power tree).
If rail is stable but reset is watchdog/hardfault, scheduling/firmware fault dominates (handoff to H2-8/H2-9 evidence).

First fix

• Reduce event inrush coupling (soft-start, sequencing, separation of drive domain return path).
• Add event-tagged logs for heater/steam/motor so future captures always align to the same moment.

Verify pass criteria

• Rail dip no longer crosses reset threshold during repeated event triggers; reset count remains zero across stress cycles.
• ADC reference/raw stability does not degrade during those same events.

MPN examples (power entry & regulation, background only): Flyback controller: UCC28740 (TI), NCP1342 (onsemi) · PFC controller (background): L6562 (ST) · TVS (AC/DC side examples): SMBJ series · Supervisor (reset/brownout class): TPS3808 (TI)

RAIL_WAVEFORMRESET_CAUSEEVENT_MARKADC_REF/RAW Back-link: H2-10 (Fig F9)

MPN note: The part numbers above are concrete examples commonly used in these functional blocks. Final selection must match mains region, heater power rating, safety isolation needs, and thermal environment.

Request a Quote

Name

Company

Part Number(s) / BOM

Quantity & Target Lead Time

Alternates Allowed

Temperature Grade

Package / Footprint

Compliance

Budget Window

Lot Size / Qty

Message

Attachment

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

H2-12 · FAQs ×12 (Evidence-based)

FAQs: Fast Diagnosis Questions That Always Fall Back to Evidence

Each answer is constrained to: First evidence (two quickest probes/logs) → Discriminator → First fix → Verify. Answers stay inside this page’s oven/steam-oven evidence chain and do not expand to cloud/app tutorials.

FAQ1
FAQ2
FAQ3
FAQ4
FAQ5
FAQ6
FAQ7
FAQ8
FAQ9
FAQ10
FAQ11
FAQ12

Figure F11. FAQ evidence map: each question is answerable via a minimal set of device-side probes and logs (no cloud/app steps).

Cite this figure: ICNavigator — Oven/Steam Oven, Fig F11 (FAQ Evidence Map), [PAGE URL], accessed [DATE].

FAQ1 — Set to 200°C but browning is inconsistent: delta-T or heater conduction strategy first?

First evidence: compare DELTA_T across sensors and capture I_HEATER with ZC_DET/HEATER_EN during the same window. Discriminator: large, persistent DELTA_T points to airflow/sensor placement; stable DELTA_T with unstable heater current points to power modulation. First fix: stabilize sampling away from switching edges and verify control resolution. Verify: repeat runs show tighter DELTA_T and repeatable browning.

Back-link: H2-3 / H2-4 / H2-6 Tags: DELTA_TI_HEATERZC_DET

FAQ2 — Temperature reads stable but food is undercooked/overcooked: probe location or model compensation?

First evidence: log ADC_RAW_CHx (raw codes) and observe how each channel responds to door events and fan changes (FAN_TACH). Discriminator: if channels disagree on transient recovery, the probe is not representative; if all probes move coherently yet outcomes differ, compensation/estimation bias is likely. First fix: re-anchor representative sensing points and limit model correction to validated regions. Verify: identical recipes show tighter outcome spread.

Back-link: H2-3 / H2-6 Tags: ADC_RAW_CHxFAN_TACHDoor-event recovery

FAQ3 — Temperature “jumps” right when heating starts: sampling window or ground/ reference drift?

First evidence: align SAMPLE_WINDOW against the heater edge (relay/SSR/triac) and capture RAIL_3V3/RAIL_REF simultaneously. Discriminator: a jump that always coincides with switching edges points to sampling interference; a jump that tracks rail/reference movement points to power/return coupling. First fix: move sampling away from edge windows and harden the reference/return path. Verify: no repeatable step at heat enable.

Back-link: H2-3 / H2-10 Tags: SAMPLE_WINDOWRAIL_REFHEATER_EDGE

FAQ4 — Relay “clicks” frequently and temperature ripples: resolution limit or bad tuning?

First evidence: record relay cadence (on/off timestamps) and the temperature ripple amplitude at the same timebase. Discriminator: very short cycles with large ripple indicate coarse energy quantization; long cycles with overshoot/undershoot indicate tuning and hysteresis choices. First fix: choose a cycle length that matches thermal inertia and relay limits, then tune gains around that fixed cadence. Verify: fewer transitions and smaller ripple without longer warmup.

Back-link: H2-4 Tags: RELAY_CADENCET_RIPPLECONTROL_RESOLUTION

FAQ5 — SSR/triac overheats or “leaks on”: which two waveforms prove it fastest?

First evidence: capture I_HEATER (load current waveform) and the gate/command aligned to ZC_DET. Discriminator: current present when command is off indicates leakage or unintended triggering; missing current when commanded indicates gate/drive/timing faults. First fix: validate zero-cross timing, snubber needs, and drive integrity under load; check rail stability during edge events. Verify: commanded conduction matches current half-cycle behavior across repeats.

Back-link: H2-4 / H2-10 Tags: I_HEATERZC_DETGATE_CMD

FAQ6 — Steam output swings: false “empty water” or unstable steam-heater power?

First evidence: log WATER_LEVEL (raw + state) and capture I_STEAM with T_STEAM through the same steam event. Discriminator: WATER_LEVEL state flips during pump/valve transitions indicates sensing disturbance; stable level with unstable I_STEAM indicates power modulation/drive issues. First fix: gate level decisions during noisy windows and stabilize steam power updates. Verify: repeat steam ramps show consistent I_STEAM and no false empty flags.

Back-link: H2-5 / H2-10 Tags: WATER_LEVELI_STEAMT_STEAM

FAQ7 — Steam takes a long time to appear: water path or heating chain first?

First evidence: confirm FLOW_STATE transitions (pump/valve enable → stable flow state) and then check I_STEAM rise with T_STEAM. Discriminator: no valid flow transition means supply/priming; valid flow but no I_STEAM/T_STEAM response means heater chain. First fix: add a logged priming step and enforce timeouts tied to evidence, not assumptions. Verify: latency becomes repeatable across cold starts.

Back-link: H2-5 Tags: FLOW_STATEI_STEAMT_STEAM

FAQ8 — More dripping/standing water: condensation path or control strategy? Prove via logs.

First evidence: review DRAIN_LOG timestamps against steam/fan events and track FAN_TACH with DELTA_T recovery after door openings. Discriminator: dripping aligned to airflow changes suggests condensation relocation; dripping aligned to missing/late drain events suggests strategy and timing. First fix: enforce drain actions based on measured conditions and add event-stamped logs. Verify: repeated runs show fewer drip events with consistent drain logs.

Back-link: H2-5 / H2-6 Tags: DRAIN_LOGFAN_TACHDELTA_T

FAQ9 — Door lock stuck / unlock fails: actuator current or position timing first?

First evidence: capture I_LOCK/V_LOCK during actuation and log LOCK_POS transitions with timestamps. Discriminator: current without position change indicates mechanical jam or weak supply; position toggles without real motion indicates sensor bounce or coupling. First fix: add a stability window before declaring locked/unlocked and log the first interlock that triggers a stop. Verify: high success rate across repeated lock/unlock cycles.

Back-link: H2-7 Tags: I_LOCKLOCK_POSLATCH_REASON

FAQ10 — Door is closed but “not closed” alert appears: mechanical, sensor, or EMI injection?

First evidence: inspect DOOR_OPEN/LOCK_POS glitches aligned to heater/steam/motor event markers, and capture RAIL_3V3/RAIL_REF during those events. Discriminator: glitches that only occur at high-load edges point to EMI/power coupling; persistent misreads point to mechanics or sensor alignment. First fix: debounce with consistency checks and harden the return path at the sensitive input. Verify: zero false alerts across stress cycles.

Back-link: H2-7 / H2-10 Tags: DOOR_OPENRAIL_REFEVENT_MARK

FAQ11 — Touch/display actions increase temperature ripple: task preemption or backlight PWM noise?

First evidence: compute CTRL_DT jitter (p95/p99) during UI activity and correlate BL_PWM edges with ADC_NOISE. Discriminator: ripple aligned to CTRL_DT spikes is scheduling coupling; ripple aligned to PWM edges is electrical injection. First fix: protect control timing windows and adjust PWM placement/power routing; re-measure correlation. Verify: jitter tail returns to baseline and ripple shrinks under the same UI pattern.

Back-link: H2-8 / H2-10 Tags: CTRL_DTBL_PWMADC_NOISE

FAQ12 — After Wi-Fi connects, temperature drifts or random resets occur: which rails and which log first?

First evidence: capture RF_VDD and MCU_3V3 rails during TX_EVENT bursts and read RESET_CAUSE plus drop/rejoin logs. Discriminator: rail dips aligned to TX bursts indicate coupling/impedance; watchdog/hardfault patterns indicate timing/memory pressure on the device. First fix: add RF-aware quiet windows for sensing/control and strengthen RF rail decoupling/return path. Verify: no resets and reduced noise correlation during TX peaks.

Back-link: H2-9 / H2-10 Tags: RF_VDDTX_EVENTRESET_CAUSE

Oven / Steam Oven: Control, Sensing, Door Lock & Wi-Fi UI

Oven / Steam Oven: Control, Sensing, Door Lock & Wi-Fi UI

Smart Oven / Steam Oven: What It Is

Architecture Decomposition into Measurable Signals

Multi-point Temperature Measurement: Accuracy, Dynamics, Wiring

First 2 Measurements (minimum probes)

Two Discriminators (swap tests)

Heater Power Modulation: Relay vs SSR vs Triac

First 2 Measurements (minimum probes)

Three fast discriminators

Steam Generation & Water Path: Closed-Loop Control and Protection

First 2 Measurements (minimum probes)

Three-way Evidence Chain (time-aligned)

Fan, Ducting, and Cavity Uniformity: Verifiable Causes of Uneven Browning

First 2 Measurements (minimum probes)

Two Key Discriminators

Door Lock, Interlocks, and Safety State Machine (Evidence-Based)

First 2 Measurements (minimum probes)

Safety State Machine (minimal, enforceable)

UI Is Not “Just UI”: Power Ripple and Control-Loop Jitter Effects

First 2 Measurements (minimum probes)

Two Discriminators (electrical vs time coupling)

Wi-Fi Coexistence: RF Activity → Measurement and Control Impacts

First 2 Measurements (minimum evidence)

Key discriminator (avoid blaming the router first)

Power Tree and Ruggedness: Why Heater/Steam/Motors Trigger Resets and Drift

Minimum Evidence Pack (must align in time)

Most sensitive oven events

Validation & Field Debug SOP: Symptom → Evidence → Isolate → Fix → Verify

Minimal toolkit (fastest path to proof)

Validation mindset

S1 — Temperature mismatch across cavity (same setpoint, uneven browning)

First 2 measurements

Discriminator

First fix

Verify pass criteria

S2 — Overshoot / oscillation (temperature hunts around setpoint)

First 2 measurements

Discriminator

First fix

Verify pass criteria

S3 — Slow heating / cannot reach setpoint

First 2 measurements

Discriminator

First fix

Verify pass criteria

S4 — Steam delayed / unstable output

First 2 measurements

Discriminator

First fix

Verify pass criteria

S5 — Water empty false alarm / dripping / drain anomalies

First 2 measurements

Discriminator

First fix

Verify pass criteria

S6 — Door lock failure / “door not closed” false alarm / mid-run stop

First 2 measurements

Discriminator

First fix

Verify pass criteria

S7 — UI freeze / flicker / touch anomalies affect temperature stability

First 2 measurements

Discriminator

First fix

Verify pass criteria

S8 — Connected mode worsens stability / disconnects / OTA introduces anomalies

First 2 measurements

Discriminator

First fix

Verify pass criteria

S9 — Reset when heater/steam/motor starts (or UI browns out / flickers)

First 2 measurements

Discriminator

First fix

Verify pass criteria

Recommended topics you might also need

Request a Quote

Accepted Formats

Attachment