1. Unsure what forces you're measuring, what "features" you're looking for, or what kind of bandwith your force transducer supports. I'd just say that in my experience, common mechanical systems that deal in forces and masses don't typically have a frequency response that justifies multi-kHz sampling. (Vibration measurements can need high sample rates, but one wouldn't normally use a force transducer to monitor vibration.)
It will be helpful to start bounding this problem. Some focused work can be done to determine the frequency response of the force system you're measuring. That's better than an approach that says, "we don't know what might be there, let's sample at a real high rate just in case".
2. I'd encourage you to explore the constant-rate frequency measurement mode your X-series device supports. I've not used it myself and have only skimmed the docs enough to have a basic awareness, not detailed knowledge. But it seems to offer a good middle ground between the precision of variable time interval measurements and the regularity of a constant sample rate. I suspect it'll be your best method to get RPM info.
3. I wouldn't take that approach unless I had no other options. All it really does is trade off position quantization for time quantization. There isn't a net gain from that step alone.
Pay close attention here: quantization effects are a fundamental issue. You simply can't do single-interval calculations and produce good results. Your quantization error will be of the same order of magnitude as your desired single-interval result, so the single-interval results become effectively garbage.
That's the motivation for multi-sample approaches like the moving average filter. Other kinds of filtering and curve fitting are other options. But all of them produce output values that depend on a *series* of input values, not just a single input.
Even the special constant-rate frequency-sampling mode your device supports will have quantization -- it can only update its frequency measurement when a new encoder pulse arrives. But the quantization happens when you're already natively in the realm of a speed-related rate measurement. That's much better than doing a numerical derivative on quantized position data because numerical derivatives tend to *amplify* noise and quantization errors.
-Kevin P
[Edit: P.S. re-read the original question. A moving average performed live in real time will indeed have some delay because it can only act on current and past data. If you do it in post-processing, you're free to average across past and future data symmetrically and not produce a delay.]
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
