Sunday, 26 February 2017
Digital Pre-Distortion Revisted
As I have mentioned before I have been interested in the digital pre-distortion of
Digital TV signals for some time. I have now finally got around to looking at
this problem again.
After a literature search I settled on using the polynomial filter model with memory
to do the pre-distortion. The plan is to use a LimeSDR to do the actual modulation and
a CUDA graphics card to do the maths.
The diagram above is actually quite clever, it uses the input z(n) and output y(n) of the PA
to train a filter to produce the inverse of the PA characteristic. Then it takes the signal to
be transmitted x(n) and passes it through this filter to pre-distort it. The PA then distorts
it back into a signal that looks like the original drive signal x(n).
The filter is not a normal FIR filter whose taps multiply and accumulate a series of
samples, instead the FIR filter is fed with a power series
x(0) x(0)*|x(0)| x(0)*|x(0)|^2 ... x(0)*|x(0)|^N etc
As the PA's characteristic will change slowly over time it should only be necessary to
update the filter coefficients on an infrequent basis. This is good because it means the
very intensive Minimum Mean Square Error (MMSE) estimator does not need
to run all the time.
I plan to use QR Decomposition followed by backwards substitution to estimate the filter
tap values. Fortunately clever people have already written a library to do this for me.
NVIDIA have a library called cuSolver that does it, cuSolver in turn is based on
LAPACK. NVIDIA have very kindly given an example in Appendix C.1 of their toolkit
documentation showing exactly how to do this. The example has to be modified to
deal with complex numbers but that change is trivial.
It may well be better to run the MMSE estimator on the CPU using LAPACK, rather
than on the GPU as for small matrices the CPU is faster. It is only when the matrices
become large that the GPU excels.
The beauty of the LimeSDR is that because of it's USB3 interface there is plenty of
bandwidth available. This is needed because the DPD needs to see about 7 times the
bandwidth of the transmitted signal if it is going to reduce the 3rd, 5th and 7th order
IMD products (shoulders to you DATVers).
Hopefully by doing all this on a PC host rather than using an FPGA I should be able to
get something running fairly quickly. Moving it to an FPGA can come later when I get
some idea of how well it works.
There are a lot of subtleties to this and I have just glossed over it as I didn't want people
to get too bogged down in the maths.
If you are interested in more detail please have a look here Keysight DPD
Wish me luck!