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.