# How to remove frequency offset with RRC as pulse shaping filter

I am working on a project with QPSK modulation format and a RRC filtering at the transmitter (TX) side. The channel introduces a constant dropper shift ($$f_d$$) to the received signal. To make the channel ISI free, the same RRC filter is used on the receiver (RX) side.

To remove this $$f_d$$, a practical ML frequency offset estimator is used [1].

This method is derived by assuming this $$f_d$$ is small enough. Therefore, after some mathematical manipulation, the decision statistics can be narrowed down to

$$\max(\lvert \text{fft}(c(k)^**y(k)\rvert),$$

where y(k) is the received r(k) filtered by a RRC matched to the RRC at TX, and c(k) is the transmitted data symbol (sample). To eliminate c(k) in the statistics, the $$(c(k)^**y(k) )^4$$ is used before fft operation is performed. The upsampling rate is 10. I couldn't see any issues in this process. Besides, I also tried to do $$((c(k)*y(k))^4 )^{\frac 14}$$ in order to eliminate the effect on the magnitude of the filtered received signal, but this gives me a huge DC component.

Finally, the algorithm works very well without RRC filtering at TX and RX. It also works very well without this $$f_d$$. So the problem should be something related this pulse shaping part.

Could anybody see any problems in this process?

[1]. U. Mengali et al: "Synchronization Techniques for Digital Receivers".

• thanks! Next time, just edit your existing question, but this really is interesting! – Marcus Müller Nov 29 '20 at 21:44
• Do you have timing recovery before you to the frequency estimation? – Marcus Müller Nov 29 '20 at 21:46
• I only care about samples instead of symbols at this point. Timing is done after the fd is removed – Cindy Nov 29 '20 at 21:53

The RRC output only takes the exact constellation point values at exactly the right timing instant. That's what I meant with "coherent detector feeding a synchronously sampled matched filter" in an answer to a previous question of yours.

You'll have to deal with the inter-symbol interference with previous symbols. Which is no big deal – all symbols should have the same probability, so the average phase error you'd get is zero.

But, not so much for the fourth power: that's always a positive error, so yes, you get a biased phase correction term, and that means a misestimate of your frequency. Although I only mentioned noise, uncorrelated ISI looks a lot like nose, and thus it should have been among the reasons when I said

I'd advise against this whole approach!

in the answer to a question that Linda posted a couple of months ago (and seeing that this deleted question of four hours ago is practically a precursor to this question, I'll assume you and Linda basically share a team, or actually are two accounts for the same person. If the second account was made by mistake: Moderators can merge these for you, no problem! Just ask over in Meta.DSP).

You can now either:

1. Do the timing recovery before the frequency correction, and live with the significantly reduced performance that brings due to ISI or
2. Drop the fourth-power approach and go for a second-order PLL.