You need a small CSI camera module a few metres from the board that reads it — on a moving carriage, behind a sealed panel, outside the cabinet. The first question most engineers ask is which kernel driver the extension needs, and for the common CSI-over-Ethernet extension kits the answer is none. These kits are hardware transports: they carry the MIPI CSI-2 signal over Ethernet-style cable and hand the host exactly what a directly plugged module would present. This guide explains how that transport works, why no extra driver exists to install, what the cable can and cannot do at length, and when the honest answer is not a longer cable but a different camera interface. It is written for anyone integrating v1/v2/v3-class CSI modules on embedded Linux boards.
The kit is a transport, not a network
Despite the RJ45 plugs at both ends, the cable is not carrying network traffic. A CSI-over-Ethernet extension kit is a matched pair of adapters: the camera-side adapter presents the module's own connector, serialises its MIPI CSI-2 lanes and drives them onto the cable; the host-side adapter regenerates a standard CSI-2 stream and feeds it to the board's CSI receiver. The twisted pairs carry the kit's own line coding — serialised camera data — with no IP address, no MAC and no Ethernet frames anywhere in the link.
It is the same SerDes principle (serialise at one end, de-serialise at the other) that automotive designs use to carry an uncompressed remote camera over coax or shielded twisted pair to a processor several metres away.
Why the kernel needs no extra driver
Two pieces of software matter on the host, and the kit contributes neither. The first is the driver for the CSI receiver built into the SoC. The second is the driver for the sensor on your module, normally selected with a Device Tree overlay; these kernel trees carry both, the imx477 driver and its overlay being one documented example. The SerDes pair sits electrically between the sensor and the receiver, so the module still looks directly attached: the sensor driver probes it, attaches and streams exactly as it would over the short ribbon.
What you do on the software side is what you would do without the kit. Current OS images for these boards enable the camera interfaces automatically; on older images the raspi-config tool's Interface Options → Camera entry does it. Hunting for a kernel module that 'handles the LAN extension' chases software that does not exist. The same rule holds on bigger embedded hosts: integration work around a deserialiser is about its output mode matching the CSI-2 receiver, and the sensor driver still attaches as if wired. What a CSI receiver does and does not guarantee once the stream arrives is its own subject — see MIPI CSI-2 camera compatibility: beyond the connector.
What decides the length
CSI-2 lanes are low-voltage differential pairs specified for short on-board traces. A passive extension — a pin-for-pin cable with no electronics — is the same signal on a longer, ungoverned run, and its margin collapses within tens of centimetres. What to check before using one is covered in passive CSI extension cable compatibility: what to verify, and why long MIPI traces lose signal integrity explains the physics behind the limit.
A SerDes kit changes the problem: the data is re-clocked onto one controlled differential pair designed for cable, so the rating comes from the kit's line rate and the cable type rather than from CSI-2. Automotive links of this class carry uncompressed camera data over coax or shielded pair for metres to tens of metres, and kit makers publish ratings in that range. Buy the rating with margin for flexing and a noisy cabinet: a run at the stated maximum leaves nothing for a splice or a drag chain.
Past the kit class — tens of metres out to the 100 m a standard 1000BASE-T run gives you — no CSI link competes. That is real Ethernet territory, covered in choosing an M12 X-coded Ethernet extension for vision, and it needs a camera that speaks Ethernet natively.
Worked example: what the link must carry
Take a module streaming 1920 × 1080 pixels at 30 fps in RAW10. CSI-2 packs RAW10 as four pixels in five bytes, so each pixel costs 1.25 bytes on the wire:
That 622 Mbit/s is the uncompressed payload the serialiser must sustain at lane rate, frame after frame. It is why the kit wants the whole cable to itself, why a marginal run shows corrupted or striped frames rather than a slower picture, and why the stream cannot be routed through network equipment.
The pixel format moves the number, too: the same frames in RGB888 cost three bytes per pixel — 62,208,000 × 3 B = 186,624,000 B/s, about 186.6 MB/s or nearly 1.5 Gbit/s. Compute your module's worst case — full resolution, full frame rate, real pixel format — before you conclude a link is faulty.
Where a kit fits, and where it does not
A kit is the right tool when the board must stay where it is safe and serviceable — a cabinet, a control box — while the camera sits at the machine: on a carriage, behind a panel, inside a sealed fixture. The link is point-to-point: one serialiser, one cable, one camera, one CSI receiver. The module needs power at the far end, injected by the kit or fed separately; confirm which before you route the cable, because it decides the supply you need at that end.
It is the wrong tool when the host has no CSI receiver at all — an industrial PC, a frame grabber, a controller class where the choice between CSI and USB is already settled, as laid out in CSI versus USB camera connections on controller-class hardware — or when the run exceeds the kit's rating, or the camera count outgrows the board's CSI connectors. Those cases need a different interface, not a longer cable.
Three ways to move the camera away from the board
The choice reduces to three options, and the driver question answers itself in all three:
| Passive extender cable | SerDes extension kit | Change the interface | |
|---|---|---|---|
| How the data moves | same CSI-2 on a longer run | serialised in hardware over the cable | camera speaks GigE or USB3 natively |
| Reliable distance | tens of centimetres | the kit's rating: metre-class, tens of metres in automotive-style designs | 100 m per 1000BASE-T run (GigE); about 3 m (USB3) |
| What the host sees | the module, directly on CSI | the module, still on CSI | a network or USB camera device |
| Extra driver | none | none | the stack the camera ships with |
| Choose it when | the run crosses a hinge or door inside one housing | the board stays in a cabinet, the camera at the machine | the host has no CSI port or the run is network-length |
Checks before you fit
Work the list in order; each item kills one class of failure:
- Match the kit to the module: connector, sensor family and lane count. The camera-side adapter carries one pin-out; it does not adapt between module families.
- Confirm the sensor driver and overlay exist for your host image. This is the only software question the kit raises.
- Put the rated length above your measured route with margin for routing, flexing and a future re-route; treat the maximum as a limit, not a target.
- Confirm how the far end is powered — through the kit or by a separate feed — and size that supply before the cable goes in.
- Keep the run one continuous cable between the matched adapters. Every RJ45 joint in the middle is an impedance break.
- Prove it with minutes of continuous video at the working resolution, not a single still.
What a failure looks like
Three symptoms cover nearly everything, and none of them is a missing LAN driver:
- No camera detected. Check seating at both adapters, the far-end supply, and that the overlay names your sensor. The host-side checks are the same as for a direct module; work through MIPI CSI camera no images: troubleshoot acquisition.
- Striped, torn or corrupted frames. The link is at its length, noise or format limit. Capture at a lower resolution or frame rate: if that cleans the image, shorten the cable or move it away from the noise source.
- Runs, then times out. A supply that sags or an adapter that heats. The failure pattern matches what to do when a CSI camera times out after a working period; start with the supply measurement.
When the right answer is a different camera
If the far end of the cable is an industrial host, no kit will help, because there is no CSI receiver to present the stream to. Choose the interface first, then the camera. For a compact remote head on a real network run, a GigE board-level camera does the job: the MV-CB016-10GM-M-W is a 1.6 MP GigE board-level camera with an M12 lens mount and a global shutter.
- Sensor format
- 1/2.9"
- Lens mount
- M12
- Interface
- GigE
- Resolution
- Up to 3 MP
Pair it with cable built for the machine, not the office: the LS-CBL-0199 is a 3 m high-flex GigE camera cable with screw locks, rated for drag-chain use.
When the host sits within USB3 reach, a board camera on that interface avoids the network stack entirely: the MV-CB060-10UM-B is a 6 MP USB3 board camera on a bare board, mono, built on the IMX178 sensor.
- Sensor format
- 1/1.8"
- Interface
- USB3
- Resolution
- 6-10 MP
- Shutter
- Rolling
For full machine-vision duty — C-mount optics, industrial triggering, a housed sensor — start from the area scan cameras instead, and pick the data cable for the route in the camera cables category; the shop's cable finder filters them by length. If you would rather browse modules first, the board-level cameras page lists the boards that build into a machine, GigE and USB3 alike.
Next step
If the run ends at an embedded board, match the kit to the module, respect the rated length and expect no driver work. If it ends at a PC, pick the interface before the cable: the configurator below starts at the camera step, and the systems integration articles cover the rest of the chain from trigger to host software.
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
Questions
Does a CSI-over-Ethernet extension kit need its own kernel module?
No. The kit is a hardware transport: it serialises the camera's MIPI CSI-2 lanes onto the cable and regenerates them at the host, so the kernel sees a normally attached module. The only software that matters is the sensor driver and overlay your module already needs, which current single-board-computer OS images carry out of the box. There is no LAN-side module to compile, because the cable carries no network protocol.
Can I put a switch or coupler in the extension run?
No. The RJ45 connectors carry the kit's own serial camera signal, not Ethernet frames, so a switch has nothing to forward and the link stays down. An inline RJ45 coupler breaks the controlled impedance the serial pair expects and puts a connector in the middle of a run that should have none. Use one continuous cable of the type and length the kit is rated for, and keep the two adapters as a matched pair.
How long can a CSI camera cable actually be?
Three regimes. A passive pin-transfer cable is good only for tens of centimetres, because CSI-2 lanes are specified for short on-board traces. A SerDes kit covers its own rating: metre-class runs, and tens of metres in automotive-style designs over coax or shielded twisted pair. Beyond that, only a camera that speaks Ethernet natively spans the 100 m of a standard 1000BASE-T run.
The camera works on a short ribbon but not behind the kit — what do I test first?
Shorten the link first; it is the fastest discriminator between a marginal run and a software problem. Second, measure the module's supply at the camera-side adapter, because voltage drop over the cable mimics a dead sensor. Third, capture at a lower resolution or frame rate: if that stabilises the image, the link is at its length or noise limit, not missing a driver.
Can I run two cameras over one extension kit?
No. Each link is point-to-point: one serialiser, one cable, one deserialiser, one camera. Two remote cameras on one board need two kits and two CSI receivers. When the camera count outgrows the board's CSI connectors, that is the point to move those cameras to native Ethernet, where a switch serves many cameras over one long run.