Building a Low-Latency Endoscopic Camera System

There is a moment during minimally invasive surgery when everything depends on the camera. The surgeon is working entirely from what appears on the monitor, and any delay between the endoscope’s movement and the corresponding on-screen shift is not just an inconvenience. It disrupts the surgeon’s spatial awareness of a cavity that they cannot see directly. It is clinically accepted that the latency for glass-to-glass in surgical previews should not be more than 50 milliseconds. When latency exceeds that threshold, vital patient feedback loops break down.

When our team was recently engaged to design an endoscopic camera system for minimally invasive procedures, that 50 ms ceiling was the non-negotiable starting point, alongside it came two other hard requirements: sustained 4K output at 30 frames per second with zero frame drops, and continuous operation inside a sealed, sterilisable enclosure without any active cooling. Meeting all three simultaneously on compact embedded hardware is the kind of problem that looks straightforward on a requirements document and turns into a multi-month engineering exercise in practice.

Through this article, I cover our complete technical approach, from hardware selection through kernel configuration, pipeline design, thermal management, image processing, and medical compliance, that produced a validated system achieving 45 ms end-to-end latency.

Choosing the right platform from the start

The NXP i.MX8M Plus was selected as the System-on-Module for this project after evaluating several processor families against the combined latency, throughput, and thermal constraints. The decision came down to three hardware capabilities that the i.MX8M Plus provides native support, whereas competing platforms require external silicon to replicate it.

The first is an on-chip Image Signal Processor. Raw Bayer data arriving from the camera sensor over the MIPI CSI-2 interface needs demosaicing, noise reduction, white balance, and colour correction before it is usable. Doing this work in software on the application cores is expensive and variable in timing. The i.MX8M Plus ISP handles the entire processing chain in dedicated silicon, leaving the four Cortex-A53 cores free for pipeline orchestration and system management.

The second is the Vivante GC7000Lite GPU with its G2D bitblit engine. After the ISP outputs a YUV422 frame, it still needs conversion to an RGB format that the display controller accepts. The G2D engine performs this conversion at full throughput using DMA-shared buffers, adding approximately 5 ms to the pipeline with no CPU involvement at all.

The third is the co-processor architecture. The i.MX8M Plus includes a Cortex-M7 running at 800 MHz alongside the main A53 cluster. All auxiliary control tasks, sensor configuration, exposure loop management, and peripheral housekeeping were offloaded to the M7. This keeps the A53 cores entirely focused on the latency-critical video path.

Table: System hardware and software configuration

Offloading ISP and colour conversion to dedicated silicon is what enables 45 ms.

Real-time Linux and the scheduler problem

A standard mainline Linux kernel is not built for hard real-time operation. The Completely Fair Scheduler distributes CPU time fairly across threads, but it makes no guarantees about when a specific thread will next be scheduled. Interrupt service routines execute in a hard IRQ context and cannot be preempted by higher-priority threads. In a desktop or server environment, this is rarely a problem. In a surgical video pipeline, the resulting jitter in capture timing translates directly into frame irregularity and worst-case latency spikes that blow the 50 ms budget.

The solution is CONFIG_PREEMPT_RT, the full real-time preemption patch for the Linux kernel. With PREEMPT_RT enabled, nearly all spinlocks become sleeping mutexes, interrupt service routines run as schedulable kernel threads rather than in hard IRQ context, and the kernel becomes fully preemptible at almost every execution point. A SCHED_FIFO thread at the right priority will now preempt any lower-priority context within a bounded, measurable time.

Beyond enabling the patch, several additional tuning steps were applied. The V4L2 capture thread and the GStreamer pipeline thread were both assigned SCHED_FIFO scheduling at priority 80 using chrt. CPU affinity for both threads was pinned to cores 2 and 3 using taskset, keeping them isolated from general system activity on cores 0 and 1. The CSI-2 controller IRQ was reassigned via /proc/irq to core 2, and the G2D completion IRQ was pinned to core 3. The V4L2 capture buffer queue was reduced from the default of four buffers down to two, which limits how many frames can accumulate ahead of the display stage and directly cuts pipeline depth latency.

Validation used cyclictest from the rt-tests package, running for eight hours under full pipeline load. The measured maximum scheduling latency across that run was 124 microseconds, with a mean of 21 microseconds. Those numbers give ample margin against a 50 ms system target.

Reducing V4L2 buffer count from 4 to 2 alone cuts pipeline latency measurably.

GStreamer pipeline with DMA zero-copy

The GStreamer media framework was chosen for the user-space pipeline because NXP provides a mature set of i. MX-specific plugins that expose the G2D accelerator and the KMS display interface with DMA buffer sharing. The pipeline graph follows a three-element chain: v4l2src captures frames from the CSI-2 device using DMABUF memory type, imxvideoconvert_g2d performs YUV422 to RGB conversion on the GPU using the same DMA buffers without copying, and kmssink presents the result directly to the LCDIF display controller via the DRM/KMS interface.

The DMABUF memory type is the critical detail. Without it, every frame in YUV422 format at 4K resolution involves moving roughly 12 MB of data between kernel and user space at each pipeline stage. At 30 fps, that is 360 MB per second of avoidable memory traffic. With DMABUF, the physical buffer allocated by the CSI-2 DMA engine is shared by reference through the entire pipeline. The ISP writes into it, the G2D reads from it and writes the converted output into a display buffer, and the LCDIF reads that display buffer directly. No byte is copied at any stage.

The complete pipeline latency breakdown, measured using the GStreamer latency tracer alongside ftrace for kernel-level timing, came out as follows: sensor capture contributed 5 ms, CSI-2 DMA transfer to memory added 10 ms, ISP processing consumed another 10 ms, GPU colour conversion took 5 ms, and display rendering at the LCDIF accounted for the remaining 15 ms. The sum is exactly 45 ms, with 5 ms of margin remaining against the 50 ms requirement.

Thermal design for a sealed enclosure

Medical device enclosures present a thermal challenge that consumer and industrial electronics rarely face with the same severity. The enclosure must be sealed against liquid ingress to survive sterilisation cycles. It cannot have vents. It cannot have a fan. Every watt the processor dissipates must travel out through the enclosure walls by conduction alone.

The i.MX8M Plus dissipates approximately 5 watts under sustained video pipeline load. A passive copper heat spreader machined to contact the SoM’s metal shield directly carries that heat across the enclosure wall. Copper was selected for its thermal conductivity of 400 W per metre-kelvin, roughly twice that of aluminium, which matters when the temperature differential between the SoC and the enclosure exterior is the only driving force for heat removal. A phase-change thermal interface material at a 75 micrometre bond line connects the SoM shield to the spreader, and a second interface layer couples the spreader to the inner enclosure wall.

The CPUFreq governor was set to performance mode, holding the A53 cluster at 1.6 GHz continuously. Dynamic frequency scaling introduces brief clock transitions that create small but measurable pipeline stalls; eliminating it keeps the video path fully deterministic. A software thermal daemon polls the on-chip temperature sensors via the Linux thermal sysfs interface and triggers a controlled throttle if the junction temperature exceeds 70 degrees Celsius. During 72 hours of qualification testing under full load, the stabilised operating temperature was 68 degrees Celsius, within the safe envelope and below the throttle threshold.

Passive copper at 400 W/m.K keeps the SoC below 70 degrees Celsius continuously.

Medical compliance as an engineering discipline

Regulatory compliance for a medical imaging device is not a documentation exercise appended to a finished design. It shapes hardware and software decisions from the earliest architecture stage. Three standards governed this project directly.

ISO 10993 covers biocompatibility of materials that come into contact with patients or clinical staff. The enclosure material selection, surface treatment, and adhesive choices were all validated against this standard before prototype fabrication began. IEC 60601-1-2 covers electromagnetic compatibility, requiring the device to operate correctly in the presence of the high-frequency surgical equipment and monitoring devices present in an operating theatre, and to not itself emit interference that affects other equipment. IEC 62304 defines the software lifecycle requirements for medical device software, including change control, hazard analysis, and verification procedures for every software component. (Source: iso.org)

Meeting IEC 62304 in particular meant that the GStreamer pipeline, the PREEMPT_RT kernel configuration, the thermal daemon, and the ISP tuning parameters were all treated as controlled software artefacts with documented test cases and traceability to system requirements. This adds rigour to the development process but also produces a codebase that is substantially more reliable and maintainable than typical embedded software projects of comparable complexity.

A reference architecture worth replicating

The 45 ms result achieved in this system reflects decisions made consistently across every layer of the stack. Hardware ISP and GPU acceleration removed the two most expensive processing steps from the CPU budget. PREEMPT_RT with affinity pinning reduced scheduling jitter to levels that no longer influence system-level latency. DMA zero-copy eliminated hundreds of megabytes per second of memory traffic. Passive copper thermal design kept the processor at rated frequency without a fan. And treating compliance as an engineering input rather than a final-stage hurdle produced a system that passed all medical qualification tests on the first submission.

Engineers working on embedded video applications outside medical imaging will recognise these constraints in different forms. The tools are open-source and available on any embedded Linux platform. The methodology is repeatable. And the lesson is consistent across domains: in a real-time system, the overall latency is determined not by the best-case path through the pipeline but by the worst-case behaviour of every component in it. Optimise each one with measurement, and the system target takes care of itself.

Rutvij Trivedi, co-founder of Silicon Signals, architects embedded systems for 20 years and actively contributes to Linux kernel and Zephyr OS upstream.