IR flood light turns off after a few seconds on a depth camera

You command the IR flood light on, the depth stream comes up, and two to three seconds later the glow is gone while the video keeps running. That combination, emitter dark and image pipeline alive, is almost never a codec, bandwidth or pipeline problem. It points at the power reaching the emitter's driver, or at the driver itself, and three quick tests decide which: command the intensity once from the host, watch the emitter through a phone camera in a dark room, and meter the PoE budget. This guide gives you the test order, the arithmetic that says which power class your camera needs, and the decision at each outcome: change one line of code, upgrade the injector, or send the unit back for service.

What the failure signature tells you

Write the signature down before touching anything: the emitter lights within about a second of the pipeline starting, dies after 2-3 seconds, and the video stream runs on unaffected in every mode you try — host-controlled, on-device script, and a standalone package booted from flash. Two conclusions follow immediately. The command reached the driver, because something lit up, so this is not a missing setting. The streaming path is healthy, so this is not bandwidth or encoding. What remains is the power reaching the emitter, a protection circuit in its driver, or the driver itself.

One trap hides in plain sight: with room lights on, a mono image can look completely normal with the IR emitter off, and you only see the loss when the lights drop. If the depth output turns to noise in a dim room but looks fine in daylight, treat the emitter as a suspect from the first minute. The confidence image usually collapses with it, which gives you a numeric flag instead of a squinting test.

Cameras that behave this way carry the emitter inside the housing, and the type names say so: projected structured light, laser galvanometer stereo, and time of flight.

Test 1: command the emitter once, from the host

1. Open the device in normal host-controlled mode with a minimal pipeline: the mono streams only, no encoder, no script node.
2. Right after the device opens, set the flood-light brightness once and leave it alone. The SDK call reads setIrFloodLightBrightness(0.9) on the camera families that expose it. No loop.
3. Run the phone-camera test from the next section and note the time from glow to dark.
4. Repeat the same single command inside an on-device script node, then from a standalone package booted from flash.

If the emitter holds in one mode and dies in another, you have found a software or loader problem: re-flash the package and align the SDK with the camera's firmware before anything else. If it dies at the same 2-3 second mark in every mode, the code is exonerated — stop editing the pipeline and move to power. Identical behaviour across modes is the classic result, because the emitter driver does not care which core sent the command.

Test 2: watch the emitter with a phone camera

Dark room, monitors off, phone held 0.3-1 m from the front of the camera: close enough to see a faint glow, far enough to stay out of the beam. Record video rather than stills, because you want the moment of death on a clock, and the file doubles as the evidence a support engineer will ask for.

Most rear phone cameras see 850 nm as a faint purple-white glow. If yours shows nothing, try the front camera: rear lenses often carry a strong IR-cut filter, front lenses frequently do not. A 940 nm emitter always looks dimmer than an 850 nm one on a silicon sensor, so judge the fault by the timer and not by brightness — the signature is a glow that dies on a schedule, not a faint glow.

Test 3: meter the PoE power budget

The classes first, because PoE on its own hides port budgets that differ by more than a factor of five.

Put an inline PoE meter between the injector and the camera, let the stream run normally, then command the emitter to high brightness. A failing budget has a clear signature: the draw steps up as the projector fires, the voltage reading sags, and within a few seconds the port drops and renegotiates — the camera reboots, or the emitter latches off while the stream rebuilds without it. A budget that sags partway but never trips shows up instead as brightness droop mid-exposure, and that softer cousin has its own guide: PoE camera illumination droop during exposure.

Two checks in the same minute. Add the nameplate maxima of everything on the switch and compare the sum with the switch's total PoE budget, and confirm that the injector actually negotiates a class. A brick that pushes 48 V through an RJ45 with no 802.3 handshake is not a Type 1 or Type 2 source: a camera can stream on it and still refuse the emitter's current step.

Decision: sag or renegotiation at the emitter step means the budget is the fault, and the arithmetic in the next section names the port you need. A steady reading inside the class while the emitter still dies means power is innocent, and the hardware section decides.

Worked example: what an 802.3af port really delivers to a PoE depth camera

Inputs, with their sources: the IEEE 802.3 class budgets — 15.4 W at the port with 12.95 W guaranteed at the powered device for Type 1, 30 W at the port with 25.5 W at the device for Type 2, the difference in each case reserved for worst-case cable loss — plus P_max, your camera's rated maximum power with the emitter at 100%, read from its spec sheet.

The rule in words: the camera receives the port budget minus cable loss, and every load in the housing — sensors, processor, encoder and emitter — must fit inside what arrives.

Result: an af port guarantees 12.95 W at the camera and an at port 25.5 W, and 25.5 / 12.95 ≈ 2.0 — double. A bt Type 3 port goes further, with 60 W at the port and 51 W at the device.

The decision, with the threshold. Read P_max, then choose the port.

• P_max ≤ 12.95 W: af is possible by arithmetic. If the emitter still dies on a healthy af port, suspect the driver, not the injector.
• 12.95 W < P_max ≤ 25.5 W: an at-class port is required. An af injector fails exactly the way this article describes, and no swap within af can fix it.
• P_max > 25.5 W: order a bt Type 3 port.

Why the stream survives but the emitter dies

The pipeline draws a steady load: two sensors, an image processor and an encoder, all running inside the class budget. The flood projector is the opposite kind of load — pulsed, high peak current, and the single largest consumer in the housing. When the rail sags under the projector's current step, protection acts on the biggest load first: the driver latches off, the sensors and processor keep streaming on what is left, and the viewer never notices. That is why the fault presents as software; every part you can see stays alive.

Thermal shutdown looks different on the clock. A thermally limited emitter runs for many minutes, then dies, and dies sooner as ambient temperature rises, while the 2-3 second cut-out happens before the heatsink has warmed at all. If your unit matches the minutes-long pattern, treat it as thermal: add airflow, drop the emitter duty cycle, and check the ambient against the camera's rated range.

Two units, two sites: when it is the hardware

Two units failing identically at two sites, on a compliant injector, is a strong result. Two different power environments rarely share a fault, so either the model needs more than the ports provide — the worked example answers that — or the emitter driver is faulty, and when two serial numbers share the symptom, a batch defect is on the table. Either way, more code cannot help.

Collect everything before contacting the maker's support: the phone-camera video, the mode matrix across host, script and standalone, the injector model and its class, the meter reading at the emitter step, and the SDK and firmware versions. One message with those five items starts an RMA without back-and-forth. Do not open the housing: the emitter sits behind the lens assembly, and opening it ends the service claim.

If the camera came from us, the /contact/ page starts the process, and we will read the meter numbers with you.

Prevention: power checks that keep this fault off your bench

• Order the PoE class the camera names for itself, not PoE as a generic label. The spec sheet's power line and the table above decide.
• Put the inline meter on at commissioning, command full emitter brightness, and log the reading in the cell's acceptance record.
• Run one camera per port, and sum the nameplate maxima on each switch against its total budget before adding another unit.
• Keep runs within the IEEE 802.3 limit of 100 m; on a tight budget, shorter runs leave more of the class guarantee intact.
• Align SDK and firmware before commissioning, not after the first mystery.
• For a passive-stereo camera that only needs near-infrared contrast, an external IR flood illuminator moves the illumination load off the camera's budget entirely; purpose-built lights cover that route. For a coded structured-light or ToF camera, the internal projector is part of the measurement and has no external substitute, so its failure is a service case, not a lighting upgrade.

Standard PoE sits between 44 and 57 V at the power source, which is why injectors are built around a 48 V-class input. Feed that input from a supply that holds its voltage under load rather than a plug-in adapter; the LRS-75-48 gives 48 V at 76.8 W for exactly this kind of rig, and a regulated industrial supply keeps the bench from inventing power faults of its own.

The decision, case by case

1. Emitter never lights, in any mode, on any power source: align SDK and firmware, retest once, then start the RMA.
2. Lights for 2-3 seconds, dies in host mode, script and standalone alike, and the meter stays inside class: the emitter driver is faulty. Start the RMA with the phone video attached, and if a second unit shows the same, say so explicitly.
3. Dies on an af port, holds on an at port: power budget. Move the camera to an at port, or to bt Type 3 when P_max says so, and close the ticket.
4. Meter sags or renegotiates at the emitter step: the budget is the fault. Rebalance the switch or upgrade the port class.
5. Runs for minutes, then dies, sooner on warm days: thermal. Airflow, lower duty cycle, and check the ambient rating.
6. Emitter lit but depth noisy at range: not this fault. Set the working distance and exposure for the target's reflectivity; the 3D camera working distance guide covers the geometry.

If you are speccing hardware for a new cell instead, choose the emitter and the port class together: the 3D sensors category lists the active-illumination depth cameras, the camera finder filters them by type, and the system configurator matches camera, network budget and cabling in one pass. More fault-finding write-ups sit on the 3D camera topic page.