---
title: Stutter
slug: scenario/stutter
docTags: 
createdAt: 2025-07-11T14:13:45.679Z
---

To resolve a stutter issue, it's important to understand exactly which part of the tracking/rendering chain it is appearing in.

As we've covered, Stutter is essentially information not being available at a certain part of the chain when it is needed.  Therefore troubleshooting is about systematically going through each part of the hardware and software chain and checking that there are no bottlenecks or other limitations

::Image[]{src="https://api.archbee.com/api/optimize/qD4GJYL5qMffFW6GWjgo7-TNYEtEWDEl53-lnbwWtg7-20250728-104636.png" size="72" width="721" height="800" position="center" showCaption="false"}

Often the first step is to identify whether it is being caused on the "<font color="#2166ae">**Input**</font>" side, by this we mean the Link, Origin and tracking processing.

Or the "<font color="#2166ae">**Output**</font>" side, which relates to the tracking data as it leaves the Origin and arrives and is used on the renderer side

:::ExpandableHeading
# Input

## Data from the CamBar

The sensor data from the CamBar must reach the Origin in a timely manner for it to be used.  When a Link is present between the two devices there is a potential for this communication to be impacted.

The following tests can be done to see whether the issue is being generated due to bottlenecks in the data

### Test - Remove the Link temporarily

Isolate the Link and Origin connection temporarily by connecting the Cambar directly to the Origin.  If the stutter issue resolves then it is likely to be an issue with the Link or Link>Origin interface

### Test - Power the Link/Origin using a PSU

Ensure the power requirements of both the Link and Origin are being met.  If either device is underpowered then this can cause data bottlenecks between the devices.  The Link is particularly susceptible to this as it is more typically powered by camera outputs which may not be regulated

### Test - Use Grafana profiling tools

The Grafana interface provides a lot of metrics which can be helpful for identifying spikes or issues with the connectivity between the Link and Origin

::Image[]{src="https://api.archbee.com/api/optimize/qD4GJYL5qMffFW6GWjgo7-I-AOts2YVsfLybPNxAkD0-20250711-142641.png" size="76" width="3513" height="1370" position="center" showCaption="false"}
:::

::::ExpandableHeading
# Output

## Communication between Origin and Renderer

### Test - Check Scenario and Renderer logs

Scenario logs can be provided via the system report function and will display any dropped or missed packets.  On the renderer side, similar functionality should be available.

### Test - Inspect tracking data, compare tracking data locally vs when it's received via the network

Compare Wrangler recorded data with data captured on the renderer side.  If Wrangler captured data shows dropped or duplicated frames then it suggests that the issue is not being caused by the network or synchronisation between the Origin and Renderer

### Test - Is the issue seen when using a different protocol

The SDK Full protocol uses TCP/IP, while the FreeD and SDK LITE protocols utilise UDP.  Check to see if the issue is consistent across the protocols

### Test - Connect to the renderer directly

If the tracking data between the Origin and renderer is not point to point, make a temporary test with a direct network connection.  This can remove the possibility of issues in the network layer, particularly if there are managed switches etc inline

## Rendering Issues

Stuttering issues are generally observed when viewing the output of a render engine, as a result, it's important to isolate whether the issues are being generated during the rendering process as a result of a synchronisation issue or performance limitation.

The following tests are suggested to rule out problems on the rendering side

### Test - Load a simple test scene

Use a known working test scene on the renderer side and observe to see if the stutter issue is more or less prevalent

### Test - Compare Scenario calibration cones to renderer output

Sometimes it is possible to compare the calibration cones with a similar graphic on the rendering engine side, if issues are only seen on the renderer graphic is suggests that the stutter is being generated external of Scenario.

:::hint{type="warning"}
When viewing the calibration cones in Scenario, you must view them when "On Air" is disabled to ensure that the rendering is accurate **(When On Air is active the viewport is degraded to ensure performance and shouldn't be used for diagnostic checks)**
:::

### Test - Check GPU Profiler

The real time renderer should be able to provide a profiling tool to analyse or notify of rendering issues such as missed frames etc.  Compare whether any issues in the profiler correspond to observed stutters

### Test - Ensure Synchronisation is present on Renderer

Check to see that the renderer is synchronising data correctly with the camera signal.  In Unreal Engine the "Timed Data Monitor" is designed for this and will indicate if there is a synchronisation issue present
::::