Hardware components | ||||||
| × | 1 | ||||
| × | 1 | ||||
| × | 1 | ||||
Software apps and online services | ||||||
 |
| |||||
From a short CSI ribbon to metres of coax carrying video, control and power.
Philipp Brechel · BE-IIS
A camera connected to a Raspberry Pi is a useful starting point for computer vision. A short ribbon cable carries the image data, camera control and power. You can place the camera on the desk, start an application and work on your idea.
Then the mechanical requirements change. The camera needs to sit at the front of a robot, above a conveyor or inside a small enclosure. The computer needs space, cooling and protection somewhere else.
This article shows how I use GMSL2 to separate the camera from the computer. The example starts with a familiar CSI camera, adds a serializer and a receiver, and keeps the image processing on the Raspberry Pi.
My aim with the BE-IIS platform is to reduce the work needed to try computer-vision ideas. Here, a lower cost mainly means less time spent building the camera connection before you can test the application.
On the usual Pi camera connection, MIPI CSI-2 carries the image data. I²C lets the host configure the sensor and control functions such as exposure or focus. Power and additional control signals share the same flex connector.
That is convenient over a short distance. For a prototype, a ribbon of a few tens of centimetres is a useful starting point. Around 30 cm is a practical scale to think about, rather than a universal CSI-2 length limit. The actual result depends on the cable, data rate and electrical design.
Choosing the right camera connectionShort distance – CSI ribbon cable
When the camera is close to the processor, a short MIPI CSI-2 flex cable is usually the simplest solution.
Medium distance – GMSL2
For distances of several metres, a SerDes video link such as GMSL2 is a good choice. With suitable hardware and cables, distances around 15 metres are possible.
Long distance – Ethernet
For longer distances or networked camera systems, Ethernet-based solutions such as GigE Vision are often a better choice.
These are overlapping options. Distance, bandwidth, synchronization and software all influence the choice. GigE Vision provides an established camera interface over Ethernet. AVB adds timing and traffic-management features to suitable networks; it is a different part of the system from the camera interface itself. www.analog.com
Here, I focus on the middle case: carrying CSI camera data over a dedicated video link.
What a high speed video link addsA serializer sits beside the camera. It receives the CSI-2 data and sends it over the cable. A deserializer beside the computer receives that stream and produces CSI-2 again.
Several suppliers offer this kind of technology, including Sony with GVIF, Microchip with ASA Motion Link, Texas Instruments with FPD-Link, and Analog Devices with GMSL. These are separate link families, each requiring a compatible pair of devices. Sony Semiconductor Solutions Group
I use GMSL2 from Analog Devices. It has public device documentation, automotive roots and upstream Linux support for several serializers and deserializers. The host kernel, sensor driver and board configuration still determine how a particular camera is integrated.
GMSL2 devices such as the MAX96717 provide a 3 or 6 Gbit/s forward link. Those numbers describe the link rate; usable image bandwidth is lower because the link also carries protocol overhead.
The cable also carries control traffic in both directions. Depending on the devices and board routing, this can include I²C, UART, SPI and GPIO. That allows camera configuration, focus control, trigger signals or control of camera-side lighting. The example here uses the paths needed by the camera, including I²C, reset and enable. www.analog.com
Power over Coax, or PoC, adds a DC supply to the coaxial cable. A filter at the receiver board feeds power into the cable while keeping the high-frequency link away from the power supply. A corresponding filter at the camera end takes the power out again.
With compatible hardware, one coax connection can therefore carry video, control and power. This simplifies the wiring of a remote camera head.
The PoC filters are part of the high-speed channel. Cable loss, connectors, PCB routing and the filters all affect the link. The supply also has to deliver enough voltage at the camera after the cable’s voltage drop.
The hardware used hereThe host board is the BE-IIS-GMSL2-2CAM. One MAX96716A deserializer receives two GMSL2 links and provides the CSI-2 outputs for the host. The Raspberry Pi example uses separate CSI inputs for the two cameras.
At each camera, a BE-IIS-GMSL-SER board with a MAX96717 connects the CSI camera to the coax. The reference software supports the Sony IMX708 sensor used in Camera Module 3 compatible modules.
For the two-camera setup, the main parts are a Raspberry Pi 5, one 2CAM board, two serializer boards, two IMX708 camera modules, two suitable coax cables, local CSI flex cables and the required power supplies.
The photographs show my Rev. A receiver. The currently sold Rev. B provides the same functions described here.
The receiver offers a selectable PoC supply for different camera voltage requirements. The nominal options are 5, 9, 12, 16 and 24 V; use the actual jumper settings and limits in the hardware documentation for your revision. The voltage selection is shared, with separate PoC enable options for the two links.
Set the PoC voltage to a value supported by the connected serializer or camera, allowing for the cable’s voltage drop. Check the hardware documentation for the exact remote board revision.
This detail makes the receiver useful beyond a stacked Raspberry Pi arrangement:
- MIPI CSI-2 and I²C use the flex connection.
- The board’s main power comes from USB-C or the 40-pin header.
Only the power connections on the 40-pin header are used. With USB-C supplying the receiver, that header can stay completely disconnected. USB-C is the power input here; the video still enters the computer through CSI.
The receiver can also sit beside the computer. That is useful when the host has a different board shape or connector placement, or when the space above its GPIO header is needed for something else.
Other Linux boards with CSI inputs are interesting targets for a port:
Raspberry Pi 5 – Tested and working
The reference platform used in this article. Both CSI interfaces are supported, allowing two independent GMSL2 camera connections. The software is available through the BE-IIS camera installer.
NVIDIA Jetson Orin Nano – Potential platform
The Jetson Orin Nano Developer Kit provides two 22-pin camera connectors. The hardware interface makes GMSL2 integration possible, but the camera driver, Device Tree and link configuration must be adapted to the Jetson camera software.
Arduino UNO Q – With UNO Media Carrier
The Arduino UNO Media Carrier provides two 22-pin CSI camera connectors.
The BE-IIS receiver can be placed beside the Arduino board and powered independently through USB-C. Camera software integration is still required. The existing Raspberry Pi installer cannot be used without modifications.
Renesas RZ/V2H – Potential platform
The Renesas RZ/V2H Robotic Development Kit provides two 22-pin CSI camera connectors.
Its camera interfaces make it an interesting option for industrial computer vision. The GMSL2 configuration and Linux camera integration need to be adapted to the Renesas platform.
The important point: The 40-pin Raspberry Pi header is not required for communication. MIPI CSI-2 and I²C use the flex connection, while USB-C can supply the receiver independently. This allows the same receiver hardware to be evaluated with different SBC platforms, even when their connector positions or board layouts differ.
Two terms appear frequently in GMSL2 documentation.
Pixel mode extracts the image payload from incoming CSI-2 packets and reconstructs CSI-2 packets at the receiver. Depending on the chosen devices, this gives flexibility to process or rearrange video streams.
Tunnel mode transports the CSI-2 packet content through the link while preserving its structure. For this prototype, that is a useful approach: after link setup, the host can continue to work with the image sensor through its camera software. ADI explains the distinction in its pixel and tunnel mode overview.Analog Devices
The goal is for the application to use the camera much as it would over a direct flex connection. Link initialization, I²C routing and compatible video timing are still required.
Lane conversion is not exclusive to pixel mode. The MAX96716A datasheet also allows different lane counts and rates at the two ends in tunnel mode. Two lanes at the sensor and four at the host can be possible if the selected devices and bandwidth allow it. www.analog.com
The transport mode and Linux integration are separate decisions. Representing the serializer and deserializer as V4L2 media subdevices is one software approach. The reference setup here uses tunnel mode, explicit link setup and the IMX708 camera driver.
Two software details that matteredGive the video path enough blanking timeThe original IMX708 timing did not work cleanly in the selected mode through this setup. The lower part of the image was corrupted.
The driver patch increases horizontal blanking: the time between active image lines. It updates both the sensor settings and the driver’s description of the line length. This gives the video path additional timing margin.
This is a specific fix for the tested IMX708 configuration. A different sensor needs a review of its own timing and driver behaviour.
Keep identical I²C addresses separateBoth IMX708 sensors use address 0x1a. The link setup gives them different upstream aliases, 0x52 and 0x53.
A small kernel routing and address-translation module creates a separate Linux I²C bus for each camera. It directs a transfer to the correct link and translates the native sensor address to that link’s alias.
Each sensor driver can then address its own camera in a familiar way. This is the I²C part of the setup; CSI routing and video streaming are configured separately.
From installation to the first imageThe current software is in the BE-IIS camera installer repository. For the Raspberry Pi reference setup with two IMX708 cameras, start with:
git clone https://github.com/be-iis/be-iis-cam-installer.git
cd be-iis-cam-installer
./install.sh
The installer may enable the camera I²C interface and reboot. If that happens, return to the repository directory and run ./install.sh again.
Then prepare the two links, configure the video path and start the dual preview:
make unoverlay
make prepare-a-b
make pipeline-a-b
rpicam-hello --list-cameras
make video-dual
Installation, link setup and capture are separate steps. That makes it easier to check where a problem occurs. The documented video mode is 2304 × 1296, RAW10, with two CSI lanes at 900 Mbit/s per lane. The manual setup guide contains the detailed sequence and diagnostics.
When adding another camera, first identify its image sensor and serializer. Check power and reset, confirm I²C access, then configure its CSI format and timing. An existing GMSL2 camera can be another starting point, provided its link mode, control scheme, power requirements and host driver fit the system.
What I tested over longer cablesOne important question is how far a GMSL2 camera can be placed from the computer.
I tested different cable lengths with my prototype and found that the cable quality and receiver configuration make a significant difference.
7.5 m – Reliable operation
The GMSL2 connection worked without problems in my prototype setup. No special adjustments were required.
10 m – Working with selected cables
A 10-metre connection also worked successfully. However, cable selection became more important, and I enabled the receiver's adaptive equalization through software to maintain a stable link.
Beyond 10 m – Possible, but more demanding
Longer distances are technically possible, but they require a carefully designed system. Cable quality, connectors, PCB layout, PoC filters and receiver settings must all work together.
In a dedicated product design, these factors can be optimized. In a flexible prototype setup, achieving the same reliability becomes increasingly difficult.
My recommendation for prototyping: Start with a short, known-good cable. Once the camera works reliably, increase the distance and check both the GMSL2 link status and the actual video stream.
A locked GMSL2 link confirms that the serializer and deserializer can communicate. It does not automatically guarantee that the image sensor is configured correctly or that valid video frames reach the computer.
For the 10 m case, the software enables the receiver’s adaptive equalization. The signal correction happens inside the deserializer. It helps the receiver deal with the channel’s frequency-dependent loss.
At greater lengths, the cable, connectors, PCB paths, PoC filters and device settings need to work together. ADI’s typical cable examples reach around 15 m at 6 Gbit/s for a suitable cable type, with shorter distances for higher-loss cables. That is a design reference rather than a promise for every assembled prototype. www.analog.com
A short, known-good cable is therefore useful for the first image. Once that works, increase the distance while checking link status and the actual image stream. A locked GMSL2 link confirms the transport connection; successful camera capture also depends on sensor setup and the CSI path.
A starting point for computer vision ideasThis platform lets me work on the application with the camera in the place where it needs to be. I can explore camera positions, collect images or compare two viewpoints while keeping the processing on a familiar SBC.
GMSL2 has details to learn, but a documented reference setup makes the first steps manageable. Reusing a known camera, a working driver and a practical connection leaves more time for the vision problem itself.
I would like to hear which cameras, host boards or applications you want to try. Feedback helps guide the next examples. If your idea needs a different interface or additional electronics, you can also get in touch through BE-IIS.
Comments