The number of customer projects we've taken on in the last two years that needed twelve, fourteen, or sixteen cameras feeding a single edge AI box has grown steadily. Autonomous robotics, industrial inspection lines with surround-view requirements, automotive sensor test rigs, large-area surveillance arrays – the use cases differ, but the underlying bottleneck is always the same: how do you get that many high-resolution, low-latency video streams into a single NVIDIA Jetson without compromising on either the camera selection or the AI workload running downstream?
Thorium 16x GMSL2 is our answer. Sixteen GMSL2 channels, 40 Gbit/s of useful payload bandwidth, built around an NVIDIA Jetson – and, just as importantly, around the camera-driver and BSP ecosystem that we've integrated and stabilized for industrial production use.
This article walks through the technical reasoning behind the platform: why GMSL2 over FPD-Link, what the 40 Gbit/s number actually means in practice, and the honest reality of the camera-driver ecosystem under JetPack 7. If you're sizing a multi-camera edge AI system, this is what we'd want you to know before you commit to a stack.
GMSL2 (originally Maxim Integrated, now Analog Devices) and FPD-Link III (Texas Instruments) are the two dominant serializer–deserializer (SerDes) interfaces in automotive and industrial vision. Both transport high-bandwidth video over a single coaxial cable, both deliver power-over-coax to remote cameras, and both have forward-compatibility paths to faster successors (GMSL3 at 12 Gbps, FPD-Link IV at 16 Gbps).
On paper, the per-link numbers are similar enough that bandwidth alone shouldn't decide most architectures:
The real differences, in our experience designing systems on both, are in the ecosystem around the chip, not the chip itself.
Camera availability. GMSL2 has a broader and more mature ecosystem of off-the-shelf cameras from automotive Tier-1 suppliers, embedded vision specialists, and Asian sensor module manufacturers. If you need a 2 MP HDR camera with a specific lens mount and a published GMSL2 interface, you typically have more choices, shorter lead times, and a clearer path to second sourcing. FPD-Link III camera availability has been improving, but the long tail still lags.
NVIDIA Jetson support. This is the practical decider for edge AI platforms. NVIDIA's reference designs for Jetson AGX Orin and Orin NX include strong support for the MAX9296 and MAX96712 family deserializers, and the major GMSL2 camera vendors ship kernel drivers and device-tree overlays that integrate cleanly. FPD-Link III integration on Jetson is possible – we've shipped systems with it – but the glue work is heavier and the vendor-side support is thinner.
Future-proofing. Both interfaces have credible roadmaps, but GMSL3 backward-compatibility with GMSL2 is already proven in shipping silicon. For a platform we expect to sell for the next five-plus years, that mattered.
We chose GMSL2 for Thorium because of those ecosystem advantages, not because of a 2 Gbps difference in raw per-link bandwidth. If FPD-Link III's ecosystem turned out stronger for a specific application – for example, because of a Tier-1 supplier you're locked into – that calculus could flip. We're happy to make that recommendation when it's the right fit. The technology choice isn't dogma.
The 40 Gbit/s figure on the Thorium 16x spec sheet is the aggregated useful payload bandwidth across all sixteen channels what you can realistically push into the Jetson's video-ingest path after protocol overhead, line-coding, alignment, and metadata. Theoretical peak is higher; sustained payload is the number we publish, because it's the one that matters when you build a real system.
In practical multi-camera configurations, 40 Gbit/s translates roughly to:
One reality worth flagging: in multi-camera edge AI systems, the SerDes link is rarely the actual bottleneck. More often, it's downstream – ISP throughput on the Jetson, GPU and DLA capacity for the AI workload, memory bandwidth on the SoC. We size the link generously precisely so that it never becomes the constraint. The 40 Gbit/s headroom buys you the freedom to swap cameras, push higher frame rates, or add channels without redesigning the platform.
Anyone who has shipped a Jetson-based multi-camera product knows the hardest engineering problem isn't the SerDes chip or even camera selection. It's keeping the camera drivers, device-tree overlays, and JetPack updates working together over the lifetime of the product.
The situation we navigate continuously goes roughly like this:
NVIDIA releases JetPack on its own cadence. Major versions bring new kernel revisions, new BSP layers, sometimes new userspace APIs – Argus changes, V4L2 stack shifts, ISP behaviour adjustments. Camera vendors ship drivers and device-tree overlays for their products, but they release on their own cadence, typically two to six months behind a major JetPack release. Some vendors are fast; some are slow; some never quite catch up.
When you build a product on a bare vendor driver, every JetPack update is a potential break. Your customers want security patches and new features. The vendor driver isn't ready. You're stuck mediating between three parties.
For Thorium 16x, we've built an integration layer between the camera-vendor drivers and the application stack. It abstracts the camera-specific driver and device-tree details so that:
This integration work is, in our honest opinion, the single most underestimated engineering burden in commercial multi-camera edge AI systems. You can buy a great deserializer and a great Jetson and great cameras and still spend twelve months in driver hell. Thorium ships with that work already done.
The platform earns its complexity when you have at least eight cameras (below that, simpler integration paths are more cost-effective), you need synchronized capture across channels, and you're running real AI workloads on the Jetson, not just routing video for storage.
Typical fits we see:
Where it's overkill: single-camera applications, projects that just need a Jetson dev-kit equivalent, or environments where cable runs and power-over-coax don't earn their cost.
If you're sizing a multi-camera edge AI system and want to talk through the architecture before committing to a stack, drop us a line. We're happy to share what we've learned from the projects we've built, including the ones where GMSL2 turned out not to be the right answer. Fit beats dogma.