Direct CSI-2 into SoC / ISP

When my camera sensor board lives in the same cabinet as the controller, I try to keep the link as simple as possible and run MIPI or CSI-2 straight into the SoC or a dedicated ISP. This works best when the flex or board-to-board connection is only a few tens of centimetres, the data rate per lane is within what the SoC can comfortably handle, and the cabinet is not sharing space with high-noise drives or welders.

I also decide early whether I rely on the SoC’s internal ISP pipeline or keep an external ISP in the chain. An internal ISP keeps the BOM and latency down, but an external ISP gives me more freedom to mix different sensors, upgrade image quality later and offload heavy processing from the main CPU. At the same time I confirm if I am locked into D-PHY, C-PHY or both and match that to the sensor and CSI-2 receiver.

• I keep sensor–SoC distance short and inside the cabinet wherever possible.
• I check D-PHY / C-PHY support on the sensor and SoC or ISP before I pick parts.
• I decide now if I need an external ISP and a simple clock generator or PLL for CSI-2.

MIPI to LVDS / parallel / HDMI / PCIe bridges

In many industrial projects my camera choice moves faster than my controller platform. I end up with a modern CSI-2 camera module but a legacy CPU or vision card that only accepts LVDS, parallel RGB, HDMI or PCIe. In those cases I drop in a CSI-2 bridge IC between the sensor and the controller, and treat that bridge as a first-class device in my signal path and BOM.

For each bridge option I pay attention to lane count, per-lane bitrate and whether the device has enough internal FIFO to absorb bursty traffic and clock-domain differences. I also check the jitter and clocking requirements because many bridges expect a clean reference from a dedicated PLL or clock generator. Thermal behaviour, package size and industrial temperature range matter too when I pack the bridge close to the connector.

• I match bridge lane count and bitrate to my sensor resolution and frame rate.
• I confirm the bridge’s output format lines up with my LVDS, HDMI or PCIe input.
• I budget for a CSI-2 bridge IC plus any clock generator or PLL it requires.

Layout and signal-integrity checklist

No matter which CSI-2 topology I use, the layout will decide whether the link is solid or fragile. I keep the differential pairs tightly coupled, matched in length and routed over a continuous reference plane, and I avoid unnecessary layer jumps or gaps under the traces. I also keep DC-DC switches, motor gate-drive traces and other noisy nets away from the CSI-2 clock and data lines to protect eye margin and jitter.

For ESD and surge protection I place low-capacitance ESD arrays close to the connector that sees cable-related transients, and only add extra protection near the sensor if it is truly needed. I also reserve good decoupling and quiet supply rails for the CSI-2 receiver, ISP and any clock generator or PLL, so that supply noise does not translate into timing problems.

• I route CSI-2 pairs with controlled impedance, tight coupling and matched length.
• I place low-cap ESD arrays near external connectors, not buried in the middle of the link.
• I give CSI-2, ISP and clock ICs clean power and ground to keep jitter and errors under control.

When I need SerDes instead of pure MIPI

I stop trying to stretch raw CSI-2 as soon as the camera leaves the cabinet and heads out onto a moving robot arm. Drag chains, rotating joints and several metres of cable quickly push MIPI beyond what it was meant for, especially when the arm runs close to servo drives, VFDs or welding equipment. At that point I treat the camera head as a remote node and plan around a dedicated SerDes link instead.

SerDes devices such as FPD-Link or GMSL let me carry high-speed video over coax or shielded twisted pair while embedding control, I²C and even trigger GPIO in the same link. I choose this route when I need metre-scale cables, robust EMI performance and the option to treat the camera module as a field-replaceable unit rather than a fragile extension of my main PCB.

• I move to SerDes when cable length and motion make raw CSI-2 unreliable.
• I consider surrounding drives, VFDs and welders when I decide on link type.
• I treat the camera head as a remote node with its own SerDes Tx and power budget.

FPD-Link / GMSL link architecture

A typical FPD-Link or GMSL path in my robot cell has a SerDes transmitter next to the sensor and AFE, a single coax or shielded twisted pair running through the arm, and a SerDes receiver in the cabinet that outputs CSI-2 or LVDS into my ISP or SoC. On top of video, the link can tunnel I²C control and GPIO so I can configure the sensor and drive triggers without extra cables. Some devices also support power-over-coax, which can simplify wiring but needs careful power and fault planning.

When I choose between coax and shielded twisted pair, I balance EMI robustness, cable cost, flexibility and what my cable supplier can actually deliver in a drag-chain friendly form. I also confirm that the SerDes receiver output format matches the input of my ISP or SoC, and decide early whether I rely on PoC or bring a separate power pair up the arm for simplicity.

• I map SerDes Tx/Rx formats to the CSI-2 or LVDS inputs on my ISP or SoC.
• I choose coax or shielded twisted pair based on EMI, flexibility and supply chain.
• I decide up front whether to use power-over-coax or a separate power feed.

Cable, connector and EMC notes

With SerDes links the cable and connector family are part of my IC choice. I define a specific coax or shielded twisted pair that can survive repeated flexing in the drag chain, and I make sure the connectors lock firmly and keep the shield intact. I decide where the cable shield bonds to chassis and how that relates to my PCB ground so that I do not accidentally create noisy ground loops or leave the shield floating where it should not.

Around each SerDes connector I place common-mode chokes and TVS or ESD diodes close to the pins that see the outside world. Surge and ESD currents should find a very short path to the reference they return to, not wander across my whole board. I also try to keep the SerDes devices and their reference clocks a little distance away from the noisiest power electronics in the cabinet.

• I pick cable and connector families together with the SerDes devices.
• I place CM chokes and TVS diodes close to the external SerDes connectors.
• I agree on shield grounding with the mechanical team before layout, not after.

Multi-camera and daisy-chain considerations

If I ever use one SerDes link to serve multiple cameras, either by daisy-chaining modules or using an aggregator, I treat bandwidth and timing as first-class constraints. The total data rate from all sensors must stay within the SerDes and CSI-2 budget with margin, and I need a clear story for how triggers and frame timing will be aligned, which I refine later in the synchronization section of this page.

I also think through fault cases: if one remote module fails, shorts the link or loses power, does it take out every camera on that chain or just itself? That answer needs to be reflected in both the electrical design and the safety or maintenance plan for the robot cell.

• I check worst-case aggregate bandwidth when multiple cameras share a link.
• I plan trigger and timing at the same time as I plan daisy-chain topology.
• I document how a single-module fault affects the rest of the SerDes chain.

Where GigE Vision & PoE fit in my robot cell

I reach for GigE Vision and PoE cameras when I want my robot cell cameras to behave like standard network nodes, not custom point-to-point links. They make sense when cameras are spread across several stations, when I need to share images with an upper-level IPC or server, or when the end customer has already standardised on GigE Vision hardware and tools.

Compared to a dedicated SerDes link, a GigE Vision + PoE camera is easier to plug into industrial or TSN switches and IT infrastructure. I trade some determinism for a mature ecosystem, familiar cabling and simpler maintenance. In practice I treat each camera as its own IP endpoint with a PoE class, a power budget and a configuration profile, and plan my cell topology around the switch ports I have available.

• I use GigE / PoE when cameras need to plug into standard industrial or TSN switches.
• I keep SerDes for cabinet-local, tightly real-time links that do not need network reach.
• I treat each GigE camera as a network node with its own IP, PoE class and config.

PHY, magnetics and isolation path

On the electrical side I think of the Ethernet path as a fixed ladder: RJ45 connector, magnetics and isolation, ESD and surge protection, the GigE PHY, and finally the MAC in my switch or SoC. The magnetics define the isolation barrier and the PHY lives on the local ground side, so I keep those pieces physically tight and route the differential pairs with short, symmetrical traces and a clean reference plane between magnetics and PHY.

When I connect to an industrial or TSN switch I pick a PHY rated for industrial temperature, with EMC performance that matches my test plan. I place TVS or ESD diodes near the RJ45 pins that actually see the outside world, and I make sure their return path to chassis or local ground is short and intentional instead of wandering across the board. From there I treat the PHY, its clock and its power rails like any other high-speed mixed-signal block.

• I group the RJ45, magnetics, ESD and PHY as a compact, well-routed interface cluster.
• I choose a GigE PHY with the right temperature range and EMC behaviour for my cell.
• I keep ESD and surge paths short and clear between the connector, magnetics and ground.

PoE power classes & power budgeting

With PoE I start by adding up the real loads I plan to hang off the cable: the camera core, any built-in or external LED illumination, and small local I/O such as strobes or triggers. I map that to a PoE power class and then leave margin for efficiency losses, surge events and future headroom instead of running the link right at its limit. Higher classes can cover bright lighting or heated enclosures, but they drive thermal design and cable current as well.

On the board I rely on a PoE PD controller to negotiate class, manage inrush and hand power off to a hot-swap FET or eFuse. Downstream of that I use one or more DC/DC converters to feed the camera electronics, illumination driver and I/O rails. I also protect the PD front end with surge components and make sure the return paths for surge currents are short and well defined so that events do not disturb the GigE PHY or sensitive analog front-ends.

• I add up camera, illumination and I/O loads before I pick a PoE power class.
• I use a PoE PD controller plus a hot-swap FET or eFuse to manage inrush and faults.
• I leave thermal and surge margin instead of running the PoE budget at 100%.

Trigger options

When I plan multi-camera timing I first decide how exposure is triggered. The simplest option is a dedicated hardware trigger line, typically a GPIO-level signal that fans out from a controller to each camera. It is easy to understand and can be very low latency, but cable length, RC delay and ground differences can quietly stretch or skew the edge if I am not careful about routing and terminations.

Many SerDes and GigE Vision cameras also support embedded triggers over the link itself, either via sideband GPIO channels or protocol messages. At the highest level I can base exposure timing on a shared time reference such as IEEE 1588 PTP over TSN, where each camera exposes at a given absolute time. The detailed PTP and TSN configuration lives in my network design, but here I treat these options as three different ways of getting a consistent exposure instant across sensors.

• I only rely on plain GPIO triggers when cable lengths and grounds are under control.
• I confirm that my SerDes or GigE cameras actually support the trigger modes I plan.
• I treat PTP / TSN as a system feature and plan it with whoever owns the network.

Clock tree & jitter considerations

Behind every trigger scheme there is a clock tree. My sensors need a stable pixel or frame clock, my SerDes links depend on reference clocks and PLLs, and my ISP or SoC runs on its own system clock that timestamps frames and runs the control loop. I sketch how these clocks are related before I place oscillators, so I know where I want a shared clock generator and where it is acceptable to let devices free-run and be aligned in software.

Clock jitter and skew show up as eye margin loss on high-speed links and as timing error in exposure or sampling. For applications that need sub-millisecond or even sub-frame alignment, I treat jitter cleaner ICs and proper layout as part of the timing budget, not afterthoughts. I also align my choice of clock frequencies with what the sensor, SerDes and ISP actually support so I do not end up fighting fractional dividers and awkward ratios later.

• I draw a simple clock tree before I commit to oscillators and generators.
• I use clock generators or jitter cleaners when the SerDes or sensors demand it.
• I budget clock skew and jitter into my multi-camera timing margin up front.

Typical multi-camera sync topologies

In practice I end up using a small set of synchronization topologies. Sometimes one camera acts as a master and forwards a trigger to other cameras that run as slaves, which works well for two or three sensors in a compact cell. In larger systems the robot controller, PLC or FPGA is the timing master and drives hardware trigger lines or link-level trigger commands to every camera.

In TSN or PTP-based designs I rely on a shared time base instead: the controller or time grandmaster tells each camera to expose at a given time, and the cameras align themselves based on that common clock. No matter which topology I pick, I still have to account for sensor and ISP pipeline delay differences, and I often need a calibration step to line up the effective frame timing across all views.

• I declare one device as the timing master and document that choice clearly.
• I include sensor and ISP pipeline delays in my timing model, not just trigger edges.
• I only rely on software alignment when I know my hardware timing errors and margins.

Common timing traps I try to avoid

• I do not treat trigger as “just a GPIO” and ignore cable length and RC delay.
• I do not assume cameras are aligned just because they see the same trigger edge.
• I do not skip measuring sensor and ISP latency when I need sub-millisecond sync.
• I do not push all timing fixes into software without a clear hardware timing model.

Local DC/DC for camera and SerDes

• I plan a dedicated buck and LDO tree for the camera head instead of tapping random rails from the robot controller.
• I give sensor analog rails, SerDes PLL rails and clock generator rails the quietest supplies I can, often DC/DC followed by an LDO or small RC filter.
• I keep noisy switcher nodes and inductor currents physically away from CSI-2 pairs, SerDes/GigE traces and crystals.
• I define a clear power-up sequence so the sensor, SerDes and ISP never sit in half-powered states that are hard to debug.
• I set brownout thresholds and reset behaviour for the camera head so undervoltage leads to a clean restart, not random lockups.
• I consider how much local decoupling and bulk capacitance the arm-end board needs to ride out cable drops or PoE transients.

Isolation strategy

• I decide early whether the camera head shares ground with the controller or needs galvanic isolation because of safety or ground shift.
• I treat Ethernet magnetics as the main isolation barrier for GigE and PoE, but still plan surge paths and shield bonding around that boundary.
• I do not assume that a differential SerDes link alone solves all isolation needs; I still check power and safety requirements.
• I isolate trigger, safety and control lines with digital isolators or isolated GPIO when ground potential differences or safety standards demand it.
• I budget the propagation delay and edge shaping of digital isolators into my timing paths, especially for tight trigger alignment.
• I plan isolated DC/DC supplies for any logic or sensor rails that sit across an isolation barrier so both sides power up cleanly.
• I keep isolation gaps, creepage distances and any Y capacitors consistent with the voltage and standard I am designing against.

EMI, ESD & surge checklist

• I pick low-capacitance ESD arrays for MIPI / CSI-2 pairs and place them close to external connectors with very short return paths.
• I add common-mode chokes, TVS and surge protection on SerDes cables that run alongside drives, welders or VFD cables.
• I define how shields and cable screens bond to chassis and PCB ground so return currents do not wander across sensitive areas.
• I treat the GigE RJ45, magnetics, PoE PD front end and TVS diodes as one protection cluster and keep their paths compact.
• I check ESD and surge ratings of my TVS, PoE PD and interface parts against the IEC 61000-4-x tests specified for the machine.
• I separate high-di/dt power loops and motor cables from camera, clock and reference traces at both the arm and cabinet side.
• I verify in layout that filters, chokes and protection devices sit where I intended, not scattered by later routing tweaks.

How I describe my camera interface to suppliers

When I talk to suppliers, I describe my camera interface in practical terms: how many cameras I have, the resolution and frame rate, the cable length and type, the EMI and temperature environment, and whether I am using PoE or separate 24 V rails. I also mention if I need sub-millisecond multi-camera sync and which standards apply, such as TSN features or IEC 61000-4-x immunity levels.

• I state the number of cameras, their resolution, frame rate and approximate data bandwidth.
• I state cable length, routing (drag chain or fixed) and whether I use coax, STP or Ethernet.
• I state the power scheme (PoE class or 24 V / 48 V), ambient temperature and nearby noise sources such as drives or welders.
• I state any sync requirements, safety standards and EMC tests so device suggestions are realistic for my robot cell.