Since you're saving N samples in an array, you could look for the zero-crossings and compute the RMS value between three zero crossings.
Hi,
A sliding window of a fixed length combined with a varying input frequency causes problems.
If you are using lower output frequency than input frequency... it acts like a decimation filter.
Then it's causing similar artefacts than undersampling... it is causing alias frequencies.
Do you know the range of the input frequency?
Klaus
If your signal can arbitrarily change frequency from sample to sample, your RMS calculation becomes kind of meaningless, since you say you want to compute the value over a complete cycle. If you're halfway through a 100 hz signal and it jumps to 200 hz, what do you use for your window size? In other words, is your window 1/100 or 1/200?
Hi,
It's getting clearer now. But not easier.
The problem is the input frequency range.
0...200Hz. The dynamic is 200Hz / 0Hz ... which is infinite. Not good.
0Hz is more the problem than 200Hz.
Imagine you have to wait for a full cycle at 0Hz. That's really a long time....
Klaus
If you could limit the lower frequency to 0.1Hz .... this is 10s of cycle time..and gives a frequency dynamic of 2000.
This means you need 2000 times the sliding window width than with 200Hz.
One approach could be not to store the squared values in the ring buffer, but the [squared_and_accumulated] values.
But with this method you need
* to restart the measurement from time to time
* and you need a larger bit width of the buffer contents.
Then you could decide integration_time eg integration_count
The calculation is: sqrt((actual_value - buffer_value)/ integration_count)
Where the buffer_value is the value integration_count before the actual value.
With this method you could adjust window size dynamically at any time without much processing power.
*****
0..200Hz somehow reminds me on an inverter motor application..three phase
If so, then it eases the problem drastically.
Klaus
input
-2 / 1 / 0 / 1 / 2 / 2 / 1 / 0 / -1 / -2 / -2 / -1 / 0 / 1 / 2 / 1 / 0 / -1 / -2 / -1 / 0
squared
4 / 1 / [COLOR="#00FF00"]0[/COLOR] / 1 / 4 / 4 / 1 / 0 / 1 / 4 / 4 / 1 / [COLOR="#0000FF"]0[/COLOR] / 1 / 4 / 1 / 0 / 1 / 4 / 1 / [COLOR="#FF0000"]0[/COLOR]
in buffer:
4 / 5 / [COLOR="#00FF00"]5[/COLOR] / 6 /10 /14 /15 /15 / 16 / 20 / 24 / 25 /[COLOR="#0000FF"]25[/COLOR] /26 /30 /31 /31 / 32 / 35 / 36 / [COLOR="#FF0000"]36[/COLOR]
Hi,
example:
for the first full wave: green to blue:Code:input -2 / 1 / 0 / 1 / 2 / 2 / 1 / 0 / -1 / -2 / -2 / -1 / 0 / 1 / 2 / 1 / 0 / -1 / -2 / -1 / 0 squared 4 / 1 / [COLOR="#00FF00"]0[/COLOR] / 1 / 4 / 4 / 1 / 0 / 1 / 4 / 4 / 1 / [COLOR="#0000FF"]0[/COLOR] / 1 / 4 / 1 / 0 / 1 / 4 / 1 / [COLOR="#FF0000"]0[/COLOR] in buffer: 4 / 5 / [COLOR="#00FF00"]5[/COLOR] / 6 /10 /14 /15 /15 / 16 / 20 / 24 / 25 /[COLOR="#0000FF"]25[/COLOR] /26 /30 /31 /31 / 32 / 35 / 36 / [COLOR="#FF0000"]36[/COLOR]
= sqrt (25 -5)
for the second full wave blue to red
= sqrt (36 -25)
Klaus
I tried guessing what this might be but just couldn't come up with an answer. For some reason, the results I see are all over the place & I have a feeling that this might be one of the causes for it.The calculation is: sqrt((actual_value - buffer_value)/ integration_count)
Where the buffer_value is the value integration_count before the actual value.
Klaus
If so, what'd be the proper/efficient way to do so considering the additional processing load this presents and also the effect this restart would have on the accuracy?But with this method you need
* to restart the measurement from time to time
Klaus
Hi Klaus,
I've been working on implementing this method and a few doubts popped up.
1. What's the integration_count/integration_time that you've mentioned?
I tried guessing what this might be but just couldn't come up with an answer. For some reason, the results I see are all over the place & I have a feeling that this might be one of the causes for it.
2. At some point, the data type assigned to the elements of the buffer will overflow. Is this the reason that you mentioned the need to restart the measurement?
If so, what'd be the proper/efficient way to do so considering the additional processing load this presents and also the effect this restart would have on the accuracy?
Again, thanks for your help.
Hi,
The spike comes because of window length mismatch. I think there is no way to avoid this...as long as you can't see into the future, how frequency changes.
Klaus
No,
the problem is that before you know the new_frequency .. you still process the incoming datastream with the old_frequency. .. but the frequency already changes.
Klaus
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?