# root/ossiedev/branches/jsnyder/STTT_paper/sttt-draft.tex@11104

Revision 11104, 47.2 KB (checked in by stedwar2, 12 months ago)

Updated for final submission.

Line
1%%%%%%%%%%%%%%%%%%%%%%% file template.tex %%%%%%%%%%%%%%%%%%%%%%%%%
2%
3% This is a template file for the International Journal on
4%                            Software Tools for Technology Transfer
5%
6% Copy it to a new file with a new name and use it as the basis
8%
9%%%%%%%%%%%%%%%%%%%%%%%% Springer-Verlag %%%%%%%%%%%%%%%%%%%%%%%%%%
10%
11
12%
13\documentclass[sttt,referee]{svjour}
14% Remove option referee for final version
15%
16% Remove any % below to load the required packages
17%\usepackage{latexsym}
18\usepackage{graphicx}
19\usepackage{stfloats}
20\usepackage{fixltx2e}
21% etc
22%
23\begin{document}
24%
25\title{Open Source Software Defined Radio Tools for Education, Research, and
26Rapid Prototyping}
27\author{Jason~Snyder, Deepan~Seeralan, Shereef~Sayed, Jeffery~Wilson,
28Carl~B.~Dietrich, Stephen~H.~Edwards, and Jeffrey~H.~Reed}
29%
30%
31\institute{Virginia Tech, Blacksburg, VA}
32%
33\date{Received: date / Revised version: date}
34% The correct dates will be entered by Springer
35%
36\authorrunning{Snyder, Seeralan, Sayed, Wilson, Dietrich, Edwards, Reed}
37\titlerunning{Open Source SDR Tools}
38\maketitle
39%
40\begin{abstract}
41Software Defined Radios (SDR) offer several advantages over traditional, hardware-based radios, most notably flexibility and reconfigurability. Developing SDR applications can be a difficult process however, for several reasons. First, much of the work involved deals with standards compliance, rather than radio functionality. This portion of the work is very detailed and error-prone, leading to wasted time and effort. Second, there is little to no support available for the debugging and refinement portions of the development cycle. There is no easy way to monitor or control SDR applications at runtime. The Waveform Workshop was created to address these issues. A part of the OSSIE SDR project, the Waveform Workshop drastically reduces the time and effort involved in SDR development. It automatically generates the portions of the software related to standards compliance, letting developers concentrate on radio functionality. In addition, the Waveform Workshop provides tools for both monitoring and controlling SDR applications at runtime, making debugging much easier.
42\keywords{Software Defined Radio, Rapid Prototyping Tools, Education, OSSIE}
43\end{abstract}
44%
45\section{Introduction}
46\label{introduction}
47Software Defined Radios involve software implementation of radio functionality that is traditionally performed by analog hardware and digital application specific integrated circuits (ASICs).  An SDR employs general purpose processors (GPPs), digital signal processors (DSPs), and field programmable gate arrays (FPGAs) that can be programmed or configured to provide great flexibility and support for multiple radio communications standards or waveforms.  Within the limits of its hardware, a well-designed SDR can support standards that were not conceived at the time the radio was designed \cite{Reed2002}.  SDRs are of interest for both commercial \cite{Vanu} and military \cite{JTRS} applications.
48
49Unfortunately, developers writing SDR software frequently face problems that are not addressed by traditional development tools.  This first problem is ensuring that SDR software conforms to the Software Communications Architecture (SCA) standard. The standard is very complex, with many details that are necessary for compliance but unrelated to the functionality of the radio itself.  Another common problem SDR developers face is the lack of any way to interact with running SDR applications.  SDR applications are deployed as collections of CORBA software components running on one or more processors.  Software component configurations are recorded in XML files loaded by the CORBA components on start up.  In this situation, the primary way to change a property value for a given component is to shut the application down entirely, change a value in one of the XML files, then restart the application. Finally, developers also have no readily available tools to monitor a running SDR application as it operates.
50
51To address these problems, we have developed a set of software tools that constitute the Waveform Workshop. The Waveform Workshop was designed to work with the OSSIE open source SDR project, a partial implementation of the U.S. Department of Defense's Software Communications Architecture (SCA) \cite{sca}, \cite{bard}, \cite{Aguayo2009a}, a standard architectural specification for SDRs.  The Waveform Workshop aids developers by automatically generating the parts of the software that relate to SCA compliance.  The developer can then concentrate on implementing the radio itself.  The Waveform Workshop also provides developers with a means to update application properties at runtime directly, without editing configuration files or restarting the application. This greatly reduces the time needed to debug applications.  Finally, the Waveform Workshop provides an interface displaying block diagrams of running SDR applications. This interface allows developers to take the output from an application, or any component within an SDR, and play it through speakers or plot it on a graph. This allows the developer to easily change application properties and observe the effects of those changes in real time, making it much easier to debug and refine SDR software.
52
53In this paper, we discuss the problems faced by SDR developers and how those problems are addressed by the Waveform Workshop.  Section~\ref{background} discusses the need for SCA-based development tools for SDR projects.
54Section~\ref{waveformworkshoptools} introduces the tools that are part of the Waveform Workshop and the problems they solve. Sections~\ref{sdrapplicationdevelopment-oef} through \ref{sdrapplicationdevelopment-alf} describe
55their use in developing, configuring, and monitoring a waveform application. Finally, Section~\ref{conclusion} concludes and presents future work.
56
57
58\section{Background}
59\label{background}
60
61\subsection{Motivation for SCA-Based SDR Tools}
62\label{toolmotivation}
63The SCA is an open standard associated with the U.S. Department of Defense Joint Tactical Radio System (JTRS) \cite{JTRS}.  The SCA is a component- and service-based architecture that delineates and provides guidance for implementation of SDR infrastructure (e.g., the SCA core framework) and application software (e.g., waveform applications and signal processing components).  The SCA makes extensive use of software design patterns \cite{Gamma}, and of other standards that include POSIX \cite{POSIX}, CORBA \cite{CORBA}, and XML \cite{XML}.  Components in the SCA communicate using Common Object Resource Broker Architecture (CORBA) middleware, which provides interprocess communication and remote procedure call capability, allowing methods associated with remote components implemented in a variety of languages to appear as local function calls.  XML is used to store profile or configuration information.
64
65The extensive nature of the SCA and its use of CORBA and XML both motivate and facilitate development of tools for SCA-based SDR development.  In most cases it is desirable to abstract the interface code required by CORBA from communications engineers who develop signal processing components and waveform applications.  Fortunately, use of CORBA also allows SCA-based SDR software tools to interact with SCA core frameworks and applications that are running either locally or remotely, while tools can parse XML files to obtain information needed to perform a variety of functions.
66
67Commercial tools for SCA-based SDR development are available \cite{SpectraCX}, but the Waveform Workshop fills a need for an open-source SCA-based SDR tool set.  These tools allow prototyping of SDR waveform applications that can be ported to work with commercial SCA software \cite{singh}, such as the Harris Domain Manager Tool Kit (dmTK) \cite{dmtk}, the SCA Reference Implementation (SCARI) tools from the Canadian Communications Research Centre \cite{jianxin}, and Prism Tech's Spectra CX.  The latter retails for as low as \$15,000 per team member based on a 10-member team \cite{prismtech}. The GNU Radio Companion (GRC) \cite{gnuradio} is an open source tool for SDR that provides many capabilities similar to those of the tools described in this paper, but is not based on the SCA. 68 69\subsection{OSSIE} 70The Open Source SCA Implementation::Embedded (OSSIE) project \cite{Aguayo2009b}, \cite{ossieweb} was started in 2003 by postdoctoral fellow Max Robert and a team of students at Virginia Tech \cite{Robert2004}. OSSIE software consists of a core framework and a library of application software (signal processing components and waveform applications). The project also provides materials for SDR education, training, and self study. 71 72The OSSIE software, including the Waveform Workshop, is a widely used and distributed software package. There have been over 20,000 downloads of the OSSIE source code, ready-to-run live DVDs, and VMware images. Students and engineers at over 20 different universities, companies, nonprofit research centers, and government laboratories have used OSSIE. 73 74 75\section{Improving the SDR Development Process} 76\label{waveformworkshoptools} 77 78SDR frameworks such as OSSIE can be used without specially designed developer tools, but it is a difficult and error-prone process. Component and waveform XML descriptors must conform to the SCA and have to be written and installed by hand. Controlling waveforms is typically limited to starting and stopping them, and there is no easy way to monitor or manipulate running waveforms. The Waveform Workshop solves these problems by: 79 80\begin{enumerate} 81\item Streamlining the development process by automatically generating the necessary infrastructure to ensure SCA compliance. 82 83\item Providing a means to control and manipulate SDR waveforms at runtime. 84 85\item Providing a means to observe SDR waveforms at runtime, including the ability to inject input to or monitor output from components. 86\end{enumerate} 87 88\subsection{Automating SDR Development} 89\label{toolsdescription:oef} 90The OSSIE Eclipse Feature (OEF) is the first tool in the Waveform Workshop and was created to automate as much of the SDR development process as possible. OEF is a port of the OSSIE Waveform Developer (OWD), an open-source Python tool for rapid component and waveform prototyping. OEF automatically generates the necessary XML descriptors and CORBA-enabled skeleton implementations for SCA-based signal processing components, as well as XML files that specify instantiation, interconnection, and deployment of these components to form end-to-end communications waveforms. 91 92In the case of signal processing components, the SDR developer who used the earlier OWD tool still needed to fill in the implementation by using his or her editor of choice to complete each component's skeleton code. Finally, the component or waveform files had to be built and installed from the command line using automake tools. In addition to duplicating the automatic generation functionality of OWD that ensured SCA compatibility, OEF also adds support for the rest of the development process. To do so, OEF was developed as a plug-in for Eclipse, a popular open-source development environment. Along with providing the automatic generation from OWD, OEF also takes care of building and installing components and waveforms, eliminating many opportunities for introducing user error. It also brings all the advantages of a modern IDE. This includes syntax highlighting of source code in multiple programming languages, a simple-to-use interface for version control systems such as CVS and SVN, and project management tools. 93 94\subsection{Controlling SDR Applications in Real Time} 95\label{toolsdescription:wavedash} 96The second tool in the Waveform Workshop is the Waveform Dashboard (WaveDash), which allows users to control SDR applications in real time. WaveDash is an interactive and reconfigurable graphical user interface (GUI) tool that acts as a control panel for working with multiple SDR waveform applications and their components. This tool abstracts the SCA interfaces and the implementation of the OSSIE core framework by providing a direct manipulation interface to control and configure SDR waveforms interactively. 97 98Users can install, start, stop, and uninstall a running waveform application using WaveDash. More importantly, it allows users to configure the properties of a waveform's components in real time. Prior to WaveDash, all property settings were loaded by a component when it started execution, and no interface was readily available to change them other than editing XML files and restarting the application. 99 100In addition, the WaveDash interface is customizable on a per-waveform and per-component basis. Users can choose the type of widget they prefer to represent a particular property of a component and can also hide or unhide specific components or properties. This allows developers to tailor WaveDash to create a custom GUI for manipulating any waveform in the way that best suits their personal workflow. 101 102 103\subsection{Monitoring SDR Applications in Real Time} 104\label{toolsdescription:alf} 105The Waveform Workshop monitors running SDR applications with a tool called ALF. The initial version of ALF was contributed to the OSSIE project by SAIC in 2007, and Virginia Tech has maintained and enhanced the tool since that time. Implemented in Python, ALF interacts with a local or remote OSSIE Domain Manager via CORBA, and allows users to install, start, stop, and uninstall OSSIE waveforms, and to display a waveform in the form of a block diagram of its CORBA components and their interconnections. ALF includes plug-in tools that can be used to inject signals into signal processing components and to monitor signals at various points in a waveform application by playing those signals through speakers or by plotting them on a graph. 106 107%-------------------- FIGURE: SDR Development using Waveform Workshop -------------------- 108\begin{figure*} 109\centering 110%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 111\includegraphics[width=\textwidth]{SDR_Development_using_Waveform_Workshop_bw.pdf} 112% trim = left bottom right top 113\caption{SDR application development using the OSSIE Waveform Workshop tools.} 114\label{fig:sdrdevelopmentdiagram} 115\end{figure*} 116 117Figure~\ref{fig:sdrdevelopmentdiagram} shows how these three tools interact with waveform application software and the OSSIE core framework. 118 119\section{SDR Application Development Work Flow, Part I: Creating Components and Waveform Applications using the OSSIE Eclipse Feature} 120\label{sdrapplicationdevelopment-oef} 121 122\subsection{Creating a Component} 123\label{sdrapplicationdevelopment-oef:creatingcomponent} 124OEF helps developers to create signal processing components. The developer specifies characteristics of the component such as ports and reconfigurable properties, and OEF generates the corresponding CORBA-enabled skeletal code. The developer then provides or links to signal processing code that implements the desired functionality. While more complex components can be developed using the same approach, the following example describes creation of a simple signal processing component, an amplifier that scales the incoming signal by a constant gain factor. 125%-------------------- FIGURE: GENERATING NEW COMPONENT -------------------- 126\begin{figure*} 127\centering 128%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 129\includegraphics[width=\textwidth]{figure2_oef_generating_new_component.pdf} 130% trim = left bottom right top 131\caption{Generating a new component in OEF.} 132\label{fig:oef:generatenewcomponent} 133\end{figure*} 134To create a signal processing component, the user first opens Eclipse and selects Window$\rightarrow$Open Perspective$\rightarrow$Other. The user then chooses OSSIE from the list. This opens the OSSIE perspective, a special Eclipse layout designed for SDR development. Next, the user chooses File$\rightarrow$New$\rightarrow$OSSIE Component to open the New OSSIE Component Project'' wizard. The user then fills in the name for the project, in this case amplifierIQ'' and clicks on finish. This creates a new component project called \texttt{amplifierIQ} with a \texttt{makefile} and a component definition file (\texttt{.ocd}), which is opened in the Component Editor as seen in Figure~\ref{fig:oef:generatenewcomponent}. 135The component editor has the following four sections: 136\begin{enumerate} 137\item Description---to provide a textual description for the component. 138\item Generation Options---to specify what type of component to generate. 139\item Ports---to specify the ports the component will have. 140\item Properties---to specify which properties the component will have. 141\end{enumerate} 142The user enters the following descriptions for the component, in this case, Amplifier with independently adjustable gains for in-phase and quadrature signal components.'' Under generation options, the user selects basic\_ports'' from the template drop-down menu and leaves both ACE Support'' and Timing Port Support'' unchecked. Selecting basic\_ports'' will create a C++ component. The other options in the template drop-down, custom\_ports'' and py-comp'', are for components that use an alternative set of interfaces and for Python components, respectively. Checking ACE Support'' would let the component use certain features of ACE \cite{ACE} such as ACE threads, and checking Timing Port Support'' adds profiling support when using the custom ports or Python component options. 143 144\subsection{Adding Ports to a Component} 145\label{sdrapplicationdevelopment-oef:addingports} 146 147%-------------------- FIGURE: ADD PORT PORT DIALOG -------------------- 148\begin{figure} 149\centering 150%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 151\includegraphics[width=8.5cm]{figure3_oef_add_port_dialog.png} 152% trim = left bottom right top 153\caption{The Add Port'' dialog.} 154\label{fig:oef:addport} 155\end{figure} 156 157The next step is to add ports to the component. Ports allow components to communicate with one another. The user clicks on the Add'' button to bring up the Add Port'' dialog, as shown in Figure~\ref{fig:oef:addport}. Next, the user enters amp\_output'' for the port name. As defined by the SCA, a \textit{uses} port is an output port while a \textit{provides} port is an input port (a backwards'' naming convention due to the client/server orientation of the CORBA remote procedure call implementation of ports). Since this port will be an output port, the user selects Uses'' from the Port Type'' drop-down menu. To choose the type of interface, the user clicks the arrow next to Standard Interfaces'' and selects complexShort'' from the choices that appear. Finally, the user clicks OK'' and sees the new port in the Ports'' table. All three fields in the Ports'' table are editable in place, so the user can change the name, interface, or type of any port after it has been added. Selecting any port and clicking the Remove'' button will delete the port from the component. This component also requires an input port called \texttt{amp\_input} that is also a \texttt{complexShort}, so the user adds another port using the same process 158 159\subsection{Adding properties to a component.} 160\label{sdrapplicationdevelopment-oef:addingproperties} 161 162%-------------------- FIGURE: ADD PROPERTY DIALOG -------------------- 163\begin{figure} 164\centering 165%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 166\includegraphics[width=8.5cm]{figure4_oef_add_property_dialog.png} 167% trim = left bottom right top 168\caption{The Add Property'' dialog.} 169\label{fig:oef:addproperty} 170\end{figure} 171 172The final step to configure a component is to add any reconfigurable properties it will need. Our amplifier needs two properties: \texttt{I\_gain} and \texttt{Q\_gain}, which multiply in-phase and quadrature components of the signal, respectively. The user clicks the Add'' button in the Properties'' section of the component editor to bring up the Add Property'' dialog as shown in Figure~\ref{fig:oef:addproperty}. The user enters I\_gain'' for the name and 1'' for the value. The rest of the attributes are left as the defaults, so the user clicks Add Property''. The process is repeated for a \texttt{Q\_gain} property. 173 174\subsection{Generating a skeleton implementation.} 175\label{sdrapplicationdevelopment-oef:skeletonimplementation} 176 177%-------------------- FIGURE: GENERATED PROJECT -------------------- 178\begin{figure*} 179\centering 180%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 181\includegraphics[width=\textwidth]{figure5_oef_newly_generated_component_project.pdf} 182% trim = left bottom right top 183\caption{A newly generated component project in OEF.} 184\label{fig:oef:generatedproject} 185\end{figure*} 186 187At this point, all of the configuration for the component is complete. The next step is to generate the XML descriptors and skeleton implementation files. The user selects Generate Component'' from the OSSIE menu to start the generation. OEF will run the necessary commands and show the output in the console view. After generation is complete, the new files will appear in the Project Explorer view, as seen in Figure~\ref{fig:oef:generatedproject}. 188 189\subsection{Filling in Implementation Code} 190\label{sdrapplicationdevelopment-oef:implementation} 191 192%-------------------- FIGURE: EDITING CODE IN OEF -------------------- 193\begin{figure*} 194\centering 195%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 196\includegraphics[width=\textwidth]{figure6_oef_editing_code.pdf} 197% trim = left bottom right top 198\caption{Editing code in OEF.} 199\label{fig:oef:editingcode} 200\end{figure*} 201 202Once the component has been generated, the user has to fill in the skeleton with implementation code. The user double-clicks on \texttt{amplifierIQ.cpp} in the Project Explorer to open the file in a C++ editor as shown in Figure~\ref{fig:oef:editingcode}. After filling in the custom implementation that operates on the input signal using the specified property (gain) values, and sends the processed signal to the output port, the file is saved. As long as there are no errors, OEF automatically builds and installs the component. 203 204\subsection{Creating and Configuring a Waveform} 205\label{sdrapplicationdevelopment-oef:waveform} 206Now that the user has successfully created and built a component, that component can be used in a new waveform. The example waveform illustrated in this section will be a simulated QPSK communications link that runs entirely on a single computer, but essentially the same approach is used to develop a radio communication waveform application that interfaces with RF hardware. To get started, the user selects File$\rightarrow$New$\rightarrow$OSSIE Waveform to open the New OSSIE Waveform Project'' wizard. The user names the project SimpleWaveform'' and clicks on Finish. When the wizard finishes, the user is presented with the main Waveform Editor, as seen in Figure~\ref{fig:oef:waveformeditor}. The waveform editor contains 3 main trees: 207\begin{enumerate} 208\item Available Resources---lists all of the components, devices, and nodes currently installed on the system and available for use. 209\item Waveform---shows all of the components to be used in the current waveform. 210\item Platform---shows the processing and input/output devices that comprise the platform, together with the components in the current waveform that are allocated to each processing device. 211\end{enumerate} 212 213%-------------------- FIGURE: OEF WAVEFORM EDITOR -------------------- 214\begin{figure*} 215\centering 216%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 217\includegraphics[width=\textwidth]{figure7_oef_waveform_editor.png} 218% trim = left bottom right top 219\caption{The waveform editor.} 220\label{fig:oef:waveformeditor} 221\end{figure*} 222 223Note that the component that the user just built, \texttt{amplifierIQ}, is listed under components in the Available Resources'' tree. To begin assembling the waveform, the user drags the \texttt{TxDemo}, \texttt{amplifierIQ}, \texttt{ChannelDemo}, and \texttt{RxDemo} components he will be using to the Waveform'' tree. The user then drags a \texttt{default\_GPP\_node} (which corresponds to a set of XML files for a Device Manager that manages a single x86 GPP) from the Available Resources'' tree to the Platform'' tree. The components are not yet allocated to any nodes, so the user expands \texttt{default\_GPP\_node} to show the device on it, \texttt{GPP1}. To allocate the components to this device, the user drags each component from the Waveform'' tree to \texttt{GPP1} in the Platform'' tree. When a component is allocated to \texttt{GPP1}, the component appears under the \texttt{GPP1} in the Platform'' tree, and the label on the component in the Waveform'' tree also changes to reflect where it has been allocated. 224 225%-------------------- FIGURE: PORTS ON COMPONENTS -------------------- 226\begin{figure*} 227\centering 228%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 229\includegraphics[width=\textwidth]{figure8_oef_ports_on_component.pdf} 230% trim = left bottom right top 231\caption{Ports on components.} 232\label{fig:oef:portsoncomponents} 233\end{figure*} 234 235Next, the user has to connect the ports on the components to one another. The user expands each component in the Waveform'' tree to show their ports, as seen in Figure~\ref{fig:oef:portsoncomponents}. To connect the ports, the user drags a uses port (orange puzzle piece) on top of a provides port (blue puzzle piece). Each port then changes to a combined puzzle piece and its label changes to show which port it is connected to. Once all of the ports have been connected, the final step is to choose an Assembly Controller. To do so, the user right clicks on \texttt{TxDemo1} in the Waveform'' tree and chooses Set Assembly Controller''. Once this is done, the waveform is fully configured and ready to be generated. The user saves the project and OEF automatically generates all of the necessary XML descriptors for the waveform and installs them. 236 237\section{SDR Application Development Work Flow, Part 2: Configuring and Controlling Waveform Applications using WaveDash} 238\label{sdrapplicationdevelopment-wavedash} 239 240%-------------------- FIGURE: WAVEDASH - INSTALL A WAVEFORM APPLICATION -------------------- 241\begin{figure} 242\centering 243%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 244\includegraphics[width=8.5cm]{figure9_wavedash_waveform_menu.png} 245% trim = left bottom right top 246\caption{Installing a waveform application using WaveDash.} 247\label{fig:wavedash:install} 248\end{figure} 249 250WaveDash allows users to control and configure waveform applications in real time. WaveDash can be used to install, uninstall, and configure the properties of the components in a waveform application, such as the one illustrated in Section~\ref{sdrapplicationdevelopment-oef:waveform}. The Waveforms'' menu in WaveDash lists the currently available waveforms on the system. The user pulls down the menu and selects SimpleWaveform'' that was just created (Figure~\ref{fig:wavedash:install}). The sub-menu allows the user to either install a new application instance of the waveform or to preview the components in the waveform and their properties. The user clicks on Install'' to install a new instance of \texttt{SimpleWaveform}. WaveDash displays the waveform applications in a tabbed fashion to allow users to work with multiple waveforms at one time. New waveform application tabs are appended to the right of the most recently installed waveform application. 251 252\subsection{Install a new waveform application} 253\label{sdrapplicationdevelopment-wavedash:installingwaveformapplication} 254The WaveDash toolbar provides controls to start, stop or uninstall the waveform application denoted by the active tab. The user has to click on the appropriate buttons on the toolbar to start, stop or uninstall a waveform application. 255 256\subsection{Show/Hide Components} 257\label{sdrapplicationdevelopment-wavedash:showhidecomponents} 258 259%-------------------- FIGURE: WAVEDASH - SELECT AND DESELECT COMPONENTS -------------------- 260\begin{figure} 261\centering 262%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 263\includegraphics[width=8.5cm]{figure10_wavedash_component_menu.png} 264% trim = left bottom right top 265\caption{Selecting/deselecting components in WaveDash.} 266\label{fig:wavedash:selectdeselectcomponents} 267\end{figure} 268 269The Component'' menu lists the components present in the waveform application denoted by the active tab. The user deselects the component \texttt{RxDemo} from the Component'' menu (Figure~\ref{fig:wavedash:selectdeselectcomponents}) to hide it as it does not have any properties to configure. This feature is particularly useful when the waveform comprises a large number of components and only few of them are required to be configured often. 270 271\subsection{Configure Component Properties of a Waveform} 272\label{sdrapplicationdevelopment-wavedash:configurecomponentproperties} 273The ability to configure component properties at runtime was urgently needed and was one of the prime motivations to develop WaveDash. Prior to development of WaveDash, OSSIE users had to either modify property values in OEF and rebuild the waveform or hand-edit the property values in the component or waveform XML files, then restart the waveform to configure the component property values. 274 275WaveDash enables users to modify component properties at runtime, thus making SDR waveform development more live and interactive. Each property has a GUI widget (such as a text box or slider) associated with it by default based on the property's data type (such as integer or string). The user can change the value of a component property by changing the value of the widget. By default, the property will be updated immediately after the user presses TAB or ENTER. Changes can be immediately seen with the ALF Plot tool (see Section$\ref{sdrapplicationdevelopment-alf:relationwithwavedash}$). In this example, the user changes the value of the \texttt{noise\_std\_dev} property of the \texttt{ChannelDemo} component from its default value of 1000 to a new value of 1500 and presses ENTER for the change to take effect. 276 277%-------------------- FIGURE: WAVEDASH - Update on Refresh -------------------- 278\begin{figure} 279\centering 280%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 281\includegraphics[width=8.5cm]{figure13_wavedash_update_properties_on_refresh.png} 282% trim = left bottom right top 283\caption{WaveDash with Update Properties on Refresh'' enabled.} 284\label{fig:wavedash_update_properties_on_refresh} 285\end{figure} 286 287While the user will normally want component properties to update immediately once the value of the widget has changed, there are times where it is better to be able to change multiple property values and have them all update simultaneously. WaveDash makes this easy to do. Under the Options'' menu, the user can select Update Properties on Refresh''. This will enable the refresh buttons on each component and on the whole waveform, as shown in Figure~\ref{fig:wavedash_update_properties_on_refresh}. When enabled, WaveDash only updates the component property values when one of the refresh buttons is clicked. Clicking the refresh button for a single component updates only that component's properties. Clicking the refresh button at the bottom updates all properties on all components in the waveform. 288 289\subsection{Change Property Configuration Control Widgets} 290\label{sdrapplicationdevelopment-wavedash:configurewidgets} 291The component \texttt{.prf} files determine the data type for each property of the component. WaveDash uses a default mapping of data type (mentioned in PRF files) to appropriate GUI widgets (control) to determine the control used for each property. WaveDash also provides an optional list of widgets which users can customize to their preferences. In this example, the \texttt{packet\_delay\_ms} property of the component \texttt{TxDemo} is mapped to a spin box by default. The user right clicks on the spin box to bring up a context menu with the list of optional widgets configurable for \texttt{packet\_delay\_ms}. The user selects slider'' (Figure~$\ref{fig:wavedash:changepropertywidgets}$) to change the widget on the application GUI. The Configure'' option visible in the context menu is used to set minimum and maximum values for spin box and slider controls. 292%-------------------- FIGURE: WAVEDASH - CHANGE PROPERTY CONTROL WIDGETS -------------------- 293\begin{figure} 294\centering 295%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 296\includegraphics[width=8.5cm]{figure11_wavedash_property_context_menu.png} 297% trim = left bottom right top 298\caption{Changing property control widgets in WaveDash.} 299\label{fig:wavedash:changepropertywidgets} 300\end{figure} 301 302\subsection{Show/Hide Component Properties} 303\label{sdrapplicationdevelopment-wavedash:showhidecomponentproperties} 304It is possible that a component may have so many properties that it is not convenient to display all of the properties at the same time. Users may wish to hide unwanted properties and keep only those that are frequently used visible. In (Figure~$\ref{fig:wavedash:selectdeselectproperties}$), the user right clicks on a component and deselects \texttt{phase\_offset} from the pop-up menu to hide it. 305%-------------------- FIGURE: WAVEDASH - SELECT/DESELECT COMPONENT PROPERTIES -------------------- 306\begin{figure} 307\centering 308%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 309\includegraphics[width=8.5cm]{figure12_wavedash_component_context_menu.png} 310% trim = left bottom right top 311\caption{Selecting component properties in Wavedash.} 312\label{fig:wavedash:selectdeselectproperties} 313\end{figure} 314 315\section{SDR Application Development Work Flow, Part III: Use of ALF Waveform Application Visualization and Debugging Environment} 316\label{sdrapplicationdevelopment-alf} 317 318The ALF environment provides several capabilities that are helpful for troubleshooting and debugging waveform applications. Like WaveDash, ALF allows users to install, uninstall, start, and stop waveform applications. ALF also lets users display running applications as block diagrams as shown in Figure~\ref{fig:alf:block_diagram_plugin_menu}, and inject or monitor signals at various component ports in the application. Port signals are manipulated using provided or user-developed plug-in tools by right clicking on the port (small rectangle on either side of the component) and selecting from a menu, as shown in Figure~\ref{fig:alf:block_diagram_plugin_menu}. Additional features enable creation and installation of single-component waveform applications, and adding connections between ports on components in the same or different waveforms at run time. 319%-------------------- FIGURE: ALF - BLOCK DIAGRAM WITH PLUG-IN MENU -------------------- 320\begin{figure*} 321\centering 322%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 323\includegraphics[width=\textwidth]{figure13_Alf_Block_Diagram_plugins_menu.pdf} 324% trim = left bottom right top 325\caption{ALF shows the SimpleWaveform block diagram and the plug-in tool menu.} 326\label{fig:alf:block_diagram_plugin_menu} 327\end{figure*} 328 329\subsection {ALF Plug-In Tools} 330\label{sdrapplicationdevelopment-alf:plugins} 331Several plug-in tools for ALF are provided as part of the OSSIE distribution. These tools are used to inject signals into component input ports, and to display, record, or otherwise process the signals from output ports. The plug-ins are implemented in Python, and users can modify the plug-ins or develop their own based on those provided. 332 333\subsubsection{Speaker Tool} 334\label{sdrapplicationdevelopment-alf:plugins:soundtool} 335ALF's speaker tool accepts signals in OSSIE's \texttt{complexShort} (2-channel, short integer) interface format and plays the signals through a computer's sound card. It allows the user to set the sampling rate at which the signal will be converted to audio. 336 337\subsubsection{Plot Tool} 338\label{sdrapplicationdevelopment-alf:plugins:plottool} 339ALF's plot tool (Figure~\ref{fig:alf:plugins:plot}) accepts signals from uses ports (output ports) that employ the \texttt{complexShort}, \texttt{complexLong}, or \texttt{complexFloat} interfaces. This tool displays the signal's spectrum on a normalized frequency scale or displays the quadrature vs. in-phase components of the signal in order to render the constellations of received digital signals. In this mode, several symbols are shown that would typically map to regularly spaced points under ideal conditions, e.g. in a circle (phase-shift keying) or in a grid pattern (quadrature amplitude modulation). In a realistic simulation or an operational radio, the symbols appear scattered about the nominal symbol points due to noise, fading, imperfect synchronization, or other anomalies. 340%-------------------- FIGURE: ALF - PLOT TOOL -------------------- 341\begin{figure} 342\centering 343%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 344\includegraphics[width=8.5cm]{alf_plot_tool.png} 345% trim = left bottom right top 346\caption{The ALF plot tool displaying a quadrature phase-shift keying (QPSK) signal constellation.} 347\label{fig:alf:plugins:plot} 348\end{figure} 349 350 351 352\subsubsection{Arbitrary Waveform Generator (AWG) Tool} 353\label{sdrapplicationdevelopment-alf:plugins:AWGtool} 354Figure~\ref{fig:alf:plugins:awg} shows the Arbitrary Waveform Generator, which allows one to select from a number of predefined signal functions or simply read signals that are stored in data files, for the purposes of testing, debugging, or demonstrating components or waveforms. By allowing a signal stored in a data file to be fed into a live SDR component, developers gain the capability of generating signals off-line using software such as MATLAB or replaying signals that are captured live over the air later during testing. 355%-------------------- FIGURE: ALF - AWG TOOL -------------------- 356\begin{figure} 357\centering 358%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 359\includegraphics[width=8.5cm]{figure17_ALF_AWG_Tool.pdf} 360% trim = left bottom right top 361\caption{The ALF AWG tool.} 362\label{fig:alf:plugins:awg} 363\end{figure} 364 365\subsection{Launching Individual Components as Waveform Applications} 366\label{sdrapplicationdevelopment-alf:compform} 367ALF includes a compform'' capability that packages individual components as self-contained waveform applications and deploys them to the default GPP device. This is accessed by clicking on a component in the middle left panel of ALF. The compform'' feature allows a user to test individual components by using the plug-in tools to inject and monitor signals into and out of each component as the component runs in a stand-alone application. 368 369 370 371\subsection{Connect Tool} 372\label{sdrapplicationdevelopment-alf:connecttool} 373ALF's connect tool, shown in Figure~\ref{fig:alf:connect}, provides the capability 374to connect ports on components that are in the same or different waveform applications. This capability, provided with the ability to create and run single-component applications, allows users to build ad-hoc applications by launching components as waveforms and connecting them at run time to form a temporary, larger composite application. The composite application can be configured by using WaveDash to change the properties of its constituent applications. Further, the connect tool provides for automatic instantiation and tear-down of applications, and automated connections and routing of data among standard applications, single-component applications, and plug-in tools, by specifying the applications/components/plug-ins and behavior in an XML file. This enables dynamic reconfiguration of SDR applications at run time, a capability that can be very useful in cognitive radio implementations \cite{Cormier2009}. 375%-------------------- FIGURE: ALF - CONNECT TOOL -------------------- 376\begin{figure} 377\centering 378%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 379\includegraphics[width=8.5cm]{figure18_ALF_Connect_Tool_2.pdf} 380% trim = left bottom right top 381\caption{The ALF connect tool.} 382\label{fig:alf:connect} 383\end{figure} 384 385 386 387\subsection{Relation of ALF with WaveDash} 388\label{sdrapplicationdevelopment-alf:relationwithwavedash} 389When used together, ALF and WaveDash allow the user to observe effects of parameter values on waveform operation interactively and in real time, as shown in Figure~\ref{fig:alf:alfwavedash}. This is very useful for education, experimentation, and debugging of waveform applications. ALF currently provides some of the same functionality as WaveDash, specifically the ability to install, uninstall, start, and stop applications. This functionality is included in both tools so that WaveDash can be used to run applications without the full ALF environment. WaveDash can be launched from within ALF, and further integration is planned. Planned changes include encapsulating all common functionality of the two tools in a single Python module or library. 390%-------------------- FIGURE: ALF AND WAVEDASH -------------------- 391\begin{figure*} 392\centering 393%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf} 394\includegraphics[width=\textwidth]{figure19_ALF_QPSK_Controlled_Wavedash.pdf} 395% trim = left bottom right top 396\caption{ALF and WaveDash used together to monitor and control a waveform.} 397\label{fig:alf:alfwavedash} 398\end{figure*} 399 400\section{Conclusions and Future Work} 401\label{conclusion} 402This paper describes a set of open-source, SCA-based SDR development tools suitable for education, research, and rapid prototyping. These tools ensure SCA compatibility while hiding much its complexity. They exploit the features provided by the SCA to enable an interactive development process. The development process includes creation of signal processing components and waveform applications as well as execution, visualization, monitoring, testing, and run time reconfiguration of waveform applications. The Waveform Workshop tools also allow developers to interact directly with running waveforms and components, as well as to visualize the output from components in real time. 403 404The current state of the Waveform Workshop allows for the work flow shown in this paper, and also allows applications such as \texttt{SimpleWaveform} to be prototyped as ad-hoc applications and then recreated in OEF. Additional development of the tools will enhance this capability by providing the option to display multiple application block diagrams in the same window, make connections by dragging lines between component ports, and formalize ad-hoc applications by saving connection and deployment information in waveform XML files. 405 406Upgrades to the Waveform Workshop are planned as part of current and pending projects. Future work includes: 407\begin{itemize} 408\item Integrating ALF and WaveDash capabilities into Eclipse. 409 410\item Enabling interactive, graphical, block-diagram-based waveform development. 411 412\item Moving to a Java implementations of the tools. 413 414\item Loading waveform and component descriptions by parsing the SCA XML files rather than using dedicated file formats (such as \texttt{.ocd} and \texttt{.owd}). 415 416\item Adding features for collaborative development. 417 418\item Adding model-based development capabilities for greater flexibility. 419 420\end{itemize} 421 422\subsection{New Tools} 423\label{toolsdescription:wavedasharchitecture} 424Finally, two new tools for the Waveform Workshop are under development. The first is a server to enable control of an OSSIE SDR application over HTTP. After installing the server on a computer running OSSIE that is connected to the internet, any waveforms on that computer can be installed and controlled via any other computer with an internet connection. The second new tool is a command line interface to allow a user to control an OSSIE SDR application over an ssh connection or via scripts. Both of these applications are simply alternative interfaces to WaveDash's features to broaden its applicability, and their implementation will use the same backend code to allow them to easily connect to and control OSSIE SDR applications. 425 426\section{Acknowledgements} 427\label{acknowledgements} 428This work was supported by the National Science Foundation under Grant No. 0520418, by Science Applications International Corporation, and by U.S. ARMY CERDEC. 429 430\begin{thebibliography}{00} 431 432%% \bibitem{label} 433%% Text of bibliographic item 434 435\bibitem{Aguayo2009b} 436C. R. Aguayo Gonz$\acute{a}$lez, et al., Open-Source SCA-Based Core Framework and Rapid Development Tools Enable Software-Defined Radio Education and Research,'' \textit{IEEE Communications Magazine}, vol. 47, no. 10, October 2009. 437 438\bibitem{ossieweb} 439OSSIE project web site. \\Available: http://www.ossie.wireless.vt.edu 440 441\bibitem{sca} 442\textit{Software Communications Architecture Specification, 2nd ed.}, Joint Tactical Radio System (JTRS) Joint Program Office, April 2004. 443 444\bibitem{bard} 445J. Bard and V.J. Kovarik Jr., \textit{Software Defined Radio: The Software Communications Architecture}, Wiley, Chichester, West Sussex, England, 2007. 446 447\bibitem{Aguayo2009a} 448C. R. Aguayo Gonz$\acute{a}\$lez , C. B. Dietrich, and J. H. Reed, Understanding the Software Communications Architecture,'' \textit{IEEE Communications Magazine}, vol. 47, no. 9, September 2009.
449
450
451\bibitem{Reed2002}
452J.H. Reed, \textit{Software Radio: A Modern Approach to Radio Engineering}, Prentice Hall PTR, 2002.
453
454\bibitem{Vanu}
455Vanu{\textregistered} Introduces the Anywave{\textregistered} MultiRAN---Wireless Industry's First Software Radio Shared Active Infrastructure Solution, \\Available:  http://www.vanu.com/media/Web%20Site%20Press%20Releases/vanu-multiran-final.pdf
456
457\bibitem{JTRS}
458JPEO JTRS, Joint Tactical Radio System.\\
459Available: http://jpeojtrs.mil
460
461\bibitem{Gamma}
462E. Gamma, R. Helm, R. Johnson, J.M. Vlissides, \textit{Design Patterns: Elements of Reusable Object-Oriented Software}, Addison-Wesley Professional, 1994.
463
464\bibitem{POSIX}
465IEEE Std 1003.1, 2004 Edition.\\
466Available: http://www.unix.org/version3/ieee\_std.html
467
468\bibitem{CORBA}
469OMG's CORBA website.\\
470Available:  http://www.corba.org
471
472\bibitem{XML}
473Extensible Markup Language (XML) 1.1 (Second Edition).\\
474Available:  http://www.w3.org/TR/2006/REC-xml11-20060816/
475
476\bibitem{Robert2004}
477M. Robert, et al., OSSIE: Open Source SCA for Researchers,'' SDR Forum Technical Conference, 2004.
478
479\bibitem{SpectraCX}
480PrismTech and Zeligsoft partner to deliver Spectra CX - a third-generation modeling tool for Software-Defined Radio (SDR/SCA) developers.\\
481Available:  http://www.mil-embedded.com/news/Technology+Partnerships/18395
482
483\bibitem{ACE}
485Available:  http://www.cs.wustl.edu/~schmidt/ACE.html
486
487\bibitem{Cormier2009}
488A.R. Cormier, C.B. Dietrich, J. Price, and J.H. Reed, Dynamic Reconfiguration of Software Defined Radios Using Standard Architectures,'' \textit{Physical Communication}, June, 2010. doi: 10.1016/j.phycom.2009.09.002
489
490\bibitem{singh}
491Singh, S., M. Adrat, M. Antweiler, NATO RTO/IST RTG on SDR: Demonstrating Portability and Interoperability of SCA-Based Waveforms,'' SDR 09 Technical Conference and Product Exposition, Washington, DC, December 1-4, 2009.
492
493\bibitem{dmtk}
495Available: http://www.govcomm.harris.com/dmtk/
496
497\bibitem{jianxin}
498Guan Jianxin, Ye Xiaohui, Gao Jun, Wang Bo, The Flow of Software Defined Radio Waveform Development Based on SCARI,'' In \textit{Proceedings of the 5th International Conference on Wireless Communications, Networking and Mobile Computing}, Beijing, China, 24--26 September 2009. doi: 10.1109/WICOM.2009.5302559
499
500\bibitem{prismtech}
501PrismTech Spectra CX webcast. \\
502Available: http://www.slideshare.net/PrismTech1/spectra-cx-v32-webcast-19-may-2010
503