Sample rate reduction using moving averaging algorithm

[Maitry07]

Hello support team,

I am capturing continuous amplitude samples with the rate of 20.48 MSPS, on this samples, I am trying to implement a moving averaging algorithm to average every 8 samples.

Sample0 to sample 7 >> average sample 0
Sample1 to sample8 >> average sample 1
like this ....

so if i assume my input number of samples = 20 , after moving averaging I will get total samples of 13. (if I am doing the moving averaging of 8 samples)

So, my input sample rate to moving averaging is 20.48 MSPS. at the output of moving averaging (with averaging of 8 samples) , my output sample rate will reduce to which number?
is it 20.479987 MSPS?

 

[KlausST]

Hi,

If the sampling rate is 20.48 MSPS, then it will stay 20.48 MSPS no matter what you do on the software / digital side.

You may reduce the output data rate. (This is not the same as sampling rate)

But your math is wrong. If you do 15 samples, then the moving average output will also be 15, but the first 7 may give nonsense values. But that´s only true for the very very first 7 samples. So if you do 2 million samples, then the first seven are invalid. so you get 1999993 valid output data.

For sure you may do averaging and output only ever n´th sample. For example every 4th sample. (giving an output data rate of 5.12 million per second)
This obviously will lose signal information. It´s a kind of low pass filter.

You can do this. No problem with that. But why sampling with 20.48MSPS while you just need 5.12 MSPS?
Why not using an analog LPF and reduce the (input) sampling rate? This will save a lot of processing power.

Klaus

 

[Maitry07]

Hello,

My actual output rate is 61.44 MSPS out of which I am taking every 1st and 4th sample and ignoring 2nd and 3rd sample. in this way, I am using module counter and having the final output rate of 20.48 MSPS.

I am getting nice accuracy of the amplitude measurement such as 0.11 dB ( for 6 msec period: 131072 consecutive samples).

But If I want some further accuracy like 0.06 dB for the same period, i think moving averaging of every 8 samples would give me this kind of accuracy.

So, for my input samples = 1 to 20 ,
I am getting moving averaging output like below.
sample1( average of 1 to 8)
sample2(average of 2 to 9)
sample3(average of 3 to 10)
sample4(average of 4 to 11)
sample5(average of 5 to 12)
sample6(average of 6 to 13).....

sample13(average of 13 to 20)

so, that's why I am assuming that for the first 20 samples, I will be getting correct averaged 13 samples.

 

[kaz1]

For down-sampling you should not just decimate as you like. You need apply a filter first specifically to remove any power that will alias at decimation. Then you decimate by discarding samples at regular intervals.

 

[Maitry07]

Hello, Actually I am using decimation upto 61.44 MSPS from 1966.08 MSPS and removing all the unwanted aliasing frequency. I have verified that in FFT domain. my -30.72 MSPS to 30.72 MSPS window is clean having only fundamental frequency. all harmonics and spurious are below 50 dBc. so, I am getting accurate samples of 61.44 MSPS on which I am doing digital signal processing to measure the amplitude and also reducing the rate to 20.48 MSPS using counter.

Then in order to slightly increase the accuracy, i am planning to use moving averging.

 

[kaz1]

If you reduce rate from 61.44 by 3 to 20.48 how sure are you aliasing wouldn't occur. If you are sure then you can just decimate by 3 without running average.

 

[Maitry07]

I have verified the amplitude measurement at the final output, aliasing is not there. because I have used proper analog and digital filtering (CIC+ FIR) upto 61.44 MSPS. I am getting accurate amplitude measurements at the rate of 20.48 MSPS. I have verified consecutive 131072 samples.
but after 20.48 MSPS samples, I want to make a provision to have better accuracy, which is only possible using running average.

 

[kaz1]

So if signal is ok at 20.48 then you can do running average on it without discarding anymore.
The rate before and after averaging should stay 20.48. You just average every N samples to get 1 sample in a running mode.

 

[Maitry07]

yes, that's my point. that rate after averaging is remain same. thank you for the confirmation

 

[kaz1]

yes, that's my point. that rate after averaging is remain same. thank you for the confirmation

If you want to discard initial samples and end samples you can do that. For example if you are averaging every 9 samples. You can discard first (9-1)/2 = 4 samples and last 4 samples and then you will get number of input samples same as output samples. This will help get a clean signal for fft.

 

[Maitry07]

Ok, I understand your point.

But, My input to running averaging is continuous. if my both algorithm trigeers with the same clock cycle, then I will be getting averging from the first 8 samples it self.

But , here my concern is how should I estimate the latency of the running average algorithm. I have written it in VHDL. is there any way to estimate the latency in vivado for the vhdl code? based on that I should get the clear idea , how much delay it is taking to do the averaging.

 

[kaz1]

For N averaging filter the delay is (N-1)/2 samples. so discard that (not N) from start and same from end if required for good fft

 

[Maitry07]

Ok, I got your point. That means, the latency for running averaging is 3.5 clock cycles. and I have to discard first and last 4 samples. right?

 

[kaz1]

Ok, I got your point. That means, the latency for running averaging is 3.5 clock cycles. and I have to discard first and last 4 samples. right?

indeed. Better make N = 7 or 9 instead of 8 as you can't discard half sample.
You also need to realise that this is filter group delay, not register delay.
Register delay is your implementation. You can check start sample visually.

 

[Maitry07]

Oh yes, I forgot that implementation delay will also be added. yes, i will visually check the start sample.