Boundary contract (what this page owns)

Only the doorbell/intercom device: capture → process → encode → transmit, plus local sensing, local security, and power integrity.

• In-scope blocks: image sensor/ISP/SoC, mic AFE & codec, speaker amp, Wi-Fi or Ethernet PHY, PoE PD + power tree, PIR/radar wake, secure boot & secure storage, ESD/surge paths.
• Out-of-scope: cloud backend, subscriptions, app UX, NVR/VMS storage architecture, smart-home automation tutorials, gateway protocol-stack deep dives.

Three deployment forms (drives the constraints)

The same “doorbell” behaves like different products depending on power+network entry.

• Wi-Fi doorbell: RF coexistence + ultra-low standby + enclosure detuning are primary risks.
• Ethernet intercom: long-cable common-mode + ESD/surge + PHY diagnostics are primary risks.
• PoE intercom: PD inrush/handshake + isolated power tree + surge return paths are primary risks.

Device-side closed loop (the measurable lifecycle)

Every chapter later must map back to this loop and its acceptance metrics.

• Power-on → rail settle, reset reason clean
• Network join → link/RSSI stable, retries bounded
• Standby → lowest current while keeping required keep-alives
• Trigger → PIR/radar IRQ → first frame/audio within target latency
• Record / talk → bitrate/FPS stable, audio duplex stable
• Report → event log preserved across dips/reboots

Acceptance metrics (evidence carriers)

Write requirements as “numbers + the first instrument/log to trust”.

• Standby power: current waveform (60s window) + wake reason counters.
• Trigger latency: IRQ-to-encode timestamp using GPIO marker + local logs.
• Stream stability: FPS jitter, bitrate transient, drop/retry counters (device-side).
• Reboot rate: reset-reason taxonomy + rail dip events (brownout/UVLO/WDT/OTP).

Common language for the whole page

All later troubleshooting and design choices must land on: which path (video/audio/sensing), which interface, which rail, and which evidence.

• Signal paths: sensor/codec/radar outputs → SoC/MCU processing → network/speaker/event log.
• Interfaces: MIPI CSI-2, I2S/PDM, GPIO IRQ/Wake, Ethernet PHY+magnetics, Wi-Fi RF, PoE PD.
• Power domains: high-energy entry → conversion → “quiet rails” for sensor/audio/RF.

Power domains (why “quality issues” are often power issues)

Doorbells mix sensitive analog/RF with switching power and Class-D audio. Isolation is not optional.

• High-energy: PoE 48V, primary switching, inrush events, surge return paths.
• Digital core: SoC/DDR/encoder bursts causing load steps.
• Quiet analog/RF: sensor analog, codec references, radar front-end, Wi-Fi PA/LNA rails.

Failure injection map (typical coupling mechanisms)

Use this list to avoid “software blame” and instead isolate the first physical cause.

• PoE transient → rail dip → reset / stream drop: prove with PD status + rail waveform + reset reason.
• Ripple/noisy return → ISP noise floor rises: prove with sensor dark-frame noise vs rail ripple correlation.
• Class-D return / ground bounce → mic clips: prove with mic input saturation aligned with speaker PWM bursts.
• Radar bursts / buck harmonics → Wi-Fi desense: prove with RSSI/retry spikes aligned with radar TX or buck switching.

Architecture-to-metrics mapping (keep it measurable)

Each block exists to protect one of the four acceptance metrics defined in H2-1.

• Standby power: wake sources, keep-alives, PD MPS behavior.
• Trigger latency: IRQ routing, buffer readiness, first-frame pipeline depth.
• Stream stability: encoder bursts, network retries, rail headroom under load steps.
• Reboot rate: UVLO/WDT/OTP taxonomy + event log retention.

Start from four measurable buckets (avoid “tuning-only” explanations)

Doorbell image quality is isolated by mapping symptoms to measurable buckets, then back to sensor/ISP/power/thermal causes.

• Noise floor (SNR): dark-frame noise, fixed-pattern noise, banding, “night grain”.
• Temporal stability: FPS jitter, exposure jumps, motion blur, HDR merge artifacts.
• Link integrity: MIPI errors, intermittent frame drops, “rare” corruption.
• Thermal drift: black-level shift, hot noise rise, color drift under steady scene.

Sensor selection (doorbell constraints, not generic camera theory)

Selection should be driven by low-light + HDR scenes at the doorstep, plus stable black level under temperature rise.

• Low-light: pixel size / QE → sets the minimum usable exposure and gain before noise floor dominates.
• HDR/WDR: improves backlit face capture but may introduce motion artifacts if merge conditions are weak.
• Rolling vs global: mention only when fast motion causes skew/blur under low shutter speed constraints.
• IR mode readiness: IR sensitivity and black-level stability influence night consistency.

MIPI CSI-2 + clock/EMI (symptom → evidence → isolate)

High-speed issues are treated as a correlation problem: when do errors spike, and what switched at that moment.

• Symptoms: rare corruption, brief “snow”, intermittent drops, sudden bitrate/FPS fallback.
• Evidence: MIPI error counters, frame CRC stats, SoC receiver logs, repeat rate vs events.
• Isolation cues: error spikes aligned with IR LED enable, PoE load steps, or Ethernet common-mode events.
• First physical suspects: clock jitter injection, rail ripple on sensor/PHY references, near-field EMI coupling.

ISP stages that matter (doorbell “failure modes”)

Keep focus on the typical doorstep failures, and tie each to measurable evidence rather than subjective “looks bad”.

• AE: backlit faces → exposure oscillation or insufficient dynamic range (verify by exposure step history).
• AWB: mixed lighting / IR assist → color temperature jumps (verify per-channel gain jumps).
• NR: night “smear” → detail loss without real SNR gain (verify edge detail vs noise floor).
• HDR merge: ghosting/tearing → frame-to-frame misalignment (verify artifact rate vs motion).

IR-cut & IR LED ripple injection (common real-world root cause)

Night noise often tracks power integrity: pulsed IR LED current can lift the sensor/ISP noise floor through ripple and ground bounce.

• Injection path: IR LED pulse → rail ripple/return bounce → sensor analog/ref → noise/banding.
• Evidence pairing: IR LED current waveform aligned with dark-frame noise statistics.
• First fixes: dedicated rail, tightened return loop, decoupling placement, switching-frequency avoidance.

Evidence checklist (how to measure, not just what to name)

Use small, repeatable measurements to classify issues before changing ISP parameters.

• SNR/noise floor: dark-frame test; compare IR on/off and load-step conditions.
• FPS jitter: encoder frame timestamp variance; correlate with retries/CPU load/rail headroom.
• Bandwidth use: bitrate curve + I-frame interval; verify if instability is encoder-side or transport-side.
• Thermal drift: black-level/noise vs time (0/10/20 min) under a fixed scene and fixed rails.

Two dominant paths (separate first, then fix)

Intercom complaints are isolated by determining whether the dominant loop is mechanical (air path) or electrical (return/ripple coupling).

• Mechanical path: speaker output re-enters the mic through the enclosure and openings → echo/howl.
• Electrical path: Class-D current pulses and ground bounce inject into mic AFE/codec references → clipping/noise.
• Goal: a single measurement set must classify the dominant loop before DSP settings are changed.

Mic AFE / codec (gain, saturation, and noise floor)

Microphone interface choice sets the diagnostic entry point; clipping must be proven by waveform and full-scale indicators.

• Interfaces: PDM, I2S, or analog mic; each has different “where to probe” points.
• Gain & headroom: near-field speech can saturate earlier than expected when references are noisy.
• Evidence: mic waveform pre/post codec, digital full-scale flags, and baseline noise floor.

Speaker amp (Class-D EMI, return path, and enclosure resonance)

Class-D amplifiers combine high di/dt switching with large return currents; both EMI and ground bounce can dominate perceived “audio quality”.

• EMI coupling: speaker traces and wiring radiate; near-field coupling can hit mic lines and codec clocks.
• Return-path coupling: current pulses lift local ground reference → mic/codec sees pseudo-signal.
• Mechanical resonance: cavity and vent structure can create narrow-band howl even with clean electronics.

AEC / NS / AGC (hardware prerequisites only)

DSP can only work within hardware limits: stable reference, bounded latency, and controlled duplex conditions.

• AEC reference: requires a clean, time-aligned playback reference signal.
• Latency budget: excessive buffering breaks echo cancellation in duplex talk.
• Full-duplex limits: high acoustic coupling or strong electrical injection can exceed cancellation headroom.

Minimal evidence set (first 2 measurements)

Use two synchronized measurements to classify the dominant loop quickly.

• Probe A: mic waveform (analog front-end or codec output).
• Probe B: amp rail/return noise or amp current pulses.
• Classifier: if mic clipping aligns with PWM/current bursts → electrical loop; if it tracks geometry/foam/ports → mechanical loop.

First-fix directions (tie to the classified loop)

Fix actions should match the proven dominant path instead of blending structural and DSP changes blindly.

• Electrical-dominant: tighten return loops, isolate rails, improve decoupling placement, control switching edges.
• Mechanical-dominant: reposition mic, add damping/foam, change vent geometry, separate speaker/mic cavities.
• Regression proof: reduced mic saturation events and lower echo residue under fixed test stimulus.

Three mechanisms explain most “mystery” PoE failures

PoE doorbell issues usually collapse into three measurable mechanisms. Identify which one dominates before changing downstream settings.

• Handshake/MPS: PD state edges and maintain-power signature failures → disconnect/reconnect loops.
• Inrush/load-step: startup surge or event bursts (IR / Wi-Fi TX / encode / audio) → rail dips under brownout.
• Noise coupling: noisy switch/return paths inject into quiet rails → image noise floor, audio clipping, RF desense.

af/at/bt: budget is not the hard part—transients are

Average watts rarely predict field stability. The design must survive short, repeatable bursts without crossing UVLO/brownout limits.

• Burst sources: IR LED enable, encoder rate step, Wi-Fi TX peaks, speaker amp bursts.
• Design target: rail dip + recovery time stays within reset-free headroom.
• Evidence: input V/I waveform aligned to “event start” timestamps.

PD controller: classification → inrush → MPS → reconnect

PD logic is a state machine. Stability depends on how the port enters power, how it limits surge, and how it stays valid under light load.

• Classification & startup: confirm stable entry and clean ramp into the primary converter.
• Inrush control: peak, slope, and duration decide whether the PSE current limit is hit.
• MPS maintenance: low-power standby can violate the maintain signature if not designed intentionally.
• Reconnect behavior: brownout recovery must be deterministic (no endless loops, no partial boots).

Isolated DC/DC + secondary rails: quiet vs noisy must be explicit

Isolation does not guarantee “quiet”. The secondary side still carries switching ripple and return currents that can pollute sensitive domains.

• Noisy rails: high di/dt bucks, IR LED driver rail, speaker amp rail, bulk load rails.
• Quiet rails: image sensor analog/ref, audio codec ref, RF/PLL rails, radar front-end rails (if present).
• Rule: the return loop of burst loads must not traverse quiet references.

Protection & surge paths: focus on current return, not part lists

TVS and filtering only work if surge current returns to a controlled reference. Uncontrolled returns turn protection into injection.

• Port-side stress: ESD/EFT/surge on RJ45 can disturb PD and secondary rails through reference shifts.
• DM vs CM: separate differential disturbance from common-mode reference motion.
• After-event checks: leakage/impedance shift and link instability often signal partial damage.

Minimal evidence set (the smallest measurement pack)

Use a repeatable set of probes to avoid guessing. These signals classify the failure mechanism quickly.

• Probe 1: Vport/Iport waveform across classification, inrush, MPS, and events.
• Probe 2: three rails: core rail, burst-load rail, and a quiet reference rail.
• Probe 3: brownout threshold + reset reason counters (prove “rail dip” vs “software”).
• Probe 4: recovery time (power loss → first stable stream / link-up).

Wired issues are usually physical-layer evidence problems

Long cables, surge events, and common-mode disturbance often look like “network problems”, but PHY counters and return paths close the loop.

• Link flap: repeated up/down indicates a PHY edge condition or damage signature.
• Common-mode: reference motion can disturb PoE, encoding stability, and even reset behavior.
• Post-surge drift: “still links but unstable” frequently points to leakage or impedance shift.

PHY selection: choose features that enable diagnosis

Selection should prioritize observability and robustness, not protocol features. Diagnostics must survive field events.

• ESD robustness: sets survival margin under real port abuse.
• Drop diagnostics: counters and status snapshots for link down reasons.
• EEE compatibility: treat as a boundary condition; verify with long cables and burst loads.

Magnetics & common-mode: coupling is the hidden root cause

Common-mode energy can traverse magnetics references and PoE center-tap structures, then disturb rails and clocks indirectly.

• Sources: surge, cable discharge, ground potential differences, switching converters.
• Symptoms: link instability + correlated resets or stream drops during bursts.
• Evidence: link counters aligned with PoE events and measured common-mode current.

Port protection: the key question is “where does the current return?”

TVS and chokes must steer energy to a controlled reference. Poor grounding turns protection into injection.

• RJ45 TVS: clamp to chassis/shield reference intentionally; avoid dragging surge into quiet logic ground.
• CMC placement: controls common-mode propagation; verify with link stability under stress.
• Shield strategy: keep chassis/shield and digital ground boundaries explicit and testable.

Minimal evidence set (wired stability closure)

A small set of counters and probes can prove whether the wired path is the trigger or a secondary symptom.

• Probe 1: link flap counters + timestamped events.
• Probe 2: PHY status registers captured immediately after a flap.
• Probe 3: common-mode current (clamp) during surge/burst tests.
• Probe 4: post-event leakage/impedance checks if instability persists.

Classifier: avoid misattributing “network” symptoms

Use correlation logic to avoid guessing and to prevent repeated, non-causal changes.

• If link flaps align with PoE load steps or rail dips → prioritize return paths and port protection.
• If flaps occur without power events but after ESD/surge → suspect leakage/impedance shift on the port.
• Fix success: reduced flap rate and stable PHY counters under the same stress profile.

Classify Wi-Fi drops into three measurable mechanisms

Most field failures map to antenna detune, RF desense from noise coupling, or in-device coexistence interference. Classify first.

• Detune: metal enclosure/door frame/hand proximity reshapes matching and radiation pattern.
• Desense: switching ripple and return-path noise lift the RF noise floor (RSSI can look “OK”).
• Coexistence: radar/IR/encode bursts correlate with retry spikes and MCS drops.

Antenna choice and placement under doorbell constraints

Focus on tolerance to metal proximity and predictable ground reference. Keep the antenna feed and keep-out area stable.

• Types: FPC / ceramic / PCB antennas each react differently to nearby metal and hand loading.
• Placement: separate from shield cans and high di/dt zones; preserve a clean ground reference boundary.
• Validation: compare “free-space vs hand/door-frame” with the same AP and distance.

Power noise → RF desense: a coupling problem, not “software”

Switching harmonics and shared return loops can inject into RF rails and references, causing retries and throughput collapse.

• Risk: buck frequency/harmonics near 2.4G/5G or coupling into RF rail/PLL reference paths.
• Symptoms: MCS downgrade, Tx power back-off, retry rate spikes, latency jitter.
• Proof: align retry/MCS timeline with RF-rail ripple or burst-load events.

Coexistence with mmWave radar (hardware-only view)

If a mmWave radar exists, treat it as a high-energy RF source: isolation, shielding, and controlled switching boundaries matter.

• Isolation: separate radar supply/ground return from Wi-Fi front-end references.
• Shielding: avoid openings that couple radar energy into Wi-Fi feed/ground.
• Correlation: radar on/off should not cause synchronized retry or Tx-power changes.

Minimal evidence set (fastest closure)

A small repeatable logging set avoids misattribution. “RSSI only” is insufficient for desense cases.

• Wireless metrics: RSSI + MCS + Tx power + retry rate (timestamped).
• Power metrics: RF rail ripple and reference stability during burst events.
• Posture controls: hand proximity, metal door frame distance, mounting angle A/B.
• Trigger alignment: radar/IR/encode/audio bursts aligned to metrics timeline.

Classifier: detune vs desense in one pass

Use correlation logic to separate geometry from noise coupling without guessing or changing firmware behavior first.

• If hand/metal proximity shifts RSSI/MCS consistently → detune dominates.
• If RSSI is stable but retries spike during bursts → desense dominates.
• Fix success: lower retry rate under the same posture and burst profile.

Turn “false trigger” into three reproducible root-cause classes

Most complaints collapse into physics of sensing, installation geometry, or trigger strategy boundaries. Evidence separates them quickly.

• Sensor physics: PIR thermal drift/noise vs radar reflection/multipath.
• Geometry: angle/height/metal corridor creates multipath or hot-air artifacts.
• Strategy: edge fusion inputs/outputs and timing rules (hardware-visible only).

PIR chain: FOV, lens, threshold, temperature drift

PIR errors often track lens FOV edges, ambient thermal changes, and threshold drift. Treat the PIR output as a time-series signal.

• FOV/lens: edge zones and nearby hot airflow can cause spurious crossings.
• Temp drift: stable in lab, unstable at doorways due to gradients and sun/wind.
• Proof: raw amplitude around trigger + temperature and supply context.

mmWave radar: angle and multipath dominate in metal doorways

Radar sees reflections and multipath. In metal-heavy entries, installation angle can create “ghost targets” or missed detections.

• Angle: main lobe hitting floor/door frame changes detection statistics.
• Multipath: corridor reflections can appear as motion behind walls/doors.
• Proof: raw detection/energy/score vs angle A/B and environmental conditions.

Trigger strategy (edge-only): define inputs, outputs, and verification

Keep the strategy hardware-visible: which sensor fires wake, when video starts, and when network send occurs. No cloud logic required.

• Inputs: PIR, radar, optional video motion, optional door contact.
• Outputs: wake, record start, notification send, local alarm.
• Verification: event timeline pinpoints “who fired first” and “who went unstable”.

Minimal evidence set (trigger closure)

Capture the two seconds around a trigger. This enables classification of false positives, false negatives, and delay regressions.

• Window: -2s to +2s raw PIR + raw radar + thresholds.
• Context: temperature and key supply events (rail dips, burst loads).
• System: video start timestamp and network send timestamp.

Classifier: false vs missed vs delay (fast pass)

Use timeline-based criteria to avoid debating “accuracy” without ground truth.

• False positive: sensor crosses threshold without sustained corroboration in timeline.
• Missed: video indicates motion but sensor never crosses, or crosses too late.
• Fix success: reduced false triggers and improved lead-time under same conditions.

System boundary: secure the device against physical access

A doorbell is physically reachable. The fastest path to compromise is usually debug access, key exposure in storage, or rollback.

• Entry points: SWD/JTAG/UART pads, boot straps, test headers, exposed metal ring/button ESD-induced faults.
• Assets: device identity keys, firmware integrity, encrypted event evidence, privacy-sensitive media metadata.
• Failure mode: “boots but untrusted” is worse than “won’t boot”.

Secure boot chain: ROM → verify → partitions

Define an unbroken chain of trust. Each stage must refuse unsigned code and record measurable version/identity evidence.

• BootROM: immutable root of trust and public key anchor.
• Verify stages: first loader → OS/RTOS → app partitions (signed).
• A/B + rollback index: update safety without allowing downgrade to vulnerable images.

Secure element / TPM: keys must be non-exportable

Key vault hardware prevents private key extraction even if external flash is dumped. Use it for device identity and signing.

• Key storage: private keys never appear in readable external memory.
• Use paths: TLS key protection or signature operations (device identity).
• Debug policy: production locks must be enforceable and verifiable (fuse/lock state).

Encrypted storage + event evidence: survive power loss

Doorway incidents often include brownout or forced resets. Evidence must persist: reset reasons and last events cannot vanish.

• Encryption: bind storage keys to secure hardware (SE/TPM) where possible.
• Event log ring: small, consistent writes with sequence counters reduce “silent loss”.
• Reset reason: store brownout/watchdog/crash classification for post-mortem closure.

Evidence checklist (minimum verification pack)

Security becomes actionable when every claim is tied to a device-side measurement or a reproducible test.

• Boot measurement: capture boot stage versions/hashes (where available) and verify failure behavior.
• Anti-rollback: attempt downgrade; confirm refusal or safe recovery path.
• Debug lock: probe pads in production state; confirm locked and lock state is readable.
• Power-loss evidence: forced brownout; confirm events and reset reasons persist.

Privacy by design (device-side only)

Keep privacy controls anchored to hardware: key isolation, encrypted evidence, and restricted debug paths. Avoid relying on app-only trust.

• Minimize exposure: keep sensitive identifiers out of readable flash regions.
• Controlled access: service modes must not bypass secure boot or export secrets.
• Forensics-safe: logs should be tamper-evident or at least loss-detectable.

Doorway constraint: long wires + mixed grounds + exposed metal

Doorbells combine long cable exposure (PoE/Ethernet) with human-contact ESD points and high di/dt sources inside the unit.

• External entries: RJ45/PoE, exposed button/metal ring, optional USB/service port.
• Internal sources: buck switching, Class-D edges, Ethernet common-mode events.
• Dominant risk: wrong return path injects stress into logic/RF/video references.

Port-by-port protection is about current path, not part count

Every port needs a defined clamp and a defined return reference. A protector that returns to the wrong plane becomes an injector.

• RJ45: TVS + CMC choices must keep surge/ESD currents out of logic ground.
• Button/metal ring: direct ESD entry requires a short, low-impedance return path.
• USB (if any): ESD is fast; keep the clamp and return path tight and local.

Conducted vs radiated: map symptoms back to sources

Doorbell failures often present as “video speckle”, “audio crackle”, or “Wi-Fi retries”. These map to distinct coupling paths.

• Class-D edges: can corrupt mic/codec references through shared returns.
• Buck/PoE harmonics: can desense Wi-Fi or raise ISP noise floor.
• Ethernet common-mode: can trigger link flap and cross-domain stability issues.

Surge reality: grounding mismatch is the hidden multiplier

Lightning seasons and long runs create large common-mode excursions. The design must tolerate reference shifts without injecting into core rails.

• Path control: keep surge energy returning to chassis/shield where intended.
• Boundary clarity: define chassis/shield ground vs digital ground interface.
• After-stress drift: soft faults (sporadic) often mean degraded clamps or leakage shifts.

Evidence-first debug: identify which rail drops first

Stop guessing. Use fault statistics and rail evidence to locate the first failing domain after ESD/EFT/surge stress.

• Fault stats: reboot / freeze / video artifacts / audio distortion / link flap categories.
• Rail dip: capture which rail dips first and how long recovery takes.
• Counters: link flap counters and reset reasons correlate symptoms to domains.

Minimal validation pack (doorbell-focused)

Use a minimal set of stresses that match real doorway exposure and record comparable evidence each run.

• ESD contact: button area, metal ring, near-RJ45 region (repeatable points).
• EFT: long-wire bursts; observe link flap and reboot correlation.
• Surge: line-to-line / line-to-ground as applicable; record post-event drift.
• Logging: rail dip + reset reason + link counters stored as persistent evidence.

SoC / ISP (video encode + device networking)

• 3 hard specs: (1) hardware encode capability (resolution/FPS) (2) memory bandwidth headroom under peak encode (3) power/thermal envelope for sealed doorway housings.
• Common pitfall: peak encode current step causes core rail dip → “random reboot” or video artifacts that look like sensor issues.
• Example MPNs: NXP i.MX 8M Plus (i.MX8MPLUS), NXP i.MX 8M Mini (i.MX8MM), Rockchip RK3566, Rockchip RK3568, Allwinner V853, SigmaStar SSD20X series.

Image Sensor (low-light + HDR/WDR)

• 3 hard specs: (1) low-light noise floor (pixel size/sensitivity trend) (2) HDR/WDR mode support (3) MIPI CSI-2 lane count and data rate margin.
• Common pitfall: IR LED driver ripple/return coupling lifts the sensor noise floor → “night speckle” blamed on ISP.
• Example MPNs: Sony IMX327, Sony IMX335, Sony IMX291, OmniVision OS04A10, OmniVision OS05A10, GalaxyCore GC4653.

Audio Codec / Mic AFE / Class-D Amp (intercom)

• 3 hard specs: (1) mic interface (PDM/I2S/analog) (2) input headroom/noise floor vs required acoustic range (3) EMI behavior of class-D output stage.
• Common pitfall: class-D return and switching edges inject into mic/codec reference → clipping, howl, or speech dropouts.
• Example MPNs: TI TLV320AIC3204, TI TLV320AIC3104, Cirrus Logic CS47L35, NXP SGTL5000, TI TPA2012D2, TI TPA3110D2.

PoE PD + Isolation + Secondary Bucks/PMIC (power tree)

• 3 hard specs: (1) PD inrush/MPS behavior control (2) isolation stage transient margin for boot peaks (3) rail partitioning: noisy vs quiet domains.
• Common pitfall: PD/MPS oscillation or insufficient hold-up causes periodic reboot loops that mimic firmware crashes.
• Example MPNs: TI TPS2372, TI TPS2373, TI TPS2378, ADI LTC4269, Silicon Labs Si3402, Microchip PD70224.
• Isolation / flyback examples: TI UCC28780, TI UCC28740, ADI LT8302, Power Integrations InnoSwitch3 (INN3xx series), Onsemi NCP1342.
• Secondary buck examples: TI TPS62130, TI TPS62840, ADI LTC3633, MPS MP2145, Onsemi NCP1529.

Ethernet PHY (RJ45 stability + diagnostics)

• 3 hard specs: (1) ESD robustness and latch-up tolerance (2) link diagnostics/counters (link flap, errors) (3) magnetics/board constraints for common-mode control.
• Common pitfall: wrong shield/chassis boundary lets common-mode events enter digital ground → link instability + system noise.
• Example MPNs: TI DP83867IR, TI DP83825I, Microchip KSZ8081RNA, Microchip KSZ9031RNX, ADI ADIN1300, Realtek RTL8211F.

Wi-Fi Module / SiP (antenna interface + coexistence)

• 3 hard specs: (1) supply transient requirements and ripple tolerance (2) antenna interface and keep-out constraints (3) coexistence resilience under nearby switching noise.
• Common pitfall: stable RSSI but high retry rate indicates desense (noise coupling), not a “router problem”.
• Example MPNs: u-blox NINA-W156, Murata Type 1DX (LBEE5KL1DX), Murata Type 1LV (CYW43012-based), Espressif ESP32-S3-WROOM-1, Espressif ESP32-C6-WROOM-1, AzureWave AW-CM256SM.

PIR Sensor / mmWave Radar (presence trigger)

• 3 hard specs: (1) raw signal stability vs temperature (2) field-of-view / angle sensitivity (3) burst interference management (supply/return isolation).
• Common pitfall: false triggers often come from doorway geometry (multipath, reflections) and temperature drift, not “bad algorithms”.
• PIR examples: Panasonic EKMB series, Murata IRS-B210ST01, Excelitas PYQ series, ams OSRAM TSL2671* (if using optical proxy) (*only if applicable).
• Radar examples: Infineon BGT60TR13C, Infineon BGT60UTR11AIP, TI IWRL6432, TI IWR6843AOP, Novelda X4 (XETHRU/X4-based modules where used).

Secure Element / TPM (device identity + key vault)

• 3 hard specs: (1) non-exportable key storage (2) secure provisioning flow support (3) interface fit (I²C/SPI) and lifecycle/lock features.
• Common pitfall: private keys stored in external flash (even encrypted “in software”) often become extractable via debug or dump.
• Example MPNs: Microchip ATECC608B, NXP SE050, Infineon OPTIGA™ Trust M (SLS32AIA010MS), STMicroelectronics STSAFE-A110, Infineon TPM SLB9670.

TVS / ESD / CMC & EMI parts (doorway robustness)

• 3 hard specs: (1) clamp level vs protected IC abs max (2) capacitance vs signal integrity (USB/Ethernet) (3) return path to chassis/shield without injecting digital ground.
• Common pitfall: a “good” TVS placed with a long return loop becomes an injector; placement is part of the spec.
• TVS/ESD examples: Nexperia PESD5V0S1UL, Nexperia PESD2ETH (Ethernet), Littelfuse SMF05C, Semtech RClamp0524P, onsemi ESD9M5V.
• CMC examples: TDK ACM2012 series, Murata DLW5BS series, Würth WE-CMI / WE-CNSW series (Ethernet use cases vary).