Frame grabber camera config file for a non-standard camera

A frame grabber does not need a standard camera. It needs a correct description of yours, and that description is the camera config file — an .icd file in the classic syntax. The file tells the board how many pixels per line the camera actually transmits, how many lines per frame, how fast the pixel clock runs, which polarity each sync signal uses, and whether the camera free-runs or waits for a trigger. When any of those numbers does not match the video stream, the board waits for a frame that never completes and reports an acquisition timeout. This guide shows how to generate the file from the camera's timing datasheet, check every number with arithmetic you can do by hand, and read a timeout by where the acquisition stops.

Why a timeout is a file problem, not a board problem

Parallel-interface and Camera Link boards are built to acquire from cameras their maker has never seen. The receiver counts pixel-clock edges and watches the frame-valid (FVAL) and line-valid (LVAL) levels; it has no opinion about whether the camera is standard. Non-standard only means the shipped file list has no entry that matches, so you write the entry yourself with the vendor's camera-file generator — a documented tool that asks for the datasheet numbers and writes the file. That generator, not the file list, is the supported path for a custom camera.

Do not start from the closest file on the list. A file from a similar camera carries that camera's blanking counts and polarities, and those wrong numbers fail in ways that look random: torn frames here, timeouts there, an image that drifts as the camera warms up. Generate a fresh file from your own datasheet instead. If you must adapt an existing file later, expect the bit-stream errors that mismatched Camera Link camera files produce, and change one field at a time.

What the camera file must describe

The generator asks for a short list, and every item comes off the camera's timing datasheet:

• Pixel clock input frequency (MHz) — the clock the board uses to sample the data lines. The generator documentation for the classic parallel-interface boards lists 67 MHz as its accepted pixel clock rate; the Camera Link specification allows up to 85 MHz on a Base channel. Keep the camera's actual clock inside your board family's figure.
• Active pixels per line and total pixels per line. The total includes horizontal blanking, and the horizontal offset tells the board how many blank pixels to skip before counting active ones.
• Active lines per frame and total lines per frame — the same idea vertically.
• Polarity of FVAL, LVAL and DVAL, and the sampling edge of the pixel clock. The same documentation states the requirement plainly: line-enable and frame-enable must be active for all valid pixels, so a camera that gates its data oddly needs these fields matched exactly.
• Tap geometry, bit depth and pixel packing — how many outputs feed the cable and how their pixels interleave in memory.
• Sync source and trigger mode — free-run from the camera's own clock, or external EXSYNC on CC1 (the control line most cameras reserve for it), with retrigger and exposure behavior on top.

All line-scan and most parallel area-scan cameras drive a pixel clock on the cable, so confirm yours does before planning anything else. If you are new to these boards, the frame grabber image acquisition walkthrough for Camera Link and CoaXPress shows how the fields become an image.

The procedure below assumes a Base Camera Link or parallel-interface board with a working generator.

What you need on the bench

Gather four things before you open the generator: the camera's timing datasheet with a complete timing diagram; a board whose status view shows clock detection and a frame counter; an oscilloscope, or at least the board's signal-status page; and the camera-file generator itself.

Pick a Camera Link cable in the connector type your board uses — MDR-26 or SDR-26 — and keep the run inside the 7 m Base limit of the Camera Link specification.

For scope work, a frame grabber I/O breakout cable brings FVAL, LVAL and the trigger line out to test clips, so you can measure signal levels without soldering to a connector.

Build the camera file, step by step

1. Write down the pixel clock and check the ceiling. Take the typical value from the datasheet, not the maximum. A 40 MHz clock sits comfortably inside every parallel-family ceiling; 85 MHz is the Camera Link Base limit itself and needs a board family rated at that rate.
2. Enter the active resolution. Active pixels per line and active lines per frame, exactly as the sensor outputs them — 1280 × 1024 in the example below.
3. Enter the blanking counts. Total pixels per line = active + horizontal blanking; total lines per frame = active + vertical blanking. If the datasheet gives periods instead of counts, convert them: total pixels per line = pixel clock × line period. A 40 MHz clock with a 40 µs line period means 1,600 pixels per line.
4. Set the polarities from the timing diagram. Enter each signal's active level exactly as drawn. An inverted FVAL makes the board see one endless frame or no frame at all — both end in a timeout, and neither produces a useful error message.
5. Set the taps, bit depth and packing. A single-output camera is trivial. Dual-tap needs the interleave order from the datasheet; get it wrong and columns alternate in the image.
6. Set the sync source. Free-run means the board self-times from the pixel clock. For a triggered camera, set EXSYNC on CC1 with the polarity the camera expects; exposure then follows the sync edge. The same discipline carries over to modern interfaces as GenICam trigger line configuration.
7. Set the trigger and exposure ceiling. Exposure must fit inside the frame period the file describes, or frames collide and buffers starve. The worked example below puts a number on that ceiling.
8. Save, load and acquire full-frame first. No cropping and no region of interest on the first acquisition. A full frame proves the counts; cropping hides them.

Worked example: a 1280 × 1024 camera at 40 MHz

Take a custom global-shutter CMOS camera: 1280 active pixels per line, 1024 active lines, 40 MHz pixel clock, 320 pixels of horizontal blanking, 16 lines of vertical blanking, one 8-bit output. The datasheet gives all six numbers; the file takes four of them directly and the rest is arithmetic:

• Total pixels per line = 1280 + 320 = 1600
• Line period = 1600 / 40,000,000 = 40 µs, so the line rate is 25,000 lines per second
• Total lines per frame = 1024 + 16 = 1040
• Frame period = 1040 × 40 µs = 41.6 ms, so the frame rate is 1 / 41.6 ms ≈ 24 fps
• Data rate = 40,000,000 pixels/s × 8 bit = 40 MB/s, far inside a Base Camera Link channel

So the file reads: 40 MHz pixel clock, 1600 total pixels per line, 1040 total lines per frame, horizontal offset 320, active window 1280 × 1024 — and the frame counter should settle at about 24 fps once it loads.

The exposure ceiling comes from the same numbers. If the camera cannot overlap exposure with readout, exposure must fit inside the blanking window: 16 lines × 40 µs = 0.64 ms. If it can overlap — most modern global-shutter CMOS designs can — exposure runs to roughly the full 41.6 ms frame period before frames are lost.

The line-rate calculation is the same math the embedded calculator runs; enter any pixel clock and total pixels per line to check another camera the same way.

Diagnose the timeout by where it stops

Verify the file before you blame the board

1. The status view reports the pixel clock detected. No clock means stop here: scope the cable, check connector seating, and follow the parallel-camera pixel-clock diagnosis or the signal checks for an undetected video source.
2. The frame counter ticks at about 24 fps — roughly 1,440 frames in a 60-second count.
3. The captured image measures exactly 1280 pixels wide.
4. One capture at the total width of 1600 shows the blanking as dark margins; setting the horizontal offset to 320 with an active width of 1280 removes them.
5. A ten-minute run accumulates zero dropped-frame or FIFO-overflow flags.

Common mistakes

• Active counts in the total fields. The frame counter and the image geometry both go wrong, usually with dark seams at the line edges.
• Polarity copied from another camera's file. Same connector, different camera, inverted FVAL — a timeout with no other symptom.
• Treating the file as camera programming. The file configures the board only. Exposure, gain and trigger behavior stay on the camera side, set through its serial protocol or the EXSYNC line.
• A cable past its rating. Beyond the 7 m Base limit, or a fixed-install cable in a drag chain, bit errors mimic file errors. Where wiring is suspect, work through the frame grabber cable wiring checks before rewriting anything.
• Host-side stalls that read as timeouts. If the configuration tool itself stops responding, the problem may be the host rather than the file; the frame grabber host-PC fix for an unresponsive camera configuration covers that path.

When to sidestep the file — and the decision

If you are choosing hardware rather than rescuing a legacy camera, a GenICam interface removes this entire step. GigE, USB3 and CoaXPress cameras describe their own capabilities to the board, so there is no timing file to write; compatibility reduces to bandwidth and connector budget. On the older interface, the same thinking is the Camera Link camera-and-frame-grabber matching checklist.

The decision, in three lines:

• Rescuing a parallel or Camera Link custom camera: generate the file, and fix in this order — pixel clock present, then counts, then polarities, then trigger mode. Each step eliminates a whole class of timeout.
• Specifying new hardware: prefer a GenICam-interface camera unless the custom timing is itself the requirement.
• Everything verified and still timing out: move to the physical layer, then the host, in that order.

Browse the frame grabbers range, use the accessories finder to filter by interface, or let the configurator step through board, cable and adapter choices. The acquisition-side fixes collected on the systems topic page cover the rest of the pipeline.