# Adaptive equalizer for BPSK signals with frequency offset

I'm trying to equalize a BPSK signal which has a residual frequency offset on it. This frequency offset is dealt with at a later stage in the DSP chain, along with phase estimation.

I have implemented a FIR filter which updates its filter taps using gradient descent CMA:

The equalized signal (y) is a discrete-time convolution of the filter taps (W) and the input signal (X):

$$y = W^HX$$

The update error is: $$\epsilon = |y|^2-1$$

Finally I compute the update as: $$W_{i+1} = W_i - \mu \epsilon y^*X$$ Where $\mu$ is the step size = 0.001.

My problem is that due to the frequency offset, my input signal X is complex, which is resulting in complex filter taps in W. This in turn introduces a huge phase error into my signal. One possible solution I've looked at so far is putting the equalizer behind the frequency offset compensation stage. However, since the signal still contains some phase error, it's not entirely constrained to the real axis in the constellation diagram and I have the same problem. My workaround so far has been to update the filter taps as: $$W_{i+1} = W_i - real(\mu \epsilon y^*X)$$ My reasoning being that after frequency offset compensation and phase estimation, there should only be noise in the quadrature part of the signal, and I can safely discard it.

I'm unhappy with this solution for 2 reasons:

1. I'm not entirely sure it's theoretically sound, and at the very least it's rather unorthodox.

2. I would prefer to equalize the signal upstream in the DSP chain.

I would appreciate any help or insights!

• Even if you did not have a frequency offset, it is likely that due to channel distortion effects that you would still need an equalizer with complex filter taps given distortion effects that are not conjugate symmetric centered about the carrier. Are you dealing with a channel where you are sure that is not the case? May 10 '17 at 9:47
• Can you provide more details on the distortion sources you are trying to equalize? My thoughts are constrained to wireless channels where you would certainly want a complex equalizer, and to my understanding this is best and commonly done prior to timing and carrier recovery. May 10 '17 at 10:28
• An approach that I've used before is to use a fractionally-spaced blind equalizer (e.g. using CMA), followed by timing and carrier sync, then followed again by a symbol-spaced equalizer that is decision-directed (or possibly taking advantage of a training sequence if there is one). The carrier synchronization step will eliminate the frequency error that you're seeing. You'll still often have residual phase offset due to ambiguities in the carrier sync algorithm, but your second equalizer should be able to handle a constant to slowly-varying phase offset. May 10 '17 at 13:40
• The receiver is bandwidth limited, which is introducing a large amount of ISI into the signal. That is the main effect I would like to equalize. I should clarify that I'm not trying to avoid using a complex taps, rather, I simply can't get the filter to work if I don't include the real(.) operation in the update algorithm. May 10 '17 at 14:24
• To echo @DanBoschen, if you're receiving BPSK over a wireless channel, then the received signal will be spread over both the in-phase and the quadrature branches, and you may want to have a complex CMA. In my experience, I've used a phase-independent symbol timing estimator first, followed by CMA, and then carrier tracking. This works fairly well for BPSK and QPSK, and probably for M-PSK in general.
– MBaz
May 11 '17 at 2:42

It sounds like your biggest issue is dealing with a phase offset and otherwise you have no other concerns with your equalization approach? In that case, the issue is resolved by simply having a phase correction prior to making your decisions on the real signal. If done correctly your carrier recovery implementation should remove any residual long term phase offset. This post may help give you further insight: Phase synchronization in BPSK. I duplicated the final block diagram below where in your case "I data demod" would be your BPSK output. I want to point out using this diagram, that any residual phase error would accumulate in the PI Loop Filter which would then adjust the NCO to rotate the signal to have zero error (on average). Note that the Loop as shown if completely blind will lock in quadrature or 180° phase positions - if that is your remaining issue then another question on carrier recovery implementations would be more appropriate specific to any issue you have there, but a simple solution is to derive the phase error itself from $\phi \propto Q \text{sign}(I)$ since the objective in this case is to drive any signal on Q down to the noise. The assumption is the signal has been AGC'd prior to this point so such an approach to phase detection would result in a consistent loop gain. Here is another related post with regards to what gain constants you should use (what loop BW should be used): Loop bandwidth for symbol timing recovery

Also notice the similarity of the above diagram to a classical Costas Loop with the following figure from http://michaelgellis.tripod.com/mixerscom.html. This is because the Decision Directed CR Loop is a Costas Loop. The referenced link also diagrams the classical Costas Loop for BPSK specifically, which also shows how the digital implementation such as shown in the diagram above can be modified for the BPSK only case (which is modified the phase error metric as I described earlier). This solution will still have a 0/180° phase ambiguity which is typically resolved with minimum knowledge of the message (header or some other recognized feature in the data message or encoding in the data message).

• Hi Dan, thanks for your help so far. Perhaps I should have clarified that I already have a working CPR system in place. To verify that it's not the CPR or FO compensation causing the problems, I tried using some different adaptive filter implementations, which do actually give me nice results! I used the blind adaptive algorithms described in this paper: spiral.imperial.ac.uk/bitstream/10044/1/589/1/…. So this leads me to believe something is wrong with how I implemented the CMA algorithm. May 11 '17 at 15:50
• @Philip I was keying specifically on your comment of concern with a phase offset. This implies your carrier recovery isn't completely working or you simply need an additional phase rotator since you can easily measure (and rotate) the phase to be completely on the real axis. May 11 '17 at 18:54