# Why is a precoder necessary for DQPSK and what does it accomplish?

I've implemented a soft-decoder for DQPSK using the wonderful answers I received here:

How to soft decode DQPSK?

To get the soft-decoder working properly I needed to precode the data I was sending out. I implemented the precoder mentioned in this paper:

$I_k=\overline{u_k \oplus v_k}*(u_k \oplus I_{k-1})+(u_k \oplus v_k)*(v_k \oplus Q_{k-1})$ $Q_k=\overline{u_k \oplus v_k}*(v_k \oplus Q_{k-1})+(u_k \oplus v_k)*(u_k \oplus I_{k-1})$

I'd like to know why this precoder is necessary -- what does that complicated expression of XORs actually accomplish?

Here's a table showing what the equation yields. If "to_encode" is 00, the to_send symbol is the same as the previous ("prev") symbol. If the "to_encode" is 11, the to_send symbol is the previous symbol xor 11. What is the meaning in other cases?

to_encode prev  to send
[ 0 0 ] [ 0 0 ] [ 0 0 ]
[ 0 1 ] [ 0 0 ] [ 1 0 ]
[ 1 0 ] [ 0 0 ] [ 0 1 ]
[ 1 1 ] [ 0 0 ] [ 1 1 ]
[ 0 0 ] [ 0 1 ] [ 0 1 ]
[ 0 1 ] [ 0 1 ] [ 0 0 ]
[ 1 0 ] [ 0 1 ] [ 1 1 ]
[ 1 1 ] [ 0 1 ] [ 1 0 ]
[ 0 0 ] [ 1 0 ] [ 1 0 ]
[ 0 1 ] [ 1 0 ] [ 1 1 ]
[ 1 0 ] [ 1 0 ] [ 0 0 ]
[ 1 1 ] [ 1 0 ] [ 0 1 ]
[ 0 0 ] [ 1 1 ] [ 1 1 ]
[ 0 1 ] [ 1 1 ] [ 0 1 ]
[ 1 0 ] [ 1 1 ] [ 1 0 ]
[ 1 1 ] [ 1 1 ] [ 0 0 ]

• This question is unanswerable. You implemented a precoder which you do not describe very much, and which might, or possibly might not, be the same as the one mentioned in the link you provide. Now you ask "Why it is necessary?" You need to tell us why you thought it was necessary to have a precoder in your system. How can we tell why a precoder that you designed and about which we have no knowledge is necessary for your system? – Dilip Sarwate Mar 8 '13 at 0:12
• @DilipSarwate, I've made the question clearer. I've checked and what I implemented was the same as the precoder suggested in the paper. – Dan Sandberg Mar 8 '13 at 19:25

Regard the dibits as Gray code representations of the integers $0,1,2,3$, more specifically,

$$[0, 0] \leftrightarrow 0, ~~ [0, 1] \leftrightarrow 1, ~~ [1, 1] \leftrightarrow 2, ~~ [1, 0] \leftrightarrow 3.$$

Then, the precoding scheme is nothing but differential encoding for QPSK with

to send = prev - to_encode modulo $4$.

For example the line [ 1 0 ] [ 0 1 ] [ 1 1 ] in the question says that to encode $3 =$ [1 0] when the previous symbol was $1 =$ [0 1], we send $1-3 = -2 \equiv 2 \bmod 4$ where $2 =$ [1 1].
As stated in the answers and comments on the previous question,

Differential encoding for QPSK is not the same as differential (binary) encoding of the I and Q bit streams separately.

So the precoding scheme is just differential encoding for QPSK. As to why it is included in the system, it must be that the channel characteristics and system requirements are such that coherent detection of the signal is not thought to be feasible, and so the receiver is being implemented is a differentially coherent detector for DQPSK (differentially encoded QPSK). Note that coherent detection requires that the receiver phase lock loop acquire (and track) the incoming carrier in both frequency and phase (including resolution of the four-fold phase ambiguity) while for differentially coherent detection, frequency acquisition and tracking suffices, so that the receiver is simpler and more robust, though of course for a given SNR, the BER of the differentially coherent receiver is higher than the BER of the coherent receiver.

• Thanks Dilip, I've confirmed you're right. I suspected that at first but when I tried implementing it I didn't get the correct results. Looks like I just messed-up the implementation. Thanks again. – Dan Sandberg Mar 9 '13 at 12:45

Differential encoder to the Gray mapping is to remove the 90 degree phase variance, e.g. the received constellations are 90 degree rotated. The receiver doesn't reply on the absolute phase of the QAM constellations but uses the transition between consecutive symbols to demodulate the data.