Image Rejection along A Road Less Traveled.

"I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I--
I took the one less traveled by,
And that has made all the difference" (Frost)

Some time ago we began the process of studying, learning, suffering, failing, and then succeeding that always accompanies the creative process. Many wrong paths were taken. Life always intervenes as ruts in any roads taken. I write this for all those who have suffered with us, demonstrating the utmost patience and most especially to tell our long suffering European friends (with HF broadcaster images) that relief has arrived.

We have known for some time the mathematics of fixing the image suppression due to amplitude and phase imbalance in the QSD. Alex Shavkoplyas has done a fantastic job of following down one road in Rocky. It is a beautiful thing and my favorite cattle prod, Phil Harman, asked me very pointedly "What is the matter with you on this?" I explained and it immediately began to gnaw at me how can we do this. My apologies in advance for it haven taken so long to reach a place of an acceptable algorithm. I wrote a paper that I put in DCC (replete with errors). I followed that up with an article for QEX. I am grateful it was never published. Now the good one will be.

Unlike Rocky, we cannot take more than seconds, much less minutes and hours to converge to a useful image suppression result. Once rocky learns on a particular piece of hardware with its ROCK-bound frequency, it only needs to tweak for changes in temperature, age of crystal components, etc. You the user would be quite unhappy if it were commanded by Big Brother (Flex, DttSP) that you could not tune your radio but once a day! I suspect that amateur radio operator Winston Smith would be in rebellion and Gerald "OBrien" Youngblood could not even torture you to accept it. I know my Julia (Shann N2HPE) has suffered the torture of this with me. I am eternally grateful for her partnership. The ministry of truth has convinced you to be patient. For this I thank you.


Knowing the theory and mathematical equations necessary to accomplish a task does not make it easy to accomplish this in an algorithm. Image present is the result of nonlinearities in the QSD, RFIC, or any SSB mixer (IQ mixer). So nonlinearity must be present in the correct fix up. Nonlinearity introduced on purpose in a system hailed by all for the linearity and signal handling capability of its front end seems at best contradictory, at worst, immolation! Nevertheless, it is required. The application of these nonlinear processes must be done with some care.

Our first attempts at deriving an algorithm that would work in DttSP and PowerSDR succeeded. But they were calibration dependent. Calibration at the factory means man hours and increasing costs to Flex the manufacturer. We accepted the less than acceptable status quo until a month ago because we just didn't have a useful plan to do otherwise. Doubts, internal as well as external, began to consume. The realist among us went "who cares". The idealist averred as to how this was unacceptable. Shouldn't there be a middle way?

Traveling to Austin to work on an implementation of the image suppression algorithm became the top of the list of myriad demands on my time. The top of the heap being the work that is being done by Flex for my employer and sponsor. Knowing the mathematics as described above allows one to write down an iterative procedure where sequential estimation is used to estimate the solution (based on approximations to Newton's algorithm in an application of the fixed point theorem to real life).

The TEN LINES OF CODE were written in an hour. They were working immediately. It was clear that we needed to use something like this but it was unclear how to use it in the system as a whole. It will cause some dislocation to manufacturing, require dislocation to calibration, and require dislocation to the user access to those pieces that the user, heretofore, had come to expect. Klaus Lohman, in expert testing, pointed out an issue which seems troubling but in the end, isn't. But this had to be addressed. We learned that some of the parameters of our search algorithm were wrong. These resulted in occasional numerical instability. We did not have a plan on how to roll this out at all, but we knew we must.

Last week I returned to Austin and the magic of working in a partnership filled with respect but constant questioning allowed by mutual trust, Eric and I worked out a way to use this in any system that would attempt to use it. It is not enough to have the right algorithm in DttSP. The correct application is dependent ON THE USER not the algorithm designer so it requires knowledge of how one correctly uses it in a system for it to be effective.

So eight weeks ago, I added the math to DttSP v3.0. Four weeks ago I put a version in PowerSDR. Last week Eric Wachsmann and I made it practical. The practical comes in asking simply how can this mathematical magic be made useful to the user. It turned out to be remarkably simple. When you tune the radio and you tune it far enough that you change the synthesizer frequency, the algorithm starts a retraining cycle. This must be made stable. So, it starts VERY fast so that the image is almost suppressed completely in about 50ms but then it begins a step by step decrease in gain in the algorithm and at the end of the about 500ms, it has converged. So we can just turn it off then right? Wrong. The algorithm even works on noise BUT its answer is off because loud signal is a better input than noise. So we could not turn the algorithm off completely. We learned we need to leave it turned on at a low convergence rate. Then we ran into the problem that again, you Winston Smith, are not going to allow OBrien dictate to you what to do and think. You are going to tune rapidly and foul this learning algorithm up and the stack would run dry! That too turned out to be relatively easy to fix. If you change the DDS, the convergence algorithm is stopped and restarted and that is done in a thread safe manner.

Now that this lengthy TMI (too much information) account is done, we encourage you to use it. This information is provided for one reason only. So you who have suffered the long wait with us understand something of the creative process and why that MUST be married with the practical.

branches/n4hy/iqtest/bin/Release contains the new code.

I have been experimenting with fixes to the ANF and NR algorithm and I have fixed the complex but separable versions in this branch as well. The ANF and NR is most decidedly not stable code as it will continue to receive work all week long until we have convergence to the acceptable algorithm there as well.

The necessary steps to see this in the trunk must be done in stages. We need resampling in the IQ processing chain. We need to turn the receive training algorithm off when you are transmitting so that transmit training algorithm will run with the benefit of the perfectly adjusted receiver. All of this must be seamless. We learn from experience that you are mostly uninterested in how, you just want the damn thing to work.

Following this, the entire IQ imbalance conversation concerning Flex, QSD, etc. should be long gone. This will be useful for RFIC's, QSD, etc. It will work on RX and TX if you have full duplex hardware (Flex 3000,5000, RFX boards for GnuRadio). It will work on RX on the oldest and meanest of our hardware applications (for example, it will work on SDR-1000) and an appliqué for Flex 5000 and Flex 3000 will allow it to train the transmitter image to the noise floor in YOUR OWN RECEIVER not to mention your ionospheric neighbors.

I will tell you that success is sweet. But I am entirely aware of how long it took. I reject any gratitude because at the end of the process I am really quite critical of my having taken so long to arrive at what, in the end, amounts to no more than 20 lines of code and I had to have excellent help getting there.