GMSL3 vs GMSL2: Understanding GMSL Technology for Industrial Edge AI

GMSL3 is the third generation of the Gigabit Multimedia Serial Link, a serialiser–deserialiser (SerDes) interface that carries up to 12 Gbps of uncompressed camera or sensor data, plus power and control signals, over a single coaxial or shielded twisted pair cable. It doubles the 6 Gbps of GMSL2, which is the generation most industrial cameras and Jetson computers use today, and GMSL3 parts can run GMSL2 links so the two can share a system.

GMSL was first created by Maxim Integrated in California. Analog Devices acquired Maxim in 2021 and has continued the technology since. It was designed for cars, where cameras, radar and displays sit meters from the processor, but GMSL is now common in automated guided vehicles (AGVs), collaborative robots (cobots), autonomous mobile robots (AMRs), agricultural and off-highway machines, and inspection systems.

High-speed sensor links matter because edge AI computers such as NVIDIA Jetson systems process camera streams in real time, and the model can only be as good as the frames that reach it. This guide explains what changes from GMSL2 to GMSL3, how much bandwidth each carries, how far the cables run, how GMSL reaches a Jetson from Orin to Thor, and what makes the integration hard. For the camera side, including the Stereolabs ZED X, see our guide to the GMSL camera interface.

“GMSL is a high-performance, high-speed interface recognized for its high data rates, low latency and reliability, making it especially valuable in automotive and robotics applications. While features such as Power-over-Coax bring clear benefits, complex system and software integration remain a significant challenge. We work closely with both industrial edge AI computer and camera manufacturers to simplify this integration and help customers accelerate their time-to-market.” Andrew Whitehouse, CEO at Things Embedded

The table compares the three generations. Figures come from Analog Devices’ published device and channel information and are typical; individual parts vary, so check the data sheet of the exact serializer and deserialiser.

In practice the step from GMSL1 to GMSL2 was the big change for industrial users: a protocol built on packets rather than a fixed video bus, a much faster reverse channel and support for several video streams on one link. GMSL3 keeps that architecture and doubles the rate. That is why the device tree and driver approach used for GMSL2 carries across, and why a GMSL3 system can usually reuse GMSL2 cameras where they are fast enough.

GMSL3 is a point-to-point serial link between a sensor and a processor. A serializer beside the image sensor takes the sensor’s MIPI CSI-2 output, packs it into a high-speed serial stream and drives it down the cable. A deserialiser on the computer side recovers the stream and presents it to the processor as MIPI CSI-2 again, so the processor sees what looks like a local camera even when the sensor is several meters away.

Analog Devices positions GMSL3 for the cameras and displays that GMSL2 cannot carry at full rate: sensors of 8MP and above at high frame rates, cameras with several exposures for high dynamic range, and links that aggregate more than one sensor. Its parts are designed to support ISO 26262 functional safety, with many devices rated to ASIL-B, which matters for driver assistance and is increasingly asked for in mobile robots and off-highway machines that share their safety case.

The reverse channel stays at 187.5 Mbps. That is ample for what flows back towards the camera: I²C or UART register writes, frame-sync triggers, GPIO and occasional firmware updates.

GMSL3 runs at up to 12 Gbps in the forward direction, twice the 6 Gbps of GMSL2. The useful payload is a little lower, because the link carries packet headers, error checking and blanking as well as pixels, so it is sensible to plan on 80–90 % of the line rate for video.

The easiest way to see where GMSL3 is needed is to work out what a camera produces. Uncompressed video needs width × height × bits per pixel × frames per second. The table uses RAW12, a common output for automotive and machine vision sensors, and YUV 4:2:2 at 16 bits per pixel for cameras that process the image on board.

Worked example. An inspection gantry needs 4K images at 60 fps to catch defects on a moving web. Each camera produces about 6 Gbps before overhead, more than a GMSL2 link carries, so the choice is GMSL3, a lower frame rate, a smaller region of interest or compression on the camera. For a mobile robot with 2.3MP global shutter stereo cameras at 60 fps, GMSL2 has headroom and remains the practical choice. Our explainer on global shutter vs rolling shutter covers why those robot cameras favor lower-resolution global shutter sensors.

Bandwidth at the processor matters too. Each deserialiser output feeds MIPI CSI-2 lanes on the host, and four GMSL3 links into one deserialiser can deliver more data than one CSI-2 port accepts. Check the host’s MIPI CSI-2 lane count and lane rate before planning several high-rate cameras on one board.

GMSL carries video uncompressed, which is what keeps latency low and image quality unchanged. A serializer (SerDes) takes the data from the sensor and converts it into a high-speed serial stream, which is sent in packets over the cable. At the receiving end a deserialiser reconstructs the packets so the embedded computer can process the data. Once received, the video can be used in applications such as driver assistance, precision agriculture, environmental monitoring and autonomous navigation.

GMSL2 and GMSL3 are full duplex. Alongside the video, the same link carries control commands, synchronization signals, touch and haptic data on display links, software updates and status messages, using tunnelled I²C, UART and SPI. Power over Coax (PoC) adds the camera’s supply, so one coaxial cable does the work of three or four separate wires. That reduces system cost and improves reliability, because cables and connectors are common points of failure.

Because the link carries an exact copy of the sensor’s CSI-2 output, the host does not decode anything. That is the main difference from GigE Vision cameras, which packetise frames for an Ethernet network and need the host to reassemble them.

Yes, in the sense that matters for most projects. GMSL3 serialisers and deserialisers can run GMSL2 link modes at 6 or 3 Gbps, so a GMSL3 deserialiser board can take GMSL2 cameras, and a GMSL3 camera can run in a GMSL2 mode on a GMSL2 board at the lower rate. Compatibility is set per part and per link, so it is checked against the exact devices rather than assumed.

Two rules hold across every generation. The serializer and deserialiser must be compatible parts, normally from the same family and configured for the same mode, and the deserialiser’s CSI-2 output must suit the host processor. A link that never locks is very often a mode mismatch rather than a fault.

Typically up to about 15 m, the same headline reach as GMSL2, but the margin is smaller. A GMSL link is limited by how much signal the cable, connectors and any in-line joints lose at the link’s frequency, not by a fixed length. Analog Devices publishes channel specifications for GMSL2 and GMSL3 (application note AN-2585 and the GMSL3 channel specification user guide) that set limits for insertion loss, return loss and crosstalk across frequency. If the whole channel stays inside those limits, the link is within specification at whatever length that allows.

GMSL3 signals at higher frequencies than GMSL2, and coax loses more per meter as frequency rises. In practice that means a cable that just passes at 6 Gbps over 15 m may need a lower-loss type, fewer in-line connectors or a shorter run at 12 Gbps. Shielded twisted pair is also supported and suits some harnesses, usually over shorter distances than good coax.

Most GMSL2 cameras in our range use Z-coded FAKRA connectors, which lock positively and are keyed so a camera cannot be plugged into the wrong port. Multi-port boards often use quad or mini FAKRA housings to save panel space. Many GMSL3 designs move to newer automotive connectors with more bandwidth, so check that the camera, cable and computer connectors match before ordering. For sealed outdoor systems, the connector also has to keep the computer’s IP rating; our IP rating chart explains the levels.

Jetson modules have no GMSL input of their own. They take MIPI CSI-2, so GMSL reaches a Jetson through a deserialiser on the carrier board or on a capture card that connects to the carrier’s camera connector. Jetson AGX Orin has 16 CSI-2 lanes and the most room for camera streams; Jetson Orin NX and Orin Nano have 8. Virtual channels let several cameras share each CSI-2 port, which is how eight GMSL2 cameras reach an AGX Orin.

With Jetson Thor, NVIDIA adds a second camera path. Thor keeps MIPI CSI-2 inputs, and it also takes sensor data over Ethernet through the NVIDIA Holoscan Sensor Bridge, which packetises camera data and delivers it over high-speed Ethernet into GPU memory. That lets camera links run further and lets one Thor system collect many sensors. Holoscan Sensor Bridges with GMSL2 inputs bridge existing GMSL cameras onto that path.

Does Jetson Thor support GMSL3? The Thor computers in our range currently offer eight GMSL2 inputs as a factory option, and GMSL2 covers the robot and vehicle cameras most projects use. GMSL3 deserialiser boards for Thor are appearing from carrier and camera makers as GMSL3 cameras arrive. Because GMSL3 deserialisers also run GMSL2 links, a Thor design that needs GMSL3 later can usually keep its GMSL2 cameras. If GMSL3 is on your roadmap, tell us the camera and we will check the deserialiser, driver and JetPack release before you commit.

Software support follows the deserialiser, not the GMSL generation. Each board needs a kernel driver for its deserialiser and a device tree that matches its wiring, built for the exact JetPack release. Our guide to choosing a Jetson carrier board covers the other connectors and I/O to check at the same time.

Despite its strengths, GMSL is more complex to integrate than USB or Ethernet. Developers often face hurdles with virtual channels, addressing and timing, which require careful attention to both hardware configuration and software. The serializer and deserialiser must be matched, and the deserialiser must be compatible with the host processor and its MIPI CSI-2 output format. These are the four areas where projects most often stall.

Synchronization matters most in multi-camera systems. When several sensors share one CSI port, mismatched lane configurations or asynchronous modes can cause data loss or misread signals, which shows up as image flicker during scene transitions or poor sensor calibration. Some systems also align cameras with LiDAR and GNSS using a pulse-per-second input or Precision Time Protocol, and our paper on IEEE 1588 for machine vision covers that side.

This is integration work rather than product selection. We configure, image and test every GMSL system with the customer’s cameras and cable lengths connected, confirm that each camera enumerates and that sync holds across the array, and ship it with the drivers in the operating system image. Our paper on PoE power budgeting for multi-camera edge AI covers the IP camera alternative, where power rather than bandwidth is often the limit.

GMSL comes from the car, so the silicon is built for heat, vibration and electrical noise. The computer around it has to match. These are the industrial checks we make alongside the camera link itself.

For vehicles, see our in-vehicle computers; for sealed outdoor systems, our rugged Jetson computers are the usual starting point. Our Jetson thermal design guide explains how sealed GMSL computers hold full AI performance in the heat.

GMSL is one of several ways to get a camera onto an edge AI computer. Each suits a different distance, bandwidth and cost. Our GMSL camera interface guide, linked above, compares them in more depth with Stereolabs ZED X cameras as the worked example.

These systems cover the main GMSL setups, from a single camera on an Orin Nano to eight cameras on Jetson Thor. All are GMSL2 today. We fit the deserialiser drivers, configure the device tree for your cameras, image the operating system and test capture and sync with your cable lengths before the system ships.