MarkF
Senior Heliman
Location: Palo Alto, CA
| Howdy, Folks!
QPSK in the R/C Bands
As I’ve been thinking about the QPSK project, I delved into the FCC rules for R/C transmitters, and have learned a few things. Most importantly, the FCC has assigned 2 KHz guardbands between our control frequencies (essentially 1 KHz on either side of the modulated signal) so that the maximum legal channel bandwidth is 8 KHz, not 10 KHz. Consequently, we won’t have quite as high a data rate as I’d hoped for.
Given an infinite budget, we could approach a data rate of about 40K bits/second. However, that’s a little on the expensive side!  Using QPSK modulation, and a reasonable “alpha”, or “excess bandwidth” figure of 0.25 (meaning that the modulated signal is 25% larger than the symbol rate), we can expect realistic communication rates of 6.4K symbols/second. Since QPSK transmits two bits for every symbol, we’d be able to deliver a data rate of 12.8K bits/second. This throughput would be 2.5 times higher than current generation R/C gear – not bad at all!
The next question is: “Is it legal”? Fortunately, the answer is yes. The FCC specifically permits any form of modulation to be used for our R/C transmitters, as long as it fits within the spectral envelope that they’ve mandated, which isn’t too bad (-25 dB outside the +/- 4 KHz bandwidth region out to +/- 8 Khz, -45 dB from >8 KHz to +/- 10 KHz, -55 dB out to +/- 20 KHz, and about 56 dB beyond that). So, the answer is that this can be done! I’m still collecting information before tackling the QPSK project, but the news is encouraging so far!
The Project
Meanwhile, back to the current project. It’s turned out to be even tougher than I’d thought to create the single-chip receiver, for two reasons. First of all, the 5X oversampling that I’ve specified makes timings extremely tight without DMA, mandating a quite sophisticated event management mechanism. After knocking my head against more than a few walls, there’s now light at the end of the tunnel. While the new structure isn’t quite running yet, I’m getting very close – it should be able to perform simultaneous RF sampling and high-precision servo driving within the next couple of days. Now, that’s still with its own proprietary data format, so nothing will be able to drive it other than test code, but it’s still pretty good progress (about 20 pages of C and assembler code so far).
The second challenge is that in this tight timing environment, the performance of every element counts, and as it turns out, the C compiler I'm using (from IAR Systems) has a terribly inefficient runtime library that’s unbelievably slow, so I’m removing nearly all calls to standard C library functions and replacing them with my own code. In the most extreme example, I sped up the process of moving events around in memory by a factor of about 20X! This has obviously taken a fair amount of time.
Why 5X Oversampling?
Well, to begin with, I’ve never heard of a receiver that uses 5X oversampling, so why not? Won’t it be “a bit better”? Actually, this format is interesting, since it lets us make a stronger determination of whether each received bit is a ‘1’ or a ‘0’. I use each group of 5 samples to index into a lookup table that results in a ‘1’ decision if three or more of the received samples was high, or a ‘0’ decision if three or more samples was low. This will improve SNR [Signal/Noise Ratio] performance considerably, as compared to normal single-sample receivers.
The downside of 5X oversampling is that it leaves very little time between samples. With the new (to me) 8 KHz bandwidth limit, the PCM-FSK version will be pumping through ~6.4K bits/second, which works out to about 31 uS/sample - that's not much time to do anything! So, that’s why it’s taking longer to create than I’d initially thought.
A Bit More about QPSK
However, one great learning experience from this project is that I’ve decided that the compute power available with this core is almost certainly enough to create a single-chip QPSK version. As I mentioned before, we’ll definitely need the kind of DMA controller that the Atmel chip uses to do so, but there is sufficient horsepower to perform the necessary “software-defined radio” tasks.
I’ve decided that my target for QPSK, if I decide to pursue it, will be to use 8X oversampling, which is 51.2 KHz – that’d be 102,400 twenty-four bit samples per second flowing out of the A/D converter (and these are analog samples, not just simple digital samples). While I’d love to use just 8-bit A/D converters, the most appropriate choice here are standard PC stereo audio codecs - we’ll try to live with the additional overhead. Anyway, by using what is known as a “matched filter” architecture, this receiver should be able to deliver much better SNR performance than current FSK gear.
As you can tell, I’m definitely leaning towards creating at least a baseband version of the QPSK receiver (that is, everything but RF), but I’ll need to do more investigating before I commit to it.
For what it’s worth, that’s where things sit at this stage!
Have Fun!
MarkF |
