How Do You Design Power over Ethernet (PoE) into an Embedded Product?

Detailed Explanation

Power over Ethernet lets a single Ethernet cable carry both data and DC power to a device — common in IP cameras, VoIP phones, wireless access points, and increasingly in industrial sensors and building-automation endpoints where running a separate power cable to every device is impractical. Designing PoE into a product means implementing the Powered Device (PD) side of the IEEE 802.3 PoE clauses; the upstream Power Sourcing Equipment (PSE) — a PoE-capable switch or a mid-span injector — is generally purchased, not designed.

This is a distinct design task from the data-side Ethernet interface covered in what is Ethernet? — a PoE PD design adds an entirely separate power path that must be correctly detected, classified, isolated, and converted before the device's own logic rails exist.

The PD Handshake: Detection and Classification

A PSE never applies full voltage to a port speculatively — doing so would be unsafe for a device that isn't PoE-capable (a legacy Ethernet device, or a cable with nothing connected). Before applying power, the PSE performs two steps that every PD design must correctly respond to:

1. Detection: the PSE applies a small probing voltage (2.7–10.1 V) and measures the resulting current to calculate resistance. A compliant PD presents a precise 25 kΩ signature resistor across its input (specified by IEEE 802.3 to fall within a narrow tolerance window) — this is what tells the PSE "a valid PD is connected," as opposed to an open circuit, a short, or a non-PoE device's much lower or higher impedance.
2. Classification: once detection succeeds, the PSE applies a higher probing voltage (15.5–20.5 V, or higher for 802.3bt) and measures the current the PD draws, which the PD sets (via a precision current source) to indicate its power class — communicating its maximum power requirement to the PSE before full power is ever applied. 802.3at and 802.3bt add finer-grained classes and an optional two-event or multi-event classification handshake (LLDP-based classification is also used in 802.3bt for the most granular power negotiation).

Only after both steps succeed does the PSE apply the full nominal 44–57 V PoE bus voltage — and the PD controller IC is what implements the signature resistor, classification current source, and (in most designs) an inrush-current-limiting soft-start on power application, the same fundamental need covered generally in how do you limit inrush current when a board is hot-plugged or powered on?.

Polarity-Independent Input: The Bridge Rectifier

IEEE 802.3 deliberately allows a PSE to deliver power via either the two spare pairs (unused in 10/100BASE-T) or phantom power superimposed on the two data pairs, and does not standardise polarity on either pair set. A compliant PD cannot know in advance which mode or polarity a given PSE will use, so every PD design includes a full-bridge rectifier (four diodes, or increasingly four MOSFETs configured as an "ideal diode" bridge to reduce conduction loss) ahead of the PD controller, so the downstream circuit always sees correctly polarised DC regardless of which pairs or polarity the PSE chose.

The Isolated DC-DC Stage

IEEE 802.3 requires galvanic isolation between the Ethernet cable (and hence the PoE power path) and the rest of the device — the same isolation barrier requirement that applies to the data-side Ethernet magnetics (see the magnetics and isolation notes in what is Ethernet?). This means the PD's DC-DC converter, which steps the ~48 V PoE bus down to the device's actual logic voltage (commonly 12 V, 5 V, or 3.3 V), must itself be an isolated topology — almost universally a flyback converter (see how does a flyback converter work? for the isolated-topology fundamentals), since flyback is well suited to the wide input voltage range, moderate power level, and multiple-output flexibility PoE applications commonly need.

Feedback across the isolation barrier uses the same TL431 + optocoupler technique covered in the flyback converter page, or a digital isolator (see optocoupler vs digital isolator for that trade-off) in newer designs.

Design Considerations

• Budget power conservatively against the device's PoE class, not just its typical load. The class you select determines the PSE's guaranteed power budget — design the actual downstream load (including inrush and peak transient loads, not just steady-state) with margin below what the class guarantees, accounting for cable-loss variation across the supported cable length and gauge range.
• Decide 2-pair vs 4-pair (802.3bt) support based on real power need, not just future-proofing. Supporting 802.3bt Type 3/4 adds real input-circuit complexity (a second bridge rectifier stage and combining circuitry for the second pair set) — only take this on if the product's power budget genuinely needs more than 802.3at's 25.5 W at the PD.
• Select a PD controller IC with the classification behaviour your target power level needs. Simpler designs at lower power (802.3af Type 1) can use a single-event classification; higher-power 802.3at/bt designs need the controller to correctly perform two-event classification (and, for 802.3bt, potentially LLDP-based classification) or the PSE will not grant the higher power budget.
• Verify isolation clearance and creepage on the PCB, not just the transformer's own isolation rating — the PCB layout between the Ethernet-side and logic-side of the isolation barrier must maintain adequate creepage/clearance per the safety standard the product is certified against.

Zeus Design's engineering team designs PD-side PoE power stages — from detection/classification through the isolated DC-DC output — for industrial sensors, IP-connected devices, and other PoE-powered products; contact Zeus Design to discuss a PoE-powered product design.

Common Mistakes

• Omitting the bridge rectifier and assuming a fixed pair/polarity convention. A PD that assumes a specific PSE polarity or pair set works with some switches and injectors but fails with others — full-bridge rectification ahead of the PD controller is not optional for a genuinely compliant, interoperable design.
• Under-budgeting for cable loss at the PD's power class. The PSE guarantees a certain power budget at the PD accounting for typical cable loss at the standard's assumed maximum cable length — a design that consumes power right at the theoretical PSE-side limit, without accounting for the PD-side guaranteed figure being lower, can brown out on longer cable runs.
• Treating the isolation barrier as satisfied by the transformer alone. The transformer's isolation rating is necessary but not sufficient — PCB creepage/clearance across the isolation boundary, and correct optocoupler or digital isolator placement for the feedback path, both need to maintain the same isolation integrity.
• Skipping classification and only implementing detection. A PD that implements only the 25 kΩ detection signature without a proper classification response draws the PSE's default (lowest) power allocation regardless of actual need — a device that needs more power than the default class will brown out or fail to start reliably.
• Not testing with multiple real PSE vendors. PSE implementations vary in their exact voltage ramp behaviour, inrush tolerance, and timing around the detection/classification handshake — validating against only one switch vendor's PoE implementation risks field failures against other compliant-but-different PSE hardware.