Input lag on the Cronus Zen: what is real, what to test, how to measure
The Cronus Zen adds some input lag, as every input passes through the device and script; how to measure your own chain with a 240 fps phone camera.
Yes, the Cronus Zen adds some input delay, because every controller report is read, run through the active script and written back out before the console sees it. How much on your setup is something you measure, and the method is below. This site publishes no figure for the Zen's own contribution, and Cronus's guide gives none either. For timing, what matters is less the size of the delay than whether it stays the same from one press to the next.
Where the lag comes from
| Source | What to expect | What you control |
|---|---|---|
| The Zen itself | No published figure; a heavier script does more work per report | Script choice; CPU Load in Device Monitor |
| Wired pad | Steady | Nothing |
| Wireless pad on an adapter | Can vary with the radio link | Go wired |
| Pad over Bluetooth | Can vary | Use USB where you can |
| Underpowered port, hub or long extension | Drops and stutter; Cronus says a powered hub with a 5 V auxiliary power input helps prevent input lag | Direct port or powered hub |
| PS5 via Zen Link | Cronus describes PS5 Native Mode as a direct native connection with ultra-low latency, and gives no figure. Its older guide's Remote Play route ran over Wi-Fi, where it said lag and disconnects can occur out of the router's range | Set up Native Mode as Cronus's current Zen Link pages describe; measure it |
| Console and game frame time | Steady per game | No |
| TV or monitor processing | Steady per setting | Game mode and picture settings |
None of these rows carries a number on purpose. The measurement method below is how you get your own, on your chain, with your script.
Constant versus variable
A timing script, the NBA 2K release scripts for example, is calibrated on the chain it runs in. If every report is delayed by the same amount, the calibration absorbs it and the timing lands. If the delay changes from press to press, no calibration can absorb it, and the timing is early one shot and late the next.
So the question that matters is not "how much lag" but "how steady". Wired pad, Zen direct into the console, TV in game mode: steady. Wireless pad, hub, Wi-Fi, a TV processing the picture: less steady. Wired vs wireless controllers on the Zen is the practical version of this.
How to measure your own chain
You need a phone that records at 240 fps (most do; it is the slow-motion setting) and a game with an immediate on-screen response to a button, like a menu cursor or a weapon fire.
| Step | Do |
|---|---|
| 1 | Frame the pad and the screen together in the shot |
| 2 | Record at 240 fps. Press the button once, sharply. Stop recording |
| 3 | Scrub frame by frame. Count frames from the button bottoming out to the first visible change on screen |
| 4 | Divide by 240 for seconds; multiply by 1000 for milliseconds. Each frame at 240 fps is about 4.2 ms |
| 5 | Repeat ten times; take the middle value. Single readings vary |
| 6 | Repeat with the pad plugged straight into the console, no Zen. The difference is the Zen's contribution in your chain with your script |
| 7 | Repeat once more on slot 0, which runs no script, to separate the device from the script |
The with-and-without comparison separates the Zen's share from the console's and the display's. What you are looking for in the Zen's share is consistency across your ten readings. If it is not consistent, something in the chain is variable, and that is worth finding.
Check the Zen's own load
Zen Studio's Device Monitor (press F3 with the Zen connected over PROG) shows the Zen's CPU Load while a script runs. Cronus says any value below 80% is acceptable and means the processor is doing all its tasks on time, without delays or lag. If your script holds the load near or above that line, it is the script, not the device, that is costing you; ask its author whether a lighter mode exists.
Reading the numbers
| Your result | Reading |
|---|---|
| The Zen's added delay is about the same across all ten readings | Normal. Calibrate on this chain and stop worrying about it |
| Slot 0 and your script differ clearly | The script costs time; check CPU Load and ask the author about a lighter mode |
| The Zen's contribution jumps by several 240 fps frames between readings | Something variable: an adapter, a hub, Wi-Fi, or a script doing uneven work; fix the chain, not the script values |
| The total is large and much the same with or without the Zen | The display or console settings dominate; game mode first |
| Some presses are missing entirely | Drops, not lag; a Zen that keeps disconnecting |
What to do about it
- Play wired for anything timing-critical. Save wireless for games that forgive it.
- Zen direct into the console, no hub, no extension, or a powered hub with a 5 V auxiliary power input, which Cronus says helps prevent input lag; Ports and cables.
- TV in game mode, always. Cronus's display-lag page also suggests the PC input mode where the TV offers it, and turning off motion smoothing, "magic" picture processing, HDMI-CEC and power saving. Cronus calls game mode the single most important setting for reducing input lag.
- On PS5, use Zen Link in Native Mode. Cronus's current guide describes it as a direct native connection; the range and ethernet advice in its older guide was written for the Remote Play-based setup.
- Keep the script light. Watch CPU Load in Device Monitor and ask the author if the script has a lightweight mode.
- Calibrate on the chain you play on. If you calibrate a timing script with a wired pad and then play wireless, it will be off.
What is not real
| Claim | Status |
|---|---|
| "The Zen adds a hundred milliseconds" | No source behind it. If you measure that much, something else in the chain is adding it; measure with and without the Zen |
| "A firmware update fixed or broke the lag" | Possible either way: Cronus's changelog lists 2.2.x fixes to PS5 driver CPU use and output protocol timing. Measure before and after rather than assuming |
| "Lag makes the Zen detectable" or "undetectable" | Neither claim has a source; Is the Cronus Zen detectable? covers what is known |
| "A gold-plated cable is faster" | No. A cable either carries data or it does not |
If your measurement shows variable delay with everything wired and direct, the last suspects are the cable and the power at the port, and Cronus Zen not detected has the cable rule that applies to every page on this site.
Frequently asked
- Does the Cronus Zen add input lag?
- Yes, some: every report passes through the device and the active script before it reaches the console. Neither this site nor Cronus's guide publishes a figure for it. Measure it on your own chain with the method on this page; what matters for timing is that it stays steady.
- Is lag through the Zen worse wireless?
- Expect it to be less consistent. A wireless pad adds its own radio link, which can vary from moment to moment. Wired is the steadiest; measure both on your setup to see the difference.
- Can I measure it myself?
- Roughly. Film the pad and the screen together at 240 fps with a phone, press a button, and count frames between the press and the on-screen response. Compare with and without the Zen, and on slot 0 against your script.
- Does the Zen's lag break timing scripts?
- A steady delay can be calibrated out, because a timing script is tuned on the chain it runs in. A delay that changes from press to press, from an adapter, a hub, Wi-Fi or an overloaded script, is what breaks timings.
- Does a longer USB cable add lag?
- A cable carries data or it does not, but a connection that cannot supply enough power can cause trouble. Cronus recommends a powered USB hub with a 5 V auxiliary power input and says it helps prevent input lag, among other problems.
- Does the TV matter more than the Zen?
- Often. Cronus's own display-lag page calls game mode the single most important thing you can do to reduce input lag. Turn it on, and turn off motion smoothing and other picture processing.
Something on this page wrong or out of date? Report a correction