CoastalMaineBird wrote:
If the maximum engine revolutional frequency is 60Hz, then following the 2x Nyquist premise, sampling should be done at 120Hz.
I still don't think you have it.
The Nyquist theorem says:
If you want to capture ALL the important information about a signal, then you MUST sample at a rate TWICE the HIGHEST FREQUENCY component in that signal.
The fact that your engine is rolling at 60 Hz DOES NOT MEAN that the highest frequency component in any signal you get out of that engine is 60 Hz.
If you are looking at cylinder pressure, for example, the highest frequency component will likely be 60000 Hz, because the pressure gradient is extremely fast when the spark plug goes pop and the fuel goes boom.
The fact that the compression pulse doesn't last for a whole cycle is irrelevant. It has a high frequency. If you sample too slowly, you will miss it.
If you're making a torque map, though, you don't care about such things. You want average torque (over a cycle or three) and the fact that torque changes within the cycle is not important to you (I assume).
I'm really batting a thousand here. 🙂 I see what you're saying, my mistake. According the Nyquist theorem, if I wanted to capture all the important information, every last force change event within a single rev, I would have to identify the highest component frequency of the force signal and then sample at twice that rate. I must apologize to Mr Nyquist, I really messed that one in my previous posts.
Since I'm not interested in intra-rev data, I can sample once per rev. I have an option to sample at a fixed 60Hz, or possibly use synchronous sampling to time each sample with one complete rev, 60 pulse edges from the trigger wheel counter input. It seems like a matter of project preference, but there might be something I'm missing that makes this a more clear cut choice.
Is it accurate to say that the Nyquist theorem isn't immediately important to infrequent (max component freq >> sample freq) signal averaging data acquisition? I got caught up earlier mistakenly thinking that any signal to be sampled of a frequency x had to be sampled at 2x regardless of the required quality of signal capture. This is how I came up with the incorrect 120Hz sampling frequency number.
CoastalMaineBird wrote:
It sounds like I need to input each RPM sample into a three element FIFO buffer and read RPM as the average of the current three RPM values, for each iteration of the TargetRPM IV while loop. Each new iteration will kick out the third element of the buffer, shift element 1 -> 2 and element 2 -> 3, and input the latest DAQ counter sample into the first element. The average of these three numbers are then read as the RPM value for this iteration of the while loop. Does that sound about right?
The idea is exactly right, although there might be more efficient ways to do it. You have a constant N, say 3.
You create an array of N elements.
You have an index I, starting at 0
For each reading, you put the reading into the array at index I.
You add 1 to I, and if I = N, you set I = 0.
You average the whole array and that's your current speed.
There's less shifting around that way, and if you decide to change N to 4 or something, you have only one number to change.
Hooray, something I've put together is not rubbish. There's hope here yet. 😄
Thanks, your way would definitely be more efficient. I'm assuming I can do something similar with the force readings.
CoastalMaineBird wrote:
The engine will change speeds in a power sweep (or Torque Map) at an operator defined rate somewhere between 200RPM/s and 600RPM/s. I'm not sure if this qualifies as a relatively long averaging time.
But you see the idea I'm getting at, I hope. If you averaged for 1 second, and get an answer of 1000 RPM, you don't know what the current speed is.
It could have been 1000 RPM for the whole second. It could have ramped from 700 to 1300 RPM and you would still get 1000. It could have ramped from 1300 to 700 RPM and you would still get 1000. You just don't know.
For that reason, I suggest that you NOT count teeth per unit time, but time per tooth. If you get an answer of 0.0001 second per tooth, then you know that you are rolling at 166.6 RPM. But you have a new reading for every tooth that passes. FOr noise reasons, you can still average those readings, but you are averaging REVs. The faster the engine, the faster your readings update. There's no guesswork.
I was having trouble seeing how a counter itself was doing averaging. I think I get it now. The counter is counting pulse edges generated by the trigger wheel per unit time. If the unit time is one second and the counter counts 1700 pulses, then we know the RPM is 1700 pulses divided by 60 pulses per rev, equals 28 1/3 revs, times 60 revs per minute, equals 1700 RPM. Like you said though, there's no way to know if the engine spent the first half of the second at 2000RPM or 1400RPM.
I'll be testing the TargetRPM VI on the dyno tomorrow. The two VI changes I'm planning to make at the moment are to switch Sampling Time to 60Hz from 20Hz (while loop timer, 50ms --> 16.6ms), and to add the above averaging algorithm inline between the counter input and PID process variable input. I will try the Zieger-Nichols tuning strategy and see what can be done about the PID output response.
Thank you for your help. If there are other parts of the VI that could use review and change as well, it would be great to hear about it.
