# Generating spectrum of a spectrum / identifying frequencies of ripples present in a spectrum

I have a spectrum as shown. The x-axis is frequency in GHz. The spectrum shows ripples that we can visually quantify as ~50 MHz ripples. I am looking for a method to calculate the frequency of these ripples other than by visual inspection of thousands of spectra. Since the function is in frequency domain, taking FFT would get it back into time domain (with time reversal if I am correct). How can we get frequency of these ripples?

• It's not a problem that the FFT takes you back to the time domain. The FFT doesn't know the unit of your x-axis. So the FFT would be a valid approach to figuring out the frequency of those ripples. Jun 22 '20 at 7:43
• yep, fully agreeing. But the phrase "of thousands of spectra" might indicate that you already have a signal model that mathematically explains where these ripples come from. In that case, what you're looking for is a parametric signal estimator to parameterize that model, not even necessarily from the signal's spectrum, but quite possibly directly from the time-domain signal. You'd need to explain that signal model, though! Jun 22 '20 at 8:45
• @MattL. Thank you for your reply. For me to understand it better, when I take a FFT of the above spectrum, what should be my time sampling. The plot has 384 data points. It would be helpful if you could outline the steps. Jun 22 '20 at 9:20
• A first step would be to just take the FFT of those 384 data points and see what you get. Jun 22 '20 at 10:25
• @MattL. I forgot to add -- the spikes are removed using a median filter in python. I will add a plot to the question and explain where I am stuck. Thanks. Jun 24 '20 at 9:42

You are not doing anything "wrong" but sooner or later you will end up "re-inventing" the tool that is doing exactly that already. That tool is the Cepstrum.

You wish to estimate the frequency of ripples that show up in the frequency domain and you would like to do this via the Discrete Fourier Transform (DFT) and that is fine. (Your assumption that if you take the DFT again it will send you back to the time domain is not entirely correct though)

Suppose your time domain signal is $$x[n]$$ and after the DFT it becomes $$X[k]$$.

Now, $$X[k] \in \mathbb{C}$$ but you don't care about the phase of the phase component (hope you understand why I wrote it this way). So, we take the magnitude of $$X[k]$$, let's call it $$Q[k] = |X[k]|$$. Notice here, $$k$$ still denotes frequency, capital letters still denote spectra.

$$Q[k] \in \mathbb{R}$$, so if you send it through the DFT, it does not care that this used to be complex or the result of another DFT or anything. It still sees a real "signal" and it decomposes it to a sum of sinusoids. If you $$W = \mathcal{F}(Q)$$, your $$W$$ will now be complex again, but this time it describes the fluctuations of $$Q$$.

Now, the thing is that because of the way the sums are put together within the DFT, the dynamic range of $$Q$$ will be all over the place. Specifically, the low frequencies (DC for example) can end up having HUGE sums and the high frequencies can end up having tiny little values. If you don't account for that, your $$W$$ will have a strong $$\frac{1}{k}$$ influence.

To account for this, instead of $$W = \mathcal{F}(Q)$$, you $$W = \mathcal{F}(\log(Q))$$. The effect of $$\log()$$ is to "compress" large values and boost small values. It is the same "trick" we do when we plot a spectrum in a logarithmic scale rather than linear scale.

But, if you do all this (which is a very reasonable thought progression), you have derived the cepstrum. Specifically, the Real Cepstrum.

Depending on your application's context, following up the cepstrum further might provide some more insights or uncover work that has already been undertaken in your field around what you are looking at.

Finally, I would also like to underline what Matt.L says, because you might realise that this "oscillation" is only described by a handful of harmonics and there might be a relationship that captures it that can be optimised by the data itself. This would be very useful, rather than trying to recover just one (dominant (?)) frequency.

Hope this helps.