Frame grabber cannot detect video source: signal checks

Error 0xBFF6001F, "Cannot detect recognizable video source", appears the moment you snap or grab: the frame grabber opened its Camera Link port and found nothing it can decode. On these systems that means one of two things: the pixel clock never reached the grabber, or it arrived but the camera file's tap geometry does not match what the camera sends. This walkthrough runs the four checks in order of probability, with a test for each and the arithmetic that proves a tap mismatch. You need a multimeter, the camera manual and one spare cable; by the end you will know which side holds the fault.

What the error means at the link level

Camera Link is a serialized link: the camera packs pixel data and the pixel clock onto LVDS pairs inside the cable, and the grabber's deserializer must lock to that clock before it can frame an image. "Cannot detect recognizable video source" means the lock never happened. Either no signal reached the port at all, through power, cable or the wrong port, or the signal's geometry does not match the camera file the port was opened with; vendor troubleshooting guides group the causes exactly this way, naming tap configuration and bit depth mismatches alongside dead links. Treat it as a physical fault first and a configuration fault second: that order finds the cause fastest.

Fast cameras are the classic source of this message during bring-up, and a video source error walkthrough for one high-speed Camera Link camera follows the same chain of checks. For how these links carry images in the first place, read frame grabber image acquisition for Camera Link and CoaXPress.

Check 1: camera power, the most common cause

An unpowered camera is a silent camera: with no supply there is no serializer output and no pixel clock to lock to, and the port reports exactly this error. Power problems hide in three places.

1. Measure the supply at the camera's power input and compare it with the range printed in the camera manual. A supply that reads fine unloaded can still sag under the camera's draw.
2. If the camera is powered through the Camera Link cable, confirm the port actually sources power over the link; not every grabber port does.
3. Check the camera's power or status indicator if it has one, and retest after the camera's boot time; a tool that opens the port during boot sees an absent camera.

Set the camera to free-run as well: many cameras default to external trigger, and a triggered camera emits nothing (Check 4 covers that path).

Check 2: the cable and the port

The second most common cause is a broken path between connector and connector.

• Reseat both ends and inspect the SDR pins for damage or debris; a half-seated backshell leaves pins floating while still looking attached.
• Open the port the cable actually occupies. On multi-port frame grabbers the numbering in the acquisition software does not always match the silkscreen, so count ports from the bracket outward and try each.
• Swap in one known-good cable; this single substitution settles the question faster than any measurement.

The bench spare for single-cable systems is a 5 m SDR-to-SDR Camera Link data cable such as the LS-CBL-0191:

A Base-configuration link needs one cable; Medium and Full configurations split the data bits across a second cable. A Full camera with only its first cable attached delivers half its taps, which the grabber reports as no recognizable source.

If you get an image but it is torn, doubled or split by a dark band, the link passes but the wiring is wrong: that failure mode is covered in camera connected but no image: check the frame grabber cable wiring, and the Camera Link cables category lists the connector styles and lengths. Where several cameras must stay on fixed ports, assign cameras to ports reliably in a multi-camera system covers persistent port naming.

Check 3: the camera file, tap geometry and bit depth

The camera file tells the grabber how to reassemble the frame: tap count, bit depth, region size and frame timing. The camera's manual lists its output modes, and the port must be opened with the file that matches the camera's current mode exactly. A mismatch is a named cause of this error in vendor guides: the deserializer locks, the reassembly fails, and the port reports no recognizable source with power and cabling healthy.

The test is a two-column comparison. Write the camera's configured tap configuration and bit depth on one side and the file's on the other, then make them identical: select the right file, or set the camera into the mode the file describes.

Worked example: one tap or two

Example inputs: a 1280 × 1024 camera, 8-bit output, 40 MHz pixel clock, blanking at 15% of active pixels (Camera Link blanking typically runs 10-20%).

• Active pixels: 1280 × 1024 = 1,310,720.
• Clocks per frame: 1,310,720 × 1.15 ≈ 1,507,328.
• Single tap: 40,000,000 pixels/s ÷ 1,507,328 ≈ 26.5 frames/s.
• Two taps: 80,000,000 pixels/s ÷ 1,507,328 ≈ 53.1 frames/s.

Now the failure: open that single-tap camera with a two-tap camera file and the grabber assembles two pixels from every clock, one of them empty. The frame geometry collapses, sync never matches, and detection fails. When you suspect a file mismatch, drop the camera to its simplest mode, single tap at 8 bits, and grab that first.

For the errors that appear one step later, when the file loads but the bit stream is wrong, read Camera Link camera file not compatible: fix bit stream errors.

Check 4: a triggered camera is a silent camera

If the camera powers and free-runs on the bench but the error appears once installed, the camera is probably set to external trigger. In that mode it emits no pixel clock at all until a pulse arrives, and the grabber cannot tell it from an absent camera. The test takes a minute: switch the acquisition to free-run, or force a software trigger, and watch the error clear.

For the production set-up, wire the trigger source to the grabber's auxiliary I/O connector so the grabber drives the camera's trigger input over the camera-control lines carried in the same data cable, with a 7 m DB9F-to-open frame grabber I/O cable such as the LS-CBL-0224:

If the trigger itself never registers at the camera, the routing is covered in hardware trigger source not detected: check GenICam line settings.

Split the fault: camera, cable or grabber

When the four checks pass and the error stands, isolate by substitution.

• Put a second Camera Link camera on the same port and cable. If it grabs, the first camera is the fault.
• Put the camera on a second port or a second grabber. If it grabs, the original port is the fault.
• Use the serial channel as a stethoscope. The cable carries the camera's serial control channel alongside the video, so registers that still answer over serial while video stays dead condemn hardware on one side or the other, not configuration.

A grabber missing from the system altogether is a different failure: start with camera configuration not responding: fix the frame grabber host PC and Camera Link frame grabber detection and integration. If your error text says the device is in use or busy rather than silent, another process owns the port: that is frame grabber in use: find the owner and release access, and the deeper frame grabber resource conflicts guide covers the cases a second process cannot explain.

When the port itself is dead, the decision is a replacement Camera Link frame grabber such as the MV-GC1102IOL:

When the usual answer is wrong

• Same model, different default: firmware variants of one camera model can default to different tap modes than the file of the same name assumes. Compare against the manual's mode table, not the model name.
• An extender in the path: any Camera Link extender between camera and grabber is a powered stage of its own. Check its power indicator before blaming the camera, and retest with the camera direct on the grabber.
• A tool opened during boot: cameras take a moment after power-up before the serializer runs. Retry the grab after the boot delay before touching any setting.

Bring-up checklist

• Measure the camera supply at the camera and confirm free-run mode: an unpowered or triggered camera emits no pixel clock.
• Seat one known-good cable at both ends and confirm in software which port it occupies: port numbering and silkscreens disagree more often than cables fail.
• Open the port with a camera file matching the camera's tap configuration and bit depth, starting from the simplest mode: single tap, 8 bits.
• Connect both cables on Medium and Full configurations: half the data bits arrive on the second cable.
• Wire the trigger only after a free-run image is proven: trigger problems then cannot masquerade as detection problems.
• Test the serial channel when video is dead but power is good: registers that answer over serial point to hardware, not settings.

Where to go next

If the checks point at parts, the decisions are short: a replacement board from frame grabbers, a spare data or I/O line from the cable category above, or, when the camera itself is condemned, a current Camera Link model among the area scan cameras. The system configurator walks a Camera Link set-up end to end. If the fault survives every check here, contact us with the exact error text and what each test showed; that is enough to name the failing side.