Taming Software-Defined Radio: A graphical user interface for digital communication system prototyping

Dream Stream: Getting around what would have been an arduous learning curve by using Simulink for streaming access to the Universal Software Radio Peripheral 2 (USRP2)

This project proposes to develop a user-friendly Software-Defined Radio (SDR) development workflow for both research and education in wireless communications and networks. This workflow consists of multiple SDR platforms capable of digital modulation, synchronization, and full control over the physical-to-network layer of the radios and an interface to the familiar software package Simulink. Using the Universal Software Radio Peripheral 2 (USRP2) as the Radio Frequency (RF) front end, this interface will use Simulink for software radio development. Employing Simulink for radio development gives us streaming access to the USRP2 without the steep learning curve and underdeveloped development tools associated with current workflows. These commonly available software packages and the USRP2 will make this test-bed affordable yet highly versatile, enabling research groups at Worcester Polytechnic Institute (WPI) and around the world to conduct advanced research into new wireless communications and networking architectures including cognitive radio. The interface will allow students to become familiar with tools used in industry while learning communications and networking concepts through labs designed for undergraduate coursework.

Workflow consists of multiple SDR platforms capable of digital modulation, synchronization, and full control over the physical-to-network layer of the radios and an interface to the familiar software package Simulink. Using the Universal Peripheral 2 (USRP2) as the Radio Frequency (RF) front end, this interface will use Simulink for software radio development. Employing Simulink for radio development gives us streaming access to the USRP2 without the steep learning curve and underdeveloped development tools associated with current workflows. These commonly available software packages and the USRP2 will make this test-bed affordable yet highly versatile, enabling research groups at Worcester Polytechnic Institute (WPI) and around the world to conduct advanced research into new communications and networking architectures including . The interface will allow students to become familiar with tools used in industry while learning communications and networking concepts through labs designed for undergraduate coursework.

Wireless spectrum is a scarce natural resource, and the demand for it increases with each new wireless device. The current model, selling sections of spectrum to one user, leaves much of this precious resource underutilized. Cognitive Radios (CRs) sense the environment they are in and adapt to allow secondary users access to spectrum that is already allocated to a primary user without interfering with the primary users. The enabling technology behind CRs is Software-Defined Radio (SDR). An SDR moves the transition from the digital to the domain close to the Radio Frequency (RF) front end (antenna, power amplifiers, mixers, oscillators, and the like). Doing most of the on general-purpose computational hardware enables on-the-fly reconfiguration. Currently, much of the work conducted by the cognitive radio research community is in the areas of spectrum sensing [1], dynamic spectrum access [2], and agile transmission [3]. However, these research fields are often theoretical in nature. Implementing these new ideas and designs on inexpensive hardware will allow for practical testing. Rapid reconfiguration allows radios to implement multiple standards (IEEE 802.11, GSM, for example) thus making a single device more versatile.

The implementation of SDR systems varies greatly depending on the hardware available. Versatile hardware is often expensive. This expense limits the number of labs that can afford to use that hardware solution. Other development platforms require expensive or DSPs [4] or are the result of large research programs developing their own solution [5] [6] [2]. Since these solutions are not viable for everyone, lower-cost hardware would make SDR development more accessible.

The paper is organized as follows: Devised platform architecture introduces the hardware and software involved along with the driving problems and benefits of the solutions. The new interface is discussed in detail in the following section followed by a review of  testing done with the system and project review and conclusions.

Devised platform architecture

This SDR platform used can be seen in Figure 1. The host system, often a personal computer, does the vast majority of the signal processing. The baseband signal coming from the host is transmitted to the USRP2 over a Gigabit Ethernet connection. The signal is then unconverted to an Intermediate Frequency (IF) by a Cascaded Integrator Comb (CIC) filter, converted to an analog signal, and sent to the RF circuitry on a daughterboard connected to the USRP2 motherboard. The daughterboard upconverts the IF signal to RF to be transmitted. Limited resources on the USRP2 prevent extensive signal processing on the unit itself, but there are enough available resources to add things to the CIC filter located on the FPGA. First the USRP2 hardware is introduced, then its standard software package. In the third subsection we introduce the new system architecture.

21
Figure 1: USRP2 Platform Architecture

 

USRP2 platform

The USRP2 consists of a motherboard and a daughterboard. The motherboard contains the Gigabit Ethernet controller, SD card slot, CPLD, FPGA, , , and connectors for the daughterboards. The CPLD reads a bitfile from the first megabyte of a connected SD card and loads it onto the FPGA, typically consisting of hardware for separate I and Q channels, CIC filters, and Half Band Filters (HBFs) for up-converting and down-converting baseband and IF signals. The HBFs and CIC filter enable sample rate changes by a factor of 2 to 512. DACs generate analog signals that are sent to the attached daughterboard. Unlike the USRP1, the USRP2 only has one transmit and one receive chain, often used together by a single daughterboard. These daughterboards convert the IF signal to the desired passband RF frequency. Different daughterboards provide different frequency ranges, with the specific center frequency set in software.

The USRP2 offers a number of upgrades to the USRP1. The Gigabit Ethernet connection will enable a maximum RF bandwidth of 25 MHz on the USRP2, up from 8 MHz on the USRP. A larger FPGA on the USRP2 will allow for more processing to be done before a signal needs to be sent to the host. Putting DSP steps on the FPGA, which further decimates the signal, will reduce the sample rate on the host system. Advanced features are also available on the USRP2, including the ability to connect multiple USRP2s to create a MIMO system and syncing the hardware via an external clock source [7].

Current software package

The USRP was developed in conjunction with an open source software package called (GR), started in 1998 [8]. The software combines C++ and Python to connect signal processing blocks in a flow graph to create software radios. The signal processing blocks are implemented in C++ to optimize performance. Wrapping the signal processing functions using a SWIG interface lets them be tied together using Python. In Python, a flow graph is constructed by connecting several of these signal processing blocks. Hierarchies of blocks can also be created for more complex systems by creating flog graphs with inputs and outputs and using it as a single block higher in the hierarchy.

With the quickly changing codebase, documentation of the available blocks is difficult, but could be more robust. The code is largely “self” documented by sparsely commented code. More documentation would make development easier for users new to the platform. Researchers trying to develop with GR need to know C++ and Python and then learn the GR framework. This steep learning curve is not only difficult for people familiar with communications, but makes this a poor platform for teaching communications principles. A commonly used, commercially documented, platform would be an ideal development and learning tool.

Proposed system architecture

The new system architecture uses Simulink as a drop-in replacement for GNU Radio. A Simulink block that interfaces directly to the USRP2 has been developed. The key to this block, as described in Section 3, is to provide full control of all the parameters available on the USRP2. Simulink is a software package that interfaces well with the USRP2 because of its streaming focus and common usage [9]. Unlike MATLAB, Simulink is designed to stream time aware samples or frames of samples; important requirements for live over the air transmission. MATLAB and Simulink are both commonly used in industry and academia, lowering the learning curve associated with using this interface. Theoretical systems tested using Simulink can become live over-the-air radios with the simple addition of this block and optimizations focused on real-time communications.

Prior to the USRP2 hardware release, an off-the-shelf interface to the USRP from MATLAB was investigated. This interface used networking blocks from GR and Simulink. Data processed in MATLAB would be sent to a GR flow graph, which would provide the interface to the USRP. This interface would have required a separate control channel and development of a custom GR flow graph. Directly interfacing to the USRP2 from Simulink will allow full control of the USRP2 and remove the added complexity of the GR flow graph.

Proposed Simulink/USRP2 interface

Providing full control over the USRP2 and fully using the capabilities of the hardware is the objective of this interface. The USRP2 is just as configurable as the original USRP. The basic controls need to include center frequency, signal power, and gain and interpolation and decimation rates [7]. Providing these controls in Simulink requires tunable parameters or additional input ports for each of these properties. These basic controls will satisfy student requirements, but more advanced users need advanced controls for MIMO, external clocks, and antenna selection.

Simulink blocks are published as sets in libraries. The USRP2 Library has separate transmit and receive blocks. Additional input ports are made available through the mask, enabling the model to calculate and adjust the parameters of the radio. Depending on the mask settings, the USRP2s are identified by either the Ethernet interface or the MAC address, and the block displays this information. The mask has some help text and all of the parameters needed to configure the USRP2.

A dedicated Gigabit Ethernet interface is commonly used to communicate with the USRP2, so by default the block automatically detects the MAC address of the USRP2 on the specified interface. If more than one USRP2 is on the Ethernet interface, the MAC address can be specified. The exact way to specify the Ethernet interface varies by operating system; the Ethernet interface for a platform is ’eth0’.

The USRP2 has three parameters for the user to control: center frequency; power; and interpolation factor. The range for the center frequency and the power are dependent on the attached daughterboard. The interpolation factor configures filters on the USRP2. By default, the parameters of the USRP2 will be statically set in the mask of the block. The blocks will be able to input these parameters from a port, so the parameter can be calculated in the simulation and changed on the device. Controlling which parameters are visible to the user is done with mask helper functions.

The majority of the parameters for the receiver are similar to the transmitter. The parameters used to identify the USRP2 are the same, as is the center frequency. The power and interpolation factor in the transmitter have direct parallels in the receiver in the gain and decimation factor parameters.

Simulink requires source blocks to specify sample time and frame size. The sample time and frame size are the only two parameters in the receiver that are not in the transmitter. The sample time, or sample step, must use the equation shown.

21
Equation 1: Getting the sample time correct is pivotal to other blocks in the model operating correctly.


The ADC operates at 100 megasamples per second, and that sample rate is then downconverted by the decimation factor, the result is the same rate as the host. The sample time is simply 1 over the sample rate. Getting the sample time correct is pivotal to other blocks in the model operating correctly. The frame size sets the number of samples per frame that the block outputs.

 

Interface testing

Testing this interface proved difficult. Sending and receiving a simple sinusoid was ambiguous due to sample time errors and a lack of synchronization and carrier frequency recovery. These errors were corrected, and testing was done that did not require synchronization. A transmitter was developed to send one of four signals over the air to test the interface. The first signal to be transmitted is a frame of 1000 samples of a complex 1. The data must be complex so the data type is correct for the block, but in this instance the complex component is zero. The second signal generates a frame of 1000 samples of a real sine wave at 30 kHz and adds a zero complex component. The third signal generates 1000 samples of a complex sinusoid. The fourth signal generates frames of random binary data, modulates this data using QPSK, and then pulse shapes the impulses using a Root Raised Cosine (RRC) filter. This transmitter uses an interpolation rate of 512, resulting in a host sample rate of 196,000 samples per second.

A receive model was used to display the data captured using the receive interface. The model simply contains the receive block and an FFT display block. The FFT block uses the sample time to determine the frequency and displays the double-sided FFT of the received signal.

First, constant complex data would be sent from the transmitter to a receiver. This signal would be sent at 2.45 GHz using the XCVR 2450 boards. By sending a constant, a pulse centered on the carrier frequency would be expected. Figure 2 shows the output of the spectrum analyzer. Figure 3 shows the FFT of the data captured by the receiver. The spectrum analyzer shows the transmitter correctly transmitting a pulse centered on the center frequency of 2.45 GHz. Due to frequency carrier offset in the RF hardware, the receiver shows a slightly offset pulse centered on the baseband.

22
Figure 2

23
Figure 3

 

A real sinusoid was transmitted with the same settings on the transmitter and receiver. This 30 kHz sinusoid was generated in Simulink. With a real sinusoid, symmetric peaks are expected at 30 kHz above and below the center frequency. This test confirms a changing in-phase signal is being correctly transmitted. Figure 4 shows this symmetry at passband and Figure 5 shows the data captured by the receiver after being downconverted back to baseband. Again, no carrier frequency recovery is done, causing an offset. The harmonic spurs seen by the spectrum analyzer and receiver are due to not correcting for the frequency and phase response of the upconversion and the analog hardware on the daughterboard.

24
Figure 4

25
Figure 5

 

To ensure both the in-phase and quadrature components of a varying signal are being handled by the interface correctly, a complex sinusoid was transmitted. The complex sinusoid to be transmitted is also a 30 kHz signal. One pulse at 30 kHz above the center frequency is expected. This pulse can be seen at passband in Figure 6 and at baseband by the receive block in Figure 7. As the USRP2 hardware is the same as previous tests, the offset and spurs are still seen.

26
Figure 6

27
Figure 7


The fourth step in the transmitter creates random binary bits, modulates the data using QPSK, and shapes the impulses using an RRC filter. In this test, a wider pulse at the center frequency of the transmitter is expected. Figure 8 shows this pulse at passband and Figure 9 shows the correct downconverted signal. The shaped pulse is seen both at the carrier frequency and at baseband, confirming basic . The signal was not decoded further due to the lack of synchronization. As synchronization techniques are developed, more testing of the digital interface can be done.

28
Figure 8

29
Figure 9


These testing steps showed the basic functionality of the interface and can be used in the future to ensure a setup is working correctly before attempting to debug more complex systems. More complex implementations are currently being developed using the interface.

Conclusion

The testing in Section 4 shows the interface correctly transmitting samples generated in Simulink using the USRP2 hardware. Interfacing to this inexpensive hardware from a software package that is already a common part of many engineering curriculums makes it possible for educational and research labs to use this interface. The low cost of entry, in terms of both costs and prerequisite knowledge, will make this a premier solution for entry-level SDR development.

Acknowledgments

The authors would like to thank The MathWorks for their generous support of this project; especially the technical expertise provided by Ric Losada, Alec Rogers, Mike McLernon, Chandresh Vora, and Don Orofino.

Michael J. Leferman is an M.S. student in Electrical and Computer Engineering at Worcester Polytechnic Institute (WPI), Worcester, MA, USA. He received his B.S. degree in Electrical and Computer Engineering from Worcester Polytechnic Institute in May 2007. Since September 2007, he has been a member of the Wireless Innovation Laboratory. He has been a member of IEEE since 2004 and has been a student branch officer for several years. He can be reached at leferman@wpi.edu.

Alexander M. Wyglinski is an Assistant Professor of Electrical and Computer Engineering at Worcester Polytechnic Institute (WPI), Director of the WPI Limerick Project Center, and Director of the Wireless Innovation Laboratory (WI Lab). He received his Ph.D. degree from McGill University in 2005, his M.S. (Eng.) degree from Queens University at Kingston in 2000, and his B.Eng. degree from McGill University in 1999, all in electrical engineering. Dr. Wyglinski is a member of the IEEE, IEEE Communications Society, IEEE Signal Processing Society, IEEE Vehicular Technology Society, IEEE Women in Engineering, Sigma Xi, and Eta Kappa Nu. His current research interests are in the areas of wireless communications, wireless networks, cognitive radios, software-defined radios, transceiver optimization algorithms, dynamic spectrum access networks, spectrum sensing techniques, machine learning techniques for communication systems, and signal processing techniques for digital communications. He may be reached at alexw@ece.wpi.edu.

Worcester Polytechnic Institute
www.wpi.edu

 

References

[1] Y. Youn, H. Jeon, J. H. Choi, and H. Lee, “Fast spectrum sensing algorithm for 802.22 WRAN Systems,” IEEE, 2006.

[2] K. Nolan, P. Sutton, L. Doyle, T. Rondeau, B. Le, and C. Bostian, “Dynamic Spectrum Access and Coexistence Experiences Involving Two Independently Developed Cognitive Radio Testbeds,” Proceedings of the International Symposium on New Frontiers in Dynamic Spectrum Access Networks, 2007.

[3] Z. Yuan, “Sidelobe suppression and agile transmission techniques for multicarrier-based cognitive radio systems,” Master’s thesis, Worcester Polytechnic Institute, May 2009.

[4] M. Alden, “XILINX Delivers Small Form Factor SDR Development Platform in Collaboration with LYRTECH and Texas Instruments,” Retrieved from http://www.xilinx.com/prs\s\do5(r)ls/2006/embedded/06109sffsdr.htm, November 2006.

[5] S. M. Mishra, D. Cabric, C. Chang, D. Willkomm, B. van Schewick, A. Wolisz, and R. W. Brodersen, “A Real Time Cognitive Radio Testbed for Physical and Link Layer Experiments,” Proceedings of the International Symposium on New Frontiers in Dynamic Spectrum Access Networks, 2005.

[6] G. J. Minden, J. B. Evans, L. Searl, D. DePardo, V. R. Petty, R. Rajbanshi, T. Newman, Q. Chen, F. Weidling, J. Guffey, D. Datla, B. Barker, M. Peck, B. Cordill, A. M. Wyglinski, and A. Agah, “KUAR: A Flexible Software-Defined Radio Development Platform,” Proceedings of the International Symposium on New Frontiers in Dynamic Spectrum Access Networks, 2007.

[7] M. Ettus, “Ettus Research LLC,” Retrieved from http://www.ettus.com/, 2008.

[8] Gnuradio. Available: http://www.gnu.org/software/gnuradio/

[9] Communications Blockset 4, 9868th ed., The MathWorks, 3 Apple Hill Dr. Natick MA, March 2008.