MarkF
Senior Heliman
Location: Palo Alto, CA
| Hi, Gang!
Sorry that the thread got off-topic; I should have placed my last few posts into the "Omega 16" thread. To talk a bit more about QPSK issues, let me briefly discuss the general approach we're taking to modulation and demodulation, with an eye on the Intermediate Frequency topic I raised earlier.
In traditional QPSK communications, software usually stops at the baseband level, where the TX/RX signal is comprised of two separate waveforms, called 'I' and 'Q' for historical reasons (in the language of complex math, you can think of I as the 'real' waveform component, and Q as the 'imaginary' waveform component). What the hardware in the transmitter does is to modulate both the I & Q components onto a single carrier frequency (or an Intermediate Frequency). Normally, combining two signals would just make a mess, but by shifting the Q waveform by exactly 90 degrees at the I.F., it is possible to transmit two independent waveforms on one carrier. That's the magic of QPSK: two signals in one, with essentially no RF penalty to pay. With apologies to Robert Heinlein, TISATAAFL! Well, almost.
The disadvantage of the traditional approach is that the hardware is more complex and expensive than handling just a single waveform component, needing two D/A converters, two filters, two oscillator outputs, a quadrature mixer, etc. In particular, the requirements to carefully balance the power levels on I & Q, and the need for a very precise phase delay between them is not only demanding, but is a source for many problems that can deteriorate RF performance.
Enter the digital era. Current systems are increasingly moving towards more digital processing, where I & Q become visible only in software. To make this work, it's necessary to perform filtering, modulation and combining completely in software, so just a single signal is presented to the hardware in the transmitter: that signal is what I call a "digital I.F.". As it turns out, an Intermediate Frequency of four times the symbol rate is quite efficient to perform in software. Given the fact that we're working with 12,000 bps, the symbol rate is 6,000 symbols/second. A 4X I.F. would therefore be 24,000 Hz. Since we need to delay Q by 90 degrees before modulating it onto this carrier, that's most easily performed if the signal is sampled at 4X the I.F. frequency, or 96,000 samples/second. That's quite a bit faster than today's R/C gear, which is sending about 4K samples/second to the transmitter.
Moreover, with QPSK these are analog samples, not a simple serial bit stream. Earlier, I briefly mentioned performing filtering in software. In the old world, I & Q filtering was fairly simple, and H/W filters in the transmitter were used to clean up the output signal. Here, we're trying to do much more. If we apply more software horsepower to the problem, it is possible to generate a signal in S/W that is clean enough to be transmitted directly, if it is the right output frequency. In fact, if you look at the spectrum analyzer plot above, you'll see a signal that's extremely clean, thanks to some heavy-duty software processing before the signal was sent directly to the D/A converters.
Since there's no way we're going to generate a 72 MHz signal in software, we'll have to stick with some digital I.F., and I'm hoping that 24 KHz will be acceptable. At 24 KHz, we're already generating 96000 * 16 = 1.5 megabits/second - 384 times more information than today's FSK transmitters! What's even tougher is the filtering that I mentioned. For every single one of those 96,000 output samples per second, currently, 128 multiplications and 127 additions are required just to apply the "square root raised cosine" filter that shapes the I & Q pulses for minimum bandwidth. Before we move the transmitter simulator code off of the PC and onto a real ARM CPU, I'm hoping to be able to recode the filter operation to use a so-called "polyphase" filter approach that could reduce the number of multiplications that are required, but it'll still be a lot of work - particularly on a chip without floating point math.
Even more important is that the receiver has to do exactly the same thing. Using the same 96 KHz sampling rate, it has to perform the exact same filtering operation, despite the fact that it's a particularly power-sensitive device.
All that is background to help explain the current decision point regarding the I.F.. You see, 24 KHz is still a fairly low frequency, and hardware has to convert that into a higher transmit frequency. In order to do so, the transmitter has to mix the base frequency with what's called an L.O. (for local oscillator), and the output of a mixer isn't just A+B, it's actually two frequencies: A+B and A-B. Following the mixer, a filter is then used to filter out either A+B or A-B, as needed, leaving a single output frequency. Now, if we tried to make a conversion to 72.024 MHz in a single step, the transmitter would be faced with the challenge of trying to filter out 71.976 MHz from 72.024 MHz. It's possible, but expensive.
A better way to go will be to use a second I.F., probably at 455 KHz or 10.7 MHz (arbitrary, I know, but since these are commonly-used I.F.s, that's where you can buy R.F. filter components). I'll need to do a bit of discovery and hardware design to figure out what'll be best. Fortunately, this 10 KHz output bandwidth signal, centered at 24 KHz, should be relatively simple to filter at these common I.F.s.
The first step will be to see what the common I.F. is for today's transmitters, which I could always do by a bit of snooping around with a spectrum analyzer inside a transmitter. Another way would be to measure the actual frequency of a transmit crystal (rather than what is printed on it, which ignores the I.F.). If you happen to know what Futaba or J.R. uses for their transmit (and/or receive) I.F.s, I'd greatly appreciate it if you would post it here! I'd definitely prefer to use off-the-shelf TX/RX crystals!
I'm sorry that this took so long, but such is the nature of much of this project; it's surprising how many variables interact in software-defined radio systems! On the other hand, I'm sure enjoying the process of working through them!
Cheers!
MarkF |
Seriously, I know that this can get a bit esoteric, so I'm creating another thread so we don't waste folks' time on the gory details.
It is really nice to finally get the chance to start playing again! Ummm, let's see... finish one QPSK receiver: hard work; start another QPSK receiver: fun?!? Perhaps you're right, after all! 
Seriously, though, thank you!
