Camera stuck in standby after reconnect: wake it before you stream

You put a device into standby, disconnect, reconnect and call Start(): it returns true, the callback never fires and no preview image arrives. This hits serial-attached cameras, packaged code readers and integrated vision units that expose a low-power mode over their control link. The disconnect is the red herring — the device kept the state your last session left it in, and reopening a connection never touches it. This guide ranks the causes, gives a test for each and lays out a wake sequence with a worked timing budget, so you replace sleep-and-retry with a deterministic startup. The short version: wake the device, confirm it reports active, then start the stream.

The symptom: Start() succeeds and nothing streams

The signature is a start call that reports success while the image path stays silent: no frames, no callback, no error. The boolean you got back says the control channel accepted the request. That channel is alive — it is how you sent the command — so acceptance tells you nothing about the image pipeline. On a device still in standby the sensor is parked and the pipeline never runs, yet nothing on the host side raises an error.

The confirming detail: a throwaway transaction on the same control channel — a login or authentication call — makes the preview work immediately afterwards. That transaction is the wake-up. The device was asleep, not faulty, and Start() was simply the wrong first move.

Why a reconnect never clears standby

Power state lives in the device, not in your connection. Connect and disconnect open and close a transport: a serial session, a USB enumeration, a TCP link to a camera. None of that resets the electronics. Exactly two things clear standby — the wake command, or removing power — and a reopen does neither. Reopening rebuilds your host-side session and nothing more; restart a live camera preview without reopening the device covers what a reopen can and cannot recover on the stream side.

Standby is deliberate engineering on the device side: small controllers stop the core clock, keep only a wake interrupt alive, and need their clocks settled before they parse anything. Some designs react to line activity — the reconnect traffic itself — but while the clocks settle they can swallow the first command they receive, which looks exactly like no wake at all. Close order matters for the same reason: park the stream before you park the link, as stopping acquisition before you close shows from the timeout side.

Causes in order of probability

Work down this table. Row 1 explains most of these field cases; row 2 most of the rest.

The quiet second cause: the stream object left scope

A stream or preview handle created inside an if block becomes unreachable the moment the block exits. The garbage collector reclaims it, the event subscription dies with it and your callback is never invoked — with no error anywhere in the log. Keep the handle as a field on the class that owns the session, and attach the callback before Start(). When a demonstrably streaming device delivers no callbacks, read multi-camera acquisition freezes: callbacks and buffer queues: unreachable handlers and starved buffer queues look identical from the outside.

Tests that separate the causes

Run one pass, not four theories:

1. After the reconnect, read the device's reported power state. Standby or unknown points at row 1.
2. Send the wake transaction, poll until the state is active, then start. Frames inside the deadline close the case: it was standby.
3. Device reports active and streaming but callbacks stay silent: inspect object lifetimes — row 2.
4. Enumerate the cameras and match the serial number of the unit you aimed at — row 3. An index convention you cannot find in writing is not something to build a station on.
5. Connect status not Ok, or enumeration itself flaky: physical layer — row 4. USB link checks after a cable swap is the systematic version of that pass.

The wake sequence that works

1. Connect and require an Ok status before anything else.
2. Read the reported power state. Treat unknown as standby; a reconnect leaves you no basis for optimism.
3. If it is not active, send the documented wake — the transaction your login path performs counts, because that is exactly what made the preview work in the reported case.
4. Poll the state every 50 ms and cap the wait at 3 s. A bounded loop, never an open one.
5. Create the stream as a field, attach the callback, then call Start().
6. Demand a first frame inside a deadline: 30 frame periods or 2 s, whichever is smaller.
7. On timeout, stop and move to row 2 of the table. Do not resend Start() and hope.

Configuration belongs before the start call on any camera; setting the GigE camera packet size before starting acquisition is the same ordering rule on the network side.

// Illustrative class and method names: substitute your SDK's real ones.
DeviceLink link = new DeviceLink(portName: "COM2");     // serial control link
link.Connect();                                        // require Ok
if (link.DeviceState() != PowerState.Active)
{
    link.Wake();                                       // the documented wake transaction
    int waitedMs = 0;                                  // bounded poll: 50 ms steps, 3 s cap
    while (link.DeviceState() != PowerState.Active && waitedMs < 3000)
    {
        Thread.Sleep(50);
        waitedMs += 50;
    }
}
StreamHandle stream = new StreamHandle(cameraIndex: 0); // hold this as a field, not a local
stream.OnFrame += FrameReceived;                       // callback attached before start
bool accepted = stream.Start();                        // transport acknowledgement only
// Pass condition: FrameReceived fires within 1000 ms at 30 fps — 30 frame periods.

Worked example: the wake-to-first-frame budget

Numbers for a representative station. The LS-CRD-0028 is a 2560 x 2048 fixed code reader that runs at 30 fps and reads up to 60 codes/s with an 8 mm lens. At 30 fps a frame is due every 33 ms (1 ÷ 30 = 0.033 s); 60 codes/s is one decode every 17 ms (1 ÷ 60 = 0.017 s).

Now the control side. Assume a 16-byte wake command on a 115200 bit/s serial link, 10 bits per byte (start, eight data, stop):

Check the arithmetic: 1.4 + 200 + 50 + 10 + 33 = 294.4 ms, which rounds to the 294 ms in the table — call it 0.3 s. The tempting fix, a 3-second wait after the disconnect and another after the reconnect, costs 3000 + 3000 = 6000 ms, about twenty times the deterministic path (6000 ÷ 294 ≈ 20), and it never changes the device state. On a line rated 60 codes/s, 6 s of dead time is 6 × 60 = 360 codes of lost capacity; the wake path costs 0.294 × 60 ≈ 18 codes. And the 1 s first-frame deadline at 30 fps is 1000 ÷ 33 = 30 frame periods, so a stream that misses it is not slow — it is not running.

What not to do

• Do not treat the return value of Start() as proof of frames. It is a transport acknowledgement; gate success on the first frame.
• Do not stack sleeps. They mask row 1 and burn cycle time — 6 s against 0.3 s in the budget above.
• Do not resend Start() in a loop. Without a state check you are adding commands to a pipeline that has not been switched on.
• Do keep the login transaction as the wake if that is what the interface documents — but name it as a wake in your code, and still poll for active.
• Reach for the power cycle last. Removing power always clears standby, but it also drops everything held in volatile memory: a camera losing its settings after a power cycle is that failure seen from the other side, and GigE Vision image corruption after a camera power cycle is its neighbour on the same bench.

Parts and wiring that make the fix clean

A hardware fallback needs wire you can land on a PLC output — a wake line or switched power — brought out through power and I/O cables. The LS-CBL-0300 is an M8 8-pin power and I/O cable, 7 m, built for drag-chain use.

On the reader side, serial-attached units are where standby and wake commands live. Two ends of the fixed code readers range:

The MV-ID6200PM-00C-NNG is a 20 MP logistics code reader with a serial interface; the LS-CRD-0028 carries the numbers used in the budget above. For area scan cameras on Ethernet, many GigE units take power over the network port, which makes a switch-port cycle a clean remote reset — check whether your camera supports PoE before designing recovery around it. A compact GigE color camera like the MV-CU020-90GC is the class of unit this applies to.

Checklist: startup handling that ships

On connect

• Require an Ok status; log the connect timestamp.
• Read the power state; treat unknown as standby.
• Match the camera by serial number, not by index.

Before start

• Wake sent, state polled to active: 50 ms steps, 3 s cap.
• Stream handle held in a field; callback attached before Start().
• First-frame deadline armed: 30 frame periods or 2 s, whichever is smaller.

On disconnect

• Stop the stream, then send the standby, then close the link — in that order.
• Record the state you left the device in, so the next connect knows what to expect.

The decision for each case

• Reported state is standby or unknown after the reconnect: wake, poll to active, then start. Delete the sleeps.
• Device active and streaming, callbacks silent: the stream object is unreachable — hold it in a field for its lifetime.
• Enumeration intermittent or status not Ok: fix the physical layer before touching code.
• No wake command anywhere in the interface: use the login transaction as the wake, or wire switched power and cycle it. Take the wake path first — 0.3 s against several seconds, every cycle.

If you are specifying the station rather than debugging it, the camera finder filters by interface and mount, the system configurator walks camera, lens and light in order, and the accessories finder lists the I/O cable for a wake line. For a device whose standby behavior is unclear, send the model and its control documentation through the contact page and we will map the wake path with you.