Technical Articles and Newsletters |

By Cyril Iskander Signal Processing Consultant, formerly with Averna

Digital radio is rapidly establishing a foothold in the market, placing new demands on receiver manufacturers. Today's receivers must support XM, Sirius, Digital Audio Broadcasting (DAB), HD Radio, Radio Data System (RDS), Global Positioning System (GPS) protocols, and a wide variety of other broadcast and navigation standards. To test their receivers, manufacturers often require several costly hardware platforms, one for each standard supported. This test setup is not only expensive; it is also inconvenient for the engineers, who must configure multiple test environments and switch between them to test different protocols.

The Averna Universal Receiver Test (URT) platform is a software-defined radio frequency (RF) signal source that lets manufacturers test their devices against a range of standards using a single, integrated platform. Engineers can easily update the URT to support additional protocols as testing needs change or new standards emerge.

We wrote, debugged, optimized, and tested the core URT algorithms for the XM and Sirius standards in MATLAB^{®}. This workflow enabled us to verify our design before deploying it to an FPGA. We used our MATLAB simulation results to verify the FPGA implementation, giving us confidence in our production hardware.

Averna developed an early version of the XM and Sirius Toolkits for the URT platform in C and C++. Although the toolkits worked well, the development process was arduous, and toolkit functionality was limited. For example, the C and C++ implementation could generate the two satellite beams and one terrestrial beam in the Sirius band individually but was not fast enough to generate all three simultaneously. Similarly, it could not simultaneously generate the six beams required by the XM standard (Figure 1).

These limitations were minor, however, compared with the difficulties we faced in developing these URT toolkits in C and C++. We had to test our algorithms on the hardware, which meant slow and costly iterations. After writing a new algorithm or altering an existing one, we had to compile the code, deploy it to the hardware, and then check the results with a spectral analyzer. Slow development iterations made it difficult to find the optimal combination of parameters to maximize performance. Further, debugging the software as it ran in real time was exceptionally difficult. Developing a solution that worked *well enough* took so long that it left little time to refine and optimize the design.

The key to accelerating development was to design, debug, and optimize our algorithms in MATLAB before implementing them in hardware. We could then use the MATLAB simulation results as a reference to verify the FPGA implementation.

The Sirius and XM multibeam generators that we were creating required similar modulation components, including differential quadrature phase-shift keying (DQPSK) and coded orthogonal frequency division multiplexing (COFDM) schemes. Both generators also required similar filtering, waveform generation, and upconversion components. Using built-in functions in MATLAB, Communications System Toolbox™, and Signal Processing Toolbox™ we quickly developed algorithms for these components without having to code in C. As we developed the algorithms and tested new ideas, we created power spectral density plots in MATLAB to visualize the intermediate results and the final output.

Once we had verified the system's basic functionality, we began optimizing it for deployment on a low-cost FPGA. MATLAB lets us design a filter with as many filter tap coefficients as needed to produce an almost perfect signal. In practice, however, implementation on our FPGA required us to limit the filter to relatively few coefficients. In MATLAB, we ran multiple simulations using different combinations of filter coefficients until we identified a set that would fit easily on the FPGA and meet the system's performance requirements.

Handling the different data rates used in satellite and terrestrial broadcasting presented another optimization challenge. XM and Sirius complement their satellite broadcasts with terrestrial broadcasts to provide coverage in both rural and urban settings. However, the two standards use different data rates for these signals, and the rates are not integral multiples of each other. We had to identify a sampling rate that would enable the terrestrial and satellite signals to be combined and synchronized. The bigger challenge was that the sampling rate we chose had to be high enough to yield a quality signal but not so high that we could not implement it in real time on the FPGA. We used MATLAB to explore a variety of algorithms and methods until we identified one that handled the disparate data rates and that our engineers could implement efficiently on an FPGA.

A key differentiator for the URT as a product is its low cost compared with hardware solutions that support a single standard. To meet our goal of delivering a more affordable test platform, we used a low-cost Xilinx^{®} Virtex^{®}-5 LX50 FPGA. Many of the optimizations that we performed in MATLAB were undertaken to ensure that the algorithms could be efficiently implemented on this FPGA. Even with those optimizations, however, the algorithms had to be carefully coded in VHDL to ensure they would fit on the FPGA. Averna has a number of skilled engineers with years of experience in writing VHDL for signal processing applications. These engineers used the MATLAB algorithms as a basis for developing the VHDL code for the URT in Xilinx ISE^{®} Design Suite.

After running the VHDL code in the Xilinx simulator, we compared those simulation results with the simulation results from MATLAB to ensure that the VHDL implementation was a bit-true representation of the MATLAB model (Figure 2).

We verified the final FPGA implementation of the URT in three ways. First, we simply ensured that a standard XM or Sirius receiver could lock onto the URT output signal and use it to play the test broadcast stream. Second, we examined the bit error rate reported by the receiver hardware to ensure that it was close to zero. Third, we used a spectrum analyzer to verify that the URT did not generate too much adjacent channel interference.

As an additional debugging and verification step, we can generate a signal from our MATLAB model and then broadcast it to a receiver using the RF Player in the URT.

We used this functionality during development to play back a file containing the results of our MATLAB simulation. The MATLAB RF Record and Playback Toolbox, which ships with the URT, converts waveforms created in the MATLAB environment into a format compatible with the RF Player for RF streaming. We can then listen to the signal produced by the RF Player via an XM or Sirius receiver. This setup lets us audibly compare the output from our MATLAB model with output from the FPGA implementation. If the MATLAB signal is clear and the FPGA signal is garbled, then we know there is a problem with the FPGA implementation. If both signals are garbled, then we know there's a problem with the underlying algorithm.

The MATLAB RF Record and Playback Toolbox also enables URT users to import RF recordings obtained using the RF Recorder into the MATLAB environment for further baseband processing and analysis.

The algorithms for multibeam Sirius and XM signal generation, developed using MATLAB, are now delivered as part of the toolkits for the URT platform (Figure 3).

Our original design for multibeam generation in C was never completed. When implemented in hardware, the design did not meet our quality standards, and attempts to debug the design using the old compile-deploy-test cycle took too long. Instead of spending up to an hour on that cycle to test a new idea or new set of parameters, we can now complete the same task in MATLAB in minutes. It took us less time to develop the production version using MATLAB than it would have taken simply to debug the version we had already written in C. The production version meets all quality standards and is easy to maintain.

Published 2011 - 91981v00