At work we run a physics simulator (video game) that operates in an inner loop at 360 Hz. Data from that inner loop is collected 60 times a second and sent out to hardware (a force feedback steering wheel) in order for playback to the user.

I have two questions on this system.

First what is the best way to decimate the 360 Hz data down to 60 Hz. Right now we do a straight average of 6 samples together, but I suspect that this is causing some aliasing of the data and we are very sensitive to high frequency noise. We are also extremely sensitive to latency and even adding in 4 samples of latency (in the 60 Hz loop) would cause a noticeable delay between the onscreen display and the force feedback device that the users would pick up on.

Second, the hardware (steering wheels) is typically made to very poor tolerances and usually has a difficult time playing back data above about 20 Hz before the signal significantly degrades. Would it be better to low pass filter the 360 Hz data down to 20 Hz, or to low pass the 60 Hz data to 20 Hz, and what would be the most efficient way to handle this.

I currently have a single pole IIR filter that you can optionally define on the 60 Hz signal, this does smooth the data out, and adds in a considerable amount of latency as well. Mixing less than 0.20 of the current sample causes an odd disconnected feeling in the wheel so that is my lower bound. I would assume that going to a more complex filter would give me a much faster falloff and would both smooth out the high frequency chatter and noise in the wheel without increasing the latency beyond 4 samples (66 ms)

I'm half way through Steven W. Smiths book "The Scientists and Engineer's Guide to Digital Signal Processing" so I have a limited understanding of DSP's. I do have 20+ years of programming experience in 2D image manipulation so I have been using dsp's all along without knowing what they were. The point is go easy on my poor mind :)

I should also point out that the 60 Hz loop is running in 'real time' that is timed to the pc clock, and all communication with the wheel is also in real time, however the inner loop is processed 60 times a second and there is no way to get access to the inner loop data at a faster rate than 60 Hz.

  • 1
    $\begingroup$ Your description is a little confusing. Do you have access to the 360-Hz data or not? You seem to suggest so at the beginning but then say at the end that you can't get at anything sampled greater than 60 Hz. $\endgroup$
    – Jason R
    Commented Feb 8, 2016 at 20:33
  • $\begingroup$ I think the easiest approach would be to quantify the amount of latency that you can tolerate, and then design an FIR filter that gives you a delay in accordance with that. If your output device has a frequency response that rolls off above 20 Hz anyway, then you can allow your lowpass filter to have a wider transition band. This means the filter can be shorter (and therefore have a lower latency) while providing an acceptable level of stopband attenuation (to reduce aliasing effects after you decimate). $\endgroup$
    – Jason R
    Commented Feb 8, 2016 at 20:36
  • $\begingroup$ I should explain the 60 vs 360 Hz part. In our physics engine we have a function that processes 1 time slice of physics, we call that function 6 times in a row from an outer loop that is synced to run at 60 Hz. So inside the physics simulator the world is updated at 360 Hz but back in the real world we only have access to the data 60 times a second. $\endgroup$ Commented Feb 10, 2016 at 0:16

1 Answer 1


This is a really very nice applied signal processing question. Unfortunately your lack of DSP and physics expertise, builds some barriers on the way of your understanding. Hopefully this answer helps to tunnel through.

Now, your first question is about downsampling a discrete time signal. In fact there are already plenty of such questions here under the title of interpolators, downsampling etc. These are already answered with great detail. You better make a search on the site for more detailed answers but here once more I'll give a brief reply.

In downsampling a discrete-time signal (say from 360 hz to 60 hz in your case, by a facttor 6) the most critical thing to consider is the Spectral Utilisation of the original (360 Hz) signal. Based on Shannon-Nyquist sampling theorem criteria, this signal is assumed to contain meaningful (non-trivial) information in the band of frequencies 0 to 180 hz. However for many applications the frequency band of interest within the say 0-180 hz range will be a much smaller band, say for example from 0-20 hz. In such a case, the original signal is said to be "oversampled" (by a factor of 9 in this case). When a signal is oversampled by a factor of say M, then it is somewhat acceptable to discard every (M-1) samples and use the Mth one to represent the information content of the original signal without loss (except at the higher end of the band which gets to limit of aliasing). But this will/may produce some noise due to aliasing being on the very edge of it.

There won't be any aliasing, as long as the out-of-interest frequency band in the original signal contains no energy. In order to guarantee this condition of zero energy in the out of interest band, it is required to filter out those out of interest bands by a suitable filter of sufficient quality, before decimating the signal.

The quality of such a filter depends on, therefore, i-the spectral distribution of the original signal, ii-band of interest, iii-downsampling factor and other requirements such as real time processing or offline, accuracy, CPU power etc.

In your case, the answer lies in the following: the best downsampler should produce the most accurate representation of the band of interest signals and reject any irrelevant information for your steering hardware to process.

The short answer is this: as long as your system is configured to use 60 hz information (30 hz band) for the force-feedback processing, it seems that (and from my experience with mechanical acceleration signals, it is indeed so) this band of signals is adequate to represent average mechanical control. (as long as I can remember, most mechanical acceleration sensors do use at most a band of a few hundred hz). So just use a simple low-pass filter of cutoff frequency at pi/6 for better performance.

The second questions simply asks which is better to choose i-filtering 360hz into 20hz or ii-60 hz into 20 hz. The answer is the latter. It will be a much shorter filter to apply, and the transition band would also be easier.

When the latency of a few samples becomes so critical as in your example of real time forced-feedback control of a physical simulator, then high accuracy filters becomes impractical to use. May be you should completely discard using any filters at all, as you have pointed out the physical limitations of the wheel mechanics already prevents bulding of responses faster than 20 hz...

  • 1
    $\begingroup$ "Unfortunately your lack of DSP and physics expertise, builds some barriers on the way of your understanding" In my experience this is the frustration of being a programmer, the propeller heads (no offence) have lots of deep knowledge but little ability to apply it, while the code jockies have the skills to apply it but no knowledge. $\endgroup$ Commented Feb 10, 2016 at 0:18
  • $\begingroup$ On the graphics side end to end latencies beyond about 20 ms start to become noticeable, probably double that for the force feedback (tactile) side of things. Given that we only update once ever 16 ms that does not give us any time to mess around. I need to run some tests with a delay line but I suspect that even delaying the output by 2 samples (32 ms) would cause a sensation that you are driving a boat and not a car. $\endgroup$ Commented Feb 10, 2016 at 0:21
  • $\begingroup$ On the off chance that anyone here plays iRacing, you can access some raw data that outlines what is going on from our forums: members.iracing.com/jforum/posts/list/1100/3260458.page#9563956 $\endgroup$ Commented Feb 10, 2016 at 0:23
  • $\begingroup$ Am I right in assuming that a simple average of the samples adds 8 ms of delay to the output (going from 360 Hz to 60 Hz with a 6 sample average). Would it be better to skip the average and only output the last sample of the 360 Hz data? That seems incorrect to me. $\endgroup$ Commented Feb 10, 2016 at 0:27
  • $\begingroup$ if you have access to the 360hz real-time signal, then using 6 consequitive samples to produce the downsampled 60 hz real-time signal would produce about 16.7 ms of delay. For the 8 ms, I think you assume using half before and half after samples but that violates the real time property of 360 hz signal. So if I am not mistaking it will be about 16 ms of delay if you use 6 samples. Also consider using a weighted average rather than box-car average, which would fine tune the result to emphasize the most relevant sample among the array of six. $\endgroup$
    – Fat32
    Commented Feb 10, 2016 at 21:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.