(20.48 *10^6)/1024 = 20 KHzHello support team,
I have tried to implement the Xilinx FFT IP core as below.
I samples data format: FIX16_15
Q samples data format: FIX16_15
FFT window:1024
Sample rate: 20.48 MSPS
Output: unscaled
Output number of bits: 0 to 63 ( out of which 58 to 32 bits represent XK_IM and 26 to 0 bits represent XK_Re)
I have attached the screenshot of the same.
Now as per xilinx user guide, The index(xk_index: m_axis_data_user ) should be taken into account at which we are getting the highest peak amplitude of FFT output.
In the screenshot,
My input frequency is 3 MHz,
Highest peak index: 150
Frequency estimation = (Sample rate* index)/FFT window = (20.48 *10^6 *150)/1024 = 3 MHz
So, in this way I am getting the correct result. right now, I have verified it through the ILA.
But my actual requirement is to figure out the index value from the peak amplitude and take it further this index value to estimate the frequency. and then there is one fix frequency value (let's say 32 MHz ) needs to be added to the estimated 3 MHz frequency. so could you please suggest what kind of algorithm i can use to search for the correct index out of the total 1024 window?
Hello,How comes 32 MHz into play? What has it to do with peak search problem?
Peak can be identified in different ways, e.g. simple maximum, center of gravity with or without threshold filter. Choose based on intended resolution, signal-to-noise ratio, peak width.
Yes, I got your point. but in my case my input frequency would be unknown. so I need to figure out the index for the peak amplitude only.(20.48 *10^6)/1024 = 20 KHz
hence each bin is 20 KHz starting from dc bin as 0 the 20KHz then 40KHz.
If it helps.
Yes, actually my input is pure sine wave( no modulation). and my ADC to generate the digital data fulfills the nyqist criteria. But as my input sample rate to FFT IP core is higher such 20.48 MSPS. I am thinking to use counter to reduce the sample rate to 1 MSPS to get the higher resolution with lower FFT window . as lower FFT window will provide lower latency.Sampling frequency must fulfill Nyquist criterion to get non-ambiguous results.
So the maximal input frequency to be identified unambiguously is 500 kHz, isn't it?I am thinking to use counter to reduce the sample rate to 1 MSPS
Actually, my purpose is to estimate DDC frequency ( which will be in the range of 2-4 MHz). the 32 MHz addition is the NCO frequency(which here I have given as an example), the NCO frequency would be known to me . so by adding that, it is possible to estimate actual RF input frequency.Hi,
And how would you add 32MHz then? .. in a system that is limited to (below) 4MHz?
Klaus
so you want to offset back the NCO to get RF frequency. What stopped you identifying the bin index then convert it to frequency as index * 20 KHz then add 32MHz (in circuit or by hand on paper). You need extra care about negative frequency bins.Actually, my purpose is to estimate DDC frequency ( which will be in the range of 2-4 MHz). the 32 MHz addition is the NCO frequency(which here I have given as an example), the NCO frequency would be known to me . so by adding that, it is possible to estimate actual RF input frequency.
I am lost now...In the paper, it is possible. but my actual RF input will be varying within +/-1 MHz . so identifying the bin index will be variable every time my input frequency varies. so how to continuously estimate the correct one? because what I see from the FFT core latency, with 1024 FFT window, the latency is around 3 usec.
that means, the FFT IP core itself will take 3 usec to provide the output, after that peak identifying algorithm will also take some time. in between if my input frequency varies, then what is the best way to continuously estimate the correct variable frequency?
your main concern is processing time of FFT and peak detection.Hello,
Below is the figures.
ADC sample rate: 1966.08 MSPS
DDC sample rate: down sample to 61.44 MSPS
DDC output frequency: 2-4 MHz ( based on the input frequency variation)
FFT size: 1024
FFT input sample rate: (further down sample to 20.48 MSPS)
my system reference clock is 122.88 MHz, ADC sample rate generation, there is one inbuilt PLL.
Expected tone variation time(jitter): I am not sure about it. I need to check. right now,I have only that information that it will vary in between +/-1 MHz.
To reduce processing time I suggest you go faster on FFT and/or reduce fft size:ok, I got your point. my fft clock is 20.48 mhz only. 1 sample per clock
Have you considered a PLL feedback approach instead of FFT?ok, I got your point. my fft clock is 20.48 mhz only. 1 sample per clock
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?