Camera Link camera file for a sensor with no vendor file: build it

Your camera file generator has no entry for the sensor, and the sensor maker has none either, because the chip was sold to integrators who each built their own camera around it. That is normal for a CCD bought as a component — including intensified models built in small numbers — and it does not block integration. You build the camera file yourself from what the camera's builder recorded: the serial command set, the pixel format and above all the tap configuration, which no generator can guess from a sensor name. What follows covers the fields the file needs, exactly what to request from the integrator, the bandwidth arithmetic for a Base link, and the checks that prove the file right before the machine is cabled.

What a Camera Link camera file contains

A camera file is a small text file in the frame grabber vendor's own format: the extension and syntax change from vendor to vendor, but every format describes the same things. Those are the tap configuration (how many parallel pixel streams the camera sends), the tap geometry (which sensor pixels ride on which tap, and in what order), the pixel format and bit depth, the pixel clock range, and the frame valid, line valid and data valid timing with polarities. Many files also carry the UART baud rate for the Camera Link serial channel and the mapping of the four camera control lines.

Because the file is plain text, the working route is always the same: copy the grabber vendor's generic Camera Link camera file — most vendors ship one as a deliberate starting point — and edit it field by field. You can invent none of the values; every one comes from the camera's builder. For the wider question of grabber settings on an unusual camera, see frame grabber camera config file for a non-standard camera.

Who to ask when no vendor file exists

Camera file generators index cameras by model, not by sensor. A CCD sold as a component ends up inside many cameras, and each integrator picks the taps, the bit depth and the serial commands; two cameras built around the same sensor can differ in every field the file needs. Put an intensifier in front of the chip and build a short production run, and no generator list will ever carry that model.

So the request goes to the company that assembled the camera, not the company that made the sensor. The sensor maker will tell you the same, because what they hold is a sensor datasheet, not a camera interface. Ask for the ICD — the interface control document — with the tap configuration stated in writing. If the builder has no ICD, their PC driver package is a working substitute, because its C header is the ICD in code form. The register-level side of the serial link is covered separately in Camera Link serial attribute control.

What to mine from the ICD or the driver header

Request these, in this order: the serial command table with byte syntax and argument ranges; the tap configuration and tap geometry in the builder's own words; the pixel format and bit depth; the pixel clock range with its typical setting; frame valid, line valid and data valid polarity with minimum blanking; the UART baud rate; and a list of which corrections the driver applies before a frame reaches you.

One integrator header for an intensified CCD states exposure units as three constants — MICROSECONDS 0, MILLISECONDS 1, SECONDS 2 — so the camera accepts a value plus a unit, not a raw clock count. Its init call returns 0 for success, 1 for a frame grabber configuration error and 2 for a serial port error; during bring-up, a 2 means the UART never opened, and no camera file fixes that. The correction section declares PSL_VHR_enable_dark_field_subtraction(bool bDarkSubtractionEnabled) beside PSL_FDI_load_bright_field_file(char *brightfile), which tells you the dark and bright corrections live in the driver, not in the camera.

Header prototypes give you the shape of the command set, not its byte syntax. If the command table never arrives, ask for the serial protocol note, or capture the bytes the vendor's own tool writes to the camera and reuse exactly those.

Taps: the field the generator cannot guess

A tap is one pixel delivered per pixel clock. The tap configuration says how the link width is spent — Base carries 24 data bits, Medium 48, Full 64 — and the tap geometry says which pixels ride which tap: left and right halves of each line, alternating pixels along one line, or top and bottom halves of the frame. Declare a different geometry than the camera uses and the grabber reassembles a different picture than the sensor saw.

Frame rate scales with tap count at a fixed clock, which is why builders add taps at all. For a 1/1.8-inch interline CCD of 1392 × 1040 pixels on a 6.45 µm pitch, the most common implementation is 2-tap, 8- or 10-bit, on a Base link: two 8-bit taps spend 16 of the 24 data bits, two 10-bit taps spend 20, and two 12-bit taps spend all 24. Intensified units are often 1-tap, because the intensifier's gate, not the link, sets the frame rate. That is the bet to place while the answer is in transit, and the first line to check when it lands. The grabber must support at least the camera's configuration; Camera Link camera and frame grabber compatibility lists what else must line up.

Bandwidth arithmetic: taps, clock and frame rate

A Base link moves 24 data bits per pixel clock; at 85 MHz, the pixel clock most Base receivers top out at, that is 24 × 85 MHz = 2,040 Mbit/s, about 2.04 Gbit/s of payload. Take a 2-tap camera at a 40 MHz clock over a 1392 × 1040 sensor:

• pixel rate = 2 taps × 40 MHz = 80 Mpx/s
• active pixels = 1392 × 1040 = 1,447,680
• frame time = 1,447,680 ÷ 80,000,000 = 18.1 ms
• frame rate = 1 ÷ 0.0181 s = 55.3 fps before blanking

The same numbers fall out line by line: one 1392-pixel line takes 1392 ÷ 80,000,000 = 17.4 µs, and 1040 lines take 1040 × 17.4 µs = 18.1 ms, so clock, taps and frame size agree. Budget 5 to 10 percent for blanking and the realistic ceiling is 50 to 52 fps; at 1-tap the same clock delivers 27.6 fps and a 36.2 ms frame. Run the clock as low as the process allows: a 25 fps requirement needs 25 × 1,447,680 = 36.2 Mpx/s, which is 18.1 MHz across 2 taps — half the example clock, and low clocks tolerate longer cables.

Before spending a day on the file, confirm the sensor has the pixels the task needs. Across a 100 mm field of view, 1392 pixels give 100 ÷ 1392 = 71.8 µm per pixel: a 0.25 mm feature spans 3.5 pixels and is measurable, a 0.1 mm feature spans 1.4 pixels and is not. The camera resolution calculator runs this check for any field of view, and if the count falls short, the area scan cameras finder lists higher-resolution Camera Link models.

Build and load the file

A Camera Link grabber such as the MV-GC1102IOL takes all of its acquisition timing from the loaded camera file; on the PC side, the file is the whole integration.

1. Copy the grabber vendor's generic Camera Link camera file to a new name in the camera-files directory the configuration tool reads.
2. Enter the pixel format and bit depth per tap exactly as the ICD states them: 8, 10 or 12 bits.
3. Enter the tap configuration and tap geometry in the builder's own wording, for example "2 taps, left and right halves", not a paraphrase.
4. Set the pixel clock to the ICD's typical value and leave the maximum alone until the link is proven.
5. Set frame valid, line valid and data valid polarity, with horizontal and vertical blanking at or above the camera's stated minimum.
6. Set the UART baud rate to the camera's value — 9,600 on most CCD-era cameras — with matching parity at both ends.
7. Load the file with the camera free-running at minimum gain, and confirm the tool reports the frame size you expect: 1392 × 1040 for this class.
8. Lay a straight edge diagonally across the field and capture one frame: an unbroken edge at pixel scale proves geometry and bit order.

Port the corrections before you trust the images

The correction functions in the header run inside the vendor's driver, so once pixels stream through your own camera file, nothing applies them. Rebuild the chain in host code, in this order: offset subtraction (the header called it readout shading removal), measured with the lens capped; a dark field — the average of 32 or more capped frames — subtracted per pixel; then a bright field, a frame under uniform light, divided into every image. The same header carried a bright-corner correction, for the corner glow some intensifiers produce.

For the division step, dividing one image by another for flat-field correction shows the operation in OpenCV. Re-shoot the dark frame after every gain change: an intensifier's hot pixels and spot pattern move with gain, and a stale dark frame prints them as signal.

Checks before you cable the machine

• Grabber configuration at least equal to the camera's: a Base camera on a Medium-capable port is fine, a Medium camera on a Base-only port is not.
• One straight-through Camera Link cable, SDR or MDR to match both ends; the LS-CBL-0191, a 5 m SDR-to-SDR cable, is the safe default at the example clock. Standard Camera Link cables are usually kept under about 10 m as clocks rise toward 85 MHz.
• For hardware trigger, land the grabber's I/O lines on terminals with the LS-CBL-0224, a 7 m DB9F-to-open cable. If you need a pulse source, a trigger pulse train without a function generator covers it.
• Serial baud equal at both ends before the first command leaves the host.
• Buffers and callbacks on the acquisition side: frame grabber image acquisition for Camera Link and CoaXPress.

When the file loads but the image is wrong

• Halves swapped or mirrored. The geometry field names the wrong zone order. Fix it by mirroring or swapping taps in the geometry field, never by re-cabling; Camera Link camera file not compatible: fix bit stream errors works through the variants.
• Alternating-column zipper. The camera interleaves pixels across taps while the file declares half-line zones; switch the geometry to interleaved.
• No image at all. Stop editing taps and check the link itself: frame grabber cannot detect video source first, then check the frame grabber cable wiring.
• Dropped or banded frames at speed. Blanking in the file sits below the camera's minimum, or the clock sits above the ICD's stated range.
• Posterized or clipped gray levels. Bit depth mismatch: a 10-bit camera read as 8-bit.

Checklist before the first good frame

• ICD or driver header in hand, with tap configuration and geometry written down — the field generators never guess.
• Bit depth per tap entered exactly as the ICD states it.
• Pixel clock at the typical value, not the maximum.
• Frame valid, line valid and data valid polarity set; blanking at or above the camera's minimum.
• UART baud matched at both ends before the first command.
• Dark and bright frames captured at working gain, re-captured after any gain change.
• A diagonal edge captured and examined at pixel scale: unbroken, halves aligned, no zipper.

When the builder's answer stalls, send the header to us on the contact page and we will pull the tap configuration out of it with you; expert support comes with every order. Complete the link from Camera Link frame grabbers and camera cables, or start at the accessories finder; more integration write-ups sit on the systems topic page.