Fast answer (what it is)

Scope boundary (avoid buying / designing the wrong block)

In-scope for a PSE controller

Not a PSE controller (out-of-scope here)

Endspan vs Midspan (PSE-controller-relevant differences only)

Practical deliverables (used later in this page)

System view (controller boundary highlighted)

The key translation: “standard terms” → “PSE knobs” → “pass criteria”

For a PSE design, 802.3af/at/bt is most useful as a set of controllable knobs: Type/Class drives detection/classification behavior, 2-pair vs 4-pair power delivery intent, and how strict the port power policing must be. Every knob must map to a measurable pass criterion (threshold placeholders X).

Datasheet must-check (so “bt-ready” means something measurable)

Compatibility boundary (policy-level, not a standards lecture)

A high-capability PSE should not “force” higher power into a lower-capability PD. The port should supply power according to the detected/classified intent, and fall back to a conservative budget if intent is uncertain.

Type/Class → PSE knobs (engineering view)

Use this mapping to turn standards language into configuration fields and testable thresholds.

Standard term	PSE knobs to set	Pass criteria (X placeholders)
Type / Class	P_limit, priority, deny_policy	P_limit accuracy within ±X% over Y s; deny reason logged
2-pair / 4-pair intent	pairing_mode, per-pair limits (if exposed)	pairing mode matches configuration; no unexpected brownout on load steps (X)
Classification event support	event_mode, class retry/debounce	class result repeatable within X/100 plug cycles; logs include event flags
Power-up / inrush constraints	I_limit_inrush, t_inrush, ramp profile	no false trip during ramp; ramp time within X ms; peak I within X A
Policing windows	averaging_window, peak window (X)	no nuisance trips for valid load steps; faults correlate with V/I/T snapshot

Standards map (Type/Class translated into PSE knobs)

Fast summary (what this chapter locks down)

Typical per-port blocks (what must exist somewhere in the design)

Two integration forms (engineering trade-offs only)

Fully integrated (internal FET) simplifies routing and reduces external BOM, but concentrates heat in one package and makes per-port thermal coupling a primary constraint.

Controller + external FET scales power and improves thermal spreading, but layout parasitics and measurement integrity become the dominant risks.

Port budget fields (use as a checklist and a test plan input)

These fields make later chapters measurable: inrush, policing, faults, and telemetry all depend on them.

Block	Budget fields	Why it matters	Pass criteria (X placeholders)
Pass FET	Rds(on), package thermal (θ), heat coupling	Sets conduction loss and the first thermal trip point	Tj margin ≥ X °C at P_port_max; no thermal trip in Y min
Current sense	Rsense, tolerance, offset/gain, bandwidth (BW)	Governs policing accuracy and nuisance trip behavior	I_limit within ±X%; load-step causes no false trip within window X
Gate driver	Gate loop parasitics, ramp slope, blanking timer (X)	Controls inrush stability and prevents oscillation/overshoot	Vport ramps smoothly; peak I ≤ X A; no ringing-triggered trip
Telemetry / ADC	Sampling rate, averaging window (X), snapshots (V/I/T)	Enables correlation between faults and evidence	Fault log includes V/I/T within X ms of event; counters monotonic
Fault thresholds	I_limit, P_limit, trip time, retry/backoff (X)	Prevents damage and avoids retry storms	Trip time ≤ X ms; backoff grows to ≥ X ms; no flapping

Port BOM block (54V_in → RJ45 center tap) with test hooks

Detection logic (keep it as an observable state machine)

The dominant failure mode is rarely “no PoE”; it is usually a window/denominator mismatch: the probe result is correct, but the time window, debounce, or retry policy converts it into flapping.

Detection timeline (V/I window → debounce → retry/backoff)

Debug detection by aligning evidence to the timeline. If a false detect happens, it must appear as out-of-window samples, insufficient debounce, or an overly aggressive retry loop.

False-detect traps (symptom → likely cause → quick check)

Symptom	Likely cause (measurable)	Quick check
Detect succeeds on bench, fails in the field	Cable/port capacitance shifts probe waveform outside the sampling window	Compare detect V/I snapshots vs window (X); check debounce hits and retry count
Random false detect after ESD/surge events	Residual leakage path or bias shift causes “valid-looking” samples	Record detect attempts and invalid reasons; correlate with humidity/temperature logs
Port flaps on plug/unplug (connect bounce)	Debounce too short or retry policy too aggressive	Check debounce counter and retry/backoff (X); confirm stable decision in Y ms
Some ports detect reliably, others never do	Board-level leakage/contamination or port-to-port parasitic differences	Swap cable/PD across ports; compare detect V/I and invalid reasons; inspect port leakage paths

Observability requirements (minimum evidence to debug detection)

Detection state machine + timeline (where false-detect traps appear)

What “classification” must produce in engineering terms

Classification is only useful when it becomes fields that can be logged, validated, and consumed by power policy. Treat it as an observable port output, not a checkbox feature.

Classification flow (logic chain + configurable knobs)

Config knobs to document and log with results: class_mode, t_class (X), t_gap (X), max_attempts, fallback_policy, event_mode.

Multi-event: engineering meaning (why it matters)

Conservative rule: invalid or incomplete event evidence → use lower P_alloc and tighter P_limit, and log the reason code for field forensics.

Verification: accuracy, repeatability, and stability (measurement criteria only)

Recommended log row: port_id, expected_class, observed_class, event_flags, attempts, class_time_ms, invalid_reason, V/I snapshot.

Diagram: Class result → policy inputs (P_alloc / P_limit / priority)

Three budget semantics (nameplate / measured / requested)

Practical rule: P_alloc should be derived from class evidence + system budget, then guarded by measured reality and derating margins.

Per-port policy object (what allocation must set)

Oversubscription behavior (deterministic, no flapping)

When total PSU power cannot satisfy all ports, behavior must be predictable and stable.

Determinism rule: equal priority ports should have a stable tie-break (e.g., last-in, faultiest, or highest draw), and the choice must be logged.

Policing (P_limit + I_limit) with averaging and peak windows

Verification hooks: log window values with each fault so field reports can distinguish policy decisions from physical defects.

Output template: Power Budget Sheet (field schema)

Scope	Fields	Pass criteria (X placeholders)
System	P_PSU_total, derating, guardband, thermal_cap (X), policy_version	No brownout under worst-case plug-in; headroom ≥ X%
Per-port	port_id, class_result, priority, P_alloc, P_limit, I_limit, avg_window (X), peak_window (X), deny_policy, backoff (X)	Oversubscription actions are deterministic; no port flapping beyond X retries
Evidence	measured_P, V/I/T snapshots, fault_count, last_event, timestamp, policy_snapshot	Fault record includes V/I/T within X ms; counters monotonic; policy snapshot present

Diagram: Total PSU budget → per-port allocator (admit / throttle / preempt)

Define a “clean startup” as measurable criteria (not a feeling)

Soft-start / slope control / inrush limiting: the three-knob coupling

Startup robustness comes from aligning t_ramp, I_inrush, and Vport thresholds to the port path and the connected load.

MPS: why light-load power saving can look like a disconnect

Maintain Power Signature (MPS) is a keep-alive decision window. If the measured signature falls outside the MPS window, the port may be declared “not present” even while the cable is intact.

Engineering rule: log the MPS window ID and the matching sampling/averaging settings so field logs explain dropouts.

Plug events and brownout: bounded retries with backoff and clear recovery gates

Minimum startup log fields: timestamp, port_state (startup/inrush/steady/mps_check), V/I snapshots, inrush_peak, t_ramp_measured, mps_fail_count, retry_count.

Diagram: Vport & Iport startup waveform + MPS window (X placeholders)

Fault taxonomy: classify first, then recover (for field and production consistency)

Fault handling must map symptoms to a stable fault_id so recovery actions are deterministic and comparable across ports and units.

Recovery mode templates (avoid retry storms by construction)

Determinism rule: each fault_id should map to a default recovery profile and a bounded retry envelope.

Logging criteria: minimum evidence per fault event

Each fault event should record a reproducible “evidence packet” so field data explains both root cause category and recovery behavior.

Diagram: Fault tree (symptom → fault_id category → quick check)

Control plane vs event plane (maintenance starts here)

Engineering rule: interrupts report “something happened”; registers explain “what and why”; black-box preserves “how it evolved”.

Minimum telemetry set (portable across ports, boards, and firmware)

A system is diagnosable only if logs bind values to a decision context (window/debounce/policy version).

Event reporting: aggregation, thresholds, debounce, and window alignment

If telemetry uses one averaging window and decisions use another, field logs will never explain dropouts.

“Black-box” hooks: preserve evidence packets, not just counters

Each fault or unusual event should trigger an evidence packet with pre/post snapshots and a configuration fingerprint.

Diagram: Telemetry loop (PSE → log/counters → MCU policy → PSE)

Three-gate workflow: build repeatability into the process

The checklist is not a list of tips. It is a gated pipeline with explicit inputs, outputs, and owners. No gate pass → no next stage.

Design Gate (inputs → checks → outputs)

Bring-up Gate (prove the state machine with evidence)

Production Gate (freeze thresholds, freeze criteria, freeze configs)

Output template: Test matrix (copy into a sheet)

Columns: test item · stimulus · expected · pass criteria (X) · logs required · owner

Test item	Stimulus	Expected	Pass criteria (X)	Logs required	Owner
Detect + class	PD connect	valid signature + stable class	misclass ≤ X%	window_id + reason	(Owner)
Startup + inrush	cold start	no restart loop	I_peak ≤ X	pre/post X	(Owner)
Fault recovery	short/overload/UV	correct fault_id + bounded retry	retry ≤ X	commit_id	(Owner)

Diagram: 3-gate flow (inputs/outputs + owner placeholders)

Application buckets (no horizontal expansion)

PSE controllers diverge most in budget control, thermal survivability, and maintainability. Each bucket below binds those themes to concrete knobs and acceptance checks (threshold placeholders: X).

Differentiators are dominated by oversubscription behavior and per-port evidence quality when multiple loads ramp concurrently.

• Allocator: total PSU budget → per-port P_alloc/P_limit mapping + priority shedding order.
• Policing windows: average/peak windows aligned to telemetry window_id (X).
• Thermal hooks: temp flags + derating path (avoid on/off oscillation).
• Evidence: per-port state + fault_id + retry_count + pre/post snapshots.

• Oversubscription test: dropping/limiting order matches the configured priority table (no “random” port losses).
• Field-debug test: each port trip produces fault_id + window_id + retry_count with completeness ≥ X%.
• Thermal stress: derating reduces event rate without creating retry storms (bounded retries ≤ X).

Midspan failures are usually “state-machine ambiguity”: a PD appears incompatible, but the platform cannot prove which phase failed (detect, class, startup, MPS).

• Hot-plug behavior: debounce and bounded retry/backoff (X) to avoid repetitive power-cycling.
• False-detect immunity: robust signature discrimination and clear reason codes.
• External FET friendliness: clear sense scaling + telemetry alignment (window_id).
• Evidence packets: pre/post snapshots on every failed detect/class/startup.

The platform must distinguish transient line events from genuine faults and recover without creating a retry storm. Protection component details are intentionally excluded (see sibling pages).

• Recovery profiles: auto-retry / latch-off / cool-down / backoff, with a hard upper bound (≤ X).
• Windowed policing: P_limit/I_limit windows (X) tuned to avoid false trips from short transients.
• Evidence on every event: timestamp + V/I/T + state + retry_count.

Mixed-load stability depends on consistent budget accounting and predictable shedding under aggregate limits.

• Fixed mixed-load script: the same ports are limited/dropped every run (deterministic priority behavior).
• Policing events: telemetry window_id matches enforcement windows (no mismatched averages).
• Remote tuning: every change carries policy_version/commit_id and can be audited.

Diagram: Application buckets (power budget · thermal · manageability)

Selection pipeline (hard gates → scorecard → red flags)

Step 0 · Write requirements as structured inputs

A decision tree works only if requirements are measurable.

Step 1 · Hard gates (fail any gate → remove from shortlist)

Step 2 · Selection scorecard (template)

Scoring scale: 1 (weak) → 5 (strong). Weights are placeholders (X) and can be tuned per project.

Category	Field	Why it matters	Weight (X)	Score (1–5)	Notes
Power & Ports	bt / 4-pair capability	Defines max delivered power and pairing modes	X	—	Type 3/4 needs
Policy Control	Allocator + priority shedding	Deterministic behavior under oversubscription	X	—	Order + audit
Telemetry	V/I/P/T + state + reason	Field diagnosis without guesswork	X	—	window_id required
Recovery	Bounded retry/backoff	Avoid retry storms and oscillation	X	—	retry ≤ X
Thermal	Derating + temp reporting	Survive worst-case ports and airflow	X	—	stable under load
Ecosystem	Reference designs + compliance support	Reduces integration risk and lab iterations	X	—	production readiness

Step 3 · Red flags (one-vote veto)

Example shortlists (IC part numbers by decision outcome)

These are BOM anchors for the controller function. Platform power entry, magnetics, and protection parts are intentionally excluded here (see sibling pages).

Diagram: Decision tree (ports × power × manageability → controller form)

How to use these FAQs

Each answer is a four-line executable recipe: Likely cause → Quick check → Fix → Pass criteria. Thresholds are placeholders (X) so the same structure works for design, bring-up, and production gates.