A 12 W dome camera does not draw 12 W the moment you hand it 53 V. For roughly twenty milliseconds it looks, from the switch end, like a 200 W load. If the port's current comparator is quicker than the camera's inrush limiter, the port wins, the camera never boots, and whoever is standing in the rack gets a lesson in millisecond-scale engineering.

I keep a cardboard box under my bench with eleven cameras in it, all labelled "faulty" in my own handwriting. Nine of them work. They were never faulty. They were plugged into ports that could not ride out the first few milliseconds of a cold start, and I spent two projects blaming firmware before I put a current probe on the wire. The scene that finally taught me: a 16-port switch with a 240 W PoE budget feeding twelve domes that added up to 108 W at their worst. Nothing oversized, nothing undersized. After a maintenance shutdown, three ports would drop, wait, retry, drop again, until enough of the rack happened to come up in a workable order. The budget was correct. The timing was not.

Why the Budget Adds Up and the Port Still Trips

PoE budgets are written in watts because watts are what procurement understands. A PSE does not measure watts. It measures current through a sense resistor, compares it against a threshold, and either keeps the FET on or cuts it. That threshold is set relative to the negotiated class current, not relative to whatever the load will do in its first breath.

Here is the arithmetic. A PD's input is a capacitor, and an uncharged capacitor is a short circuit. Current follows I = C × dV/dt, which at t = 0 is limited only by series resistance. Take a 470 µF bulk cap — unremarkable for a camera with an IR driver — on a 53 V rail. The 802.3at channel budget is 12.5 Ω for a full 100 m run; add maybe 1.5 Ω for connectors, the port FET and the polyfuse. Fourteen ohms total.

53 V ÷ 14 Ω ≈ 3.8 A. On a port whose class current is 600 mA.

It is brief. The time constant is 14 × 470 µF ≈ 6.6 ms, so the cap is about 95% charged in three time constants, roughly 20 ms. Energy stored is ½CV² ≈ 0.66 J, which averaged over those 20 ms is only about 33 W — but the instantaneous product of 53 V and 3.8 A is 200 W, and a comparator does not average. It sees a step.

This is why the standard spends pages on PD inrush control instead of just naming a wattage. A well-built PD ramps its input with a hot-swap controller, holding the draw near class current for a few milliseconds while the cap fills. A cheap one uses a resistor, or nothing, and trusts that the switch is forgiving. Most switches are. The ones that are not end up on my bench with a camera taped to them.

What the Port Is Actually Measuring

The overcurrent trip sits a modest margin above class current — a few hundred milliamps, not amps. The PSE cannot distinguish a charging capacitor from a shorted cable, so when the threshold is crossed it does the only safe thing and removes power. Then it waits, a few hundred milliseconds to a couple of seconds, and tries again: detect signature, classify, power on, trip, wait. Seen from a browser that is a camera that "keeps rebooting". Seen from the switch log it is a row of overcurrent events with suspiciously even spacing.

Two different failures get reported as one. A port-level trip kills a single port and leaves the rest running, so the operator concludes the camera is dead. A budget-level shed happens when the allocation is exceeded and the switch drops whichever port is lowest priority or last to negotiate, so the operator concludes the power supply is failing. Different fixes. The log usually tells you which you have, if you read timestamps instead of counting alarms.

Some PSE controllers offer a start-up window — a short period where the limit is multiplied before the normal threshold applies. It is the most useful PoE feature nobody prints on the box. Cheap unmanaged boards omit it, because it costs a slightly better controller and nobody asks.

Where the Surge Actually Comes From

Not from the load you can see in a spec sheet. From the parts that store energy or start abruptly:

  • Bulk capacitance on the PD input, plus a second stage behind the DC-DC — two caps, two inrush events, milliseconds apart.
  • IR illuminators, which switch a constant-current driver on at dusk. Steady draw can climb 50–80% in one step, and the driver's input cap charges at the same instant.
  • Heaters and wipers, resistive and honest about it, but they engage at the coldest, darkest moment when every other unit is also at maximum.
  • PTZ motors, pulling locked-rotor current during the boot self-test. On a clamp meter the self-test is the tallest peak, taller than the heater.
  • Passive splitters and 24 V gear, which often have no inrush limiting at all, because the designer assumed a bench supply with 20 A of headroom.

The multipliers below are ratios I have recorded with a clamp meter in peak-hold, on my bench and in racks I was already troubleshooting. Treat them as ratios, not specifications — the absolute numbers move with temperature, firmware and whatever the vendor changed last quarter.

Device typeSteady draw (worst case)Startup peak, first ~100 msWhat dominates the peak
4 MP fixed dome, IR on6–8 W1.6–2.2×Input bulk cap + IR driver cap
PTZ with heater14–22 W2.0–2.8×Pan/tilt self-test, then heater
Wi-Fi 6/6E access point12–18 W1.8–2.4×Radio front end bring-up sequence
Passive splitter + 12 V router8–12 W3–4×No inrush limiter, large unregulated cap
PoE LED luminaire20–40 W1.2–1.5×Constant-current driver soft start

The passive splitter row is the one that catches people. It is also the cheapest hardware in the rack, which is not a coincidence.

The Arithmetic I Run Before Quoting a Switch

Six steps, about ten minutes, and it has saved me more site visits than any diagnostic tool I own.

  1. Use the worst-case steady figure, not the nameplate. For a camera that means IR on and, if it has one, heater on. Nameplate is a marketing number; the IR-on figure is the engineering one.
  2. Multiply by the startup ratio for that device class. A 9 W dome becomes roughly 18 W of transient demand.
  3. Compare that peak against class current, not wattage. 802.3af is 15.4 W at the PSE, capped at 350 mA. 802.3at is 30 W at 600 mA. 802.3bt Type 3 is 60 W at 600 mA per pair across four pairs; Type 4 is 90 W at roughly 960 mA per pair. If the peak exceeds what the port tolerates at that class, the label is irrelevant.
  4. Count how many ports cold-start together. Steady state is concurrent by definition. Startup is not — unless the rack just came back from an outage, which is exactly when it happens.
  5. Size the supply on steady load plus the concurrent peak, not the sum of all peaks. Twelve ports peaking at 18 W is 216 W only if all twelve start inside the same 30 ms. Compare against the real per-port figures on a PoE switch, not the front-panel total.
  6. Then apply thermal derating. Most units hold full PoE output to 40 or 45 °C ambient and derate above that, commonly 1.5–2.5% per °C. A sealed wall cabinet at 50 °C is not a 240 W switch any more.

Run it on my twelve-dome rack. 12 × 9 W = 108 W steady at the PD. Add 15% for cable loss and PD-to-PSE overhead: about 124 W at the switch. Comfortable. Now the simultaneous case: 12 × 18 W = 216 W for a few tens of milliseconds. The unit has 240 W at 25 °C and 216 W after derating to a 48 °C closet. Exactly at the line. That is why it passed on a bench in an air-conditioned room and failed in a metal box bolted to a wall. Numbers that land exactly on a limit are not margins. They are coin flips.

Staggering Beats Watts

Nine times out of ten the fix is not a bigger switch. It is not bringing twelve ports up in the same instant.

Managed units generally expose a per-port power-on delay, a PoE schedule, or port priority. Set a two- or three-second offset per port, or per group of four, and the concurrent peak collapses from 216 W to about 36 W. The marginal switch becomes boring, which is the highest compliment hardware can receive. Priority matters too: put the PTZ and the AP on the ports that come up first and let the fixed domes queue behind them.

One warning about convenience features. Many mid-range switches ship a "PoE watchdog" that pings the PD and power-cycles the port when it stops answering. During a mass restart every camera is offline at once, so every watchdog fires in the same window and every port cycles in sync. A feature built to recover one dead camera can turn an orderly startup into a stampede. If a site boot-loops only after outages and the switch advertises auto-recovery, disable it for a week. I have watched that single checkbox close a two-month intermittent-fault ticket.

No scheduling at all? Two workarounds that need no purchase order: split the camera group across two switches so the supplies start independently, or land the high-draw units on a separate unit and leave the domes on the big one. For what you give up by skipping management features entirely, see my piece on managed versus unmanaged PoE switches.

Measuring It With What Is Already in the Van

You do not need a current probe and a scope, though both help. A clamp meter with peak-hold or inrush mode will catch the event if its sampling is fast enough — many cheap ones average over 100 ms and show you nothing, which is how people conclude there is no inrush. Check the capture window before you trust a flat reading.

Poor man's method: a 0.1 Ω shunt in series with the spare pair, scope across it, single-shot trigger on a rising edge. Fifty millivolts per amp, and the shape tells you everything. A clean ramp means the PD is limiting properly; a near-vertical wall means it is not.

The cheapest instrument is the switch log. Pull the PoE event history and sort by time. Events clustered within a second or two are a concurrency problem. Events scattered across the day on one port are that port's problem, and a different article — if the camera never powers up at all, start with the nine-step checklist.

Two physical numbers worth carrying on site. 24 AWG copper is about 9.38 Ω per 100 m per conductor; because each polarity uses both conductors of a pair in parallel, a 100 m channel lands near 9–10 Ω cold, and the 12.5 Ω that 802.3at assumes covers patch cords, connectors and some temperature margin. Copper resistance rises about 0.393% per °C, so a cable pulled through a 55 °C ceiling void is roughly 12–14% worse than what you measured in winter. Both effects push PD voltage down at the exact moment the load spikes, which is why PoE extenders exist and why I stopped assuming a 100 m run is a 100 m run.

Questions I Get Asked on Site

Will a bigger power supply stop the port from tripping?

Only if the trip is budget-level. If one port cuts out because its comparator dislikes a 3 A spike, the switch could have a 1000 W supply and nothing would change. Check whether neighbouring ports stay up. If they do, the supply is not your problem.

Why does it only happen after a power cut?

Because that is the only time every PD starts together. Normal operation is staggered by human beings plugging cables in one at a time, which is the world's most reliable startup scheduler and the one nobody credits.

Would an injector on that one port help?

Often, yes. A single-port injector has its own controller, its own trip behaviour and its own supply, so it sidesteps both the comparator and the shared budget. It is a legitimate field fix, not a hack, and I have used it to keep a PTZ alive on a maxed-out switch.

Do 802.3bt ports handle inrush better?

Generally. Four-pair delivery spreads current across more copper, and a Type 4 port at roughly 960 mA per pair has more absolute headroom before its threshold is reached. The spike does not shrink; the port's tolerance grows. That is still a real improvement.

Can I fix it by adding capacitance at the camera?

That makes it worse. More capacitance means more inrush, the opposite of what a marginal port needs. People add caps to ride through dips, and it works right up until the port decides the camera is a short.

What number should I ask a supplier for?

Peak inrush current and its duration, the port's overcurrent trip point for the class, and the retry interval after a trip. Three numbers, all in the controller datasheet, almost never in the sales deck. A supplier who can answer them has read their own design.

What I keep running into is diagnosis at the wrong timescale. People measure a steady 9 W, see it is well under 15.4 W, and conclude the power is fine. The port never cared about the steady 9 W. It cared about the 3.8 A that arrived 400 microseconds after the FET turned on, and whether its comparator was configured to forgive it.

I still keep the box of cameras. Eleven of them, nine working. "Faulty" usually describes a test setup rather than a device. If you have a port that only dies on cold mornings, or a rack that needs twenty minutes to come back after an outage, I would like the numbers — peak current, run length, ambient, port count. Those four settle it before anyone opens a ticket.