Latency | The Half-Truth

When discussing latency in motion simulation, its important to realize that there really is no good way to measure latency between various motion systems. In some ways, the latency numbers don't really matter, they are kind of a half-truth. Allow us explain.

Latency numbers such as 7ms, 3ms and we've even seen claims of "negative latency" (more on that later) are often used in marketing or advertising material to make the customers believe that a lower latency is simply better than a higher latency. And in some ways this is true, lower system processing latency is better, but in engineering there are no solutions, just trade-offs. So what are the trade-offs of with latency? Well even before we answer that question, lets first understand that these latency numbers are often provided without any proof or evidence. 

The "trust me bro" measurements, is not how we do things at Sigma. Don't trust what anyone says, not even what we say, without being able to verify it yourself or at least have access to the data yourself. For example, see our Sigma Full Send Video on how we measure and guarantee our acceleration number at max payload.

All systems have inherent latency, even your brain has inherent latency, also called reaction time. Latency is typically defined as the delay from the time something happens, to the time its observed or felt in terms of motion systems. When Sigma discusses latency we usually preset this information:

Haptic latency is not a simple number that can be easily measured as in most video compression systems or when measuring human reaction times. The complete system latency can be broken down and measured at various stages but even those numbers vary greatly based on many other dynamic variables.

Often times motion system manufacturers will advertise the lowest possible theoretical latency numbers that are often not achievable just to convince you of absolute system performance. But most motion systems are very dynamic and dependent on many other external factors that increase processing time. For example, most catalog systems (see our 3 Types of Motion Systems article) do most of their algorithmic calculations in a Windows sub-systems with hobby grade 16-bit micro-controllers such as Arduinos, limiting them to 60hz. These devices are resourceful solutions to motion calculations, but lack the ability to do some of the higher level calculations required for smooth quality motion.

Companies often claiming 3ms or 7ms of latency can just be describing their electrical and system signal processing latency (which all systems inherently have) and not the total loop latency in or an average total processing latency. The games physics engine, the graphics cards and even USB controllers can  cumulatively add 16-30 ms of latency alone. In one case, a company even claimed negative latency, and how they had to introduce latency to their motion system to match their graphical latency. Sounds great for selling motion systems, but such exaggerations hurt the simulation community overall. How do you explain "negative latency"... well its not time travel. The company in this case had excessive GPU and display latencies and so their motion system appeared to be responding faster than their graphical image. :-(

Low latency numbers are achievable but they are most likely not the full picture when it comes to latency and real world system performance. We would argue that in some cases, you want more latency and not less. For example in Sigma's environment motion layer, which tell us how the car is situated on the track we need past historical information to calculate a smooth average. So if we want to simulate the vehicle going down the corkscrew at Laguna Seca, we need to know where the car was in the past and where it is now, and make that calculation very quickly to to accurately adjust the angle of the motion simulator. You have to know the state of the vehicle was 20-30ms in time, before you can position the motion simulator to where it is should be now. So in this case having latency is a positive, its something you want or need as it gives you a more authentic motion experience. Just focusing on low latency would result in an artificial, jagged or robotic-like feel to the motion which is often just then smoothed out in post-processing with with things like smoothing filters.

Our Velocity Trap algorithm for example is constantly working to give a smooth, natural and organic feel to the motion experience, without the jagged like robotic nature which is not how cars or craft feel in real life. (Here is an explanation of our Velocity Trap Algorithm) 

Furthermore, some motion system platforms still do most of their motion processing in Windows OS which is not a real-time operating system. Real-time meaning it cannot guarantee that it will prioritize and maintain a certain performance when calculating a specific mathematical instruction. This is why Windows is called a general purpose or a non-real time operating system which is great for general computing needs but it cannot accurately calculate smooth motion systems layers. Sigma uses a real-time or an embedded system for our motion processing which guarantees timely signal processing of our motion layers. But even then we are hesitant to claim any one particular number, as even the average floats between 3ms to 50ms depending on the condition.

We have recommended that certain motorsports regulating bodies standardize testing requirements and measurements for haptic simulation systems, such as steering wheels, motion systems and other devices but our suggestions for this have gone unheard for many years. It would be quite a task, but also quite a benefit for a 3rd party agency, to setup a standard measurement of performance. This would be a true benefit to the community overall.

Sigma continues to develop and improve its systems and focuses on the total (Sigma) integration (Integrale) of each system and sub-system to give the best quality motion experience possible.