How to remove frequency offset with RRC as pulse shaping filter

Question

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".

Answer 1

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.