Changeset 10492
- Timestamp:
- 11/10/10 11:34:27 (3 years ago)
- Files:
-
- 1 modified
Legend:
- Unmodified
- Added
- Removed
-
ossiedev/branches/jsnyder/STTT_paper/sttt-draft.tex
r10490 r10492 37 37 % 38 38 \begin{abstract} 39 A set of rapid development, control, and monitoring tools have been developed as part 40 of the OSSIE open source Software Defined Radio (SDR) project, which is based on the 41 U.S. Department of Defense Software Communications Architecture (SCA). SDR is an 42 emerging area of wireless communications in which radio functionality that was previously 43 implemented in analog hardware or digital application specific integrated circuits 44 (ASICs) is instead implemented in programmable and reconfigurable processing devices. 45 By moving this functionality into software, radios can be made more flexible to support 46 a wide range of communications standards or waveforms, limited only by the capabilities 47 of the software developers and the hardware on which the applications will run. 48 Open source SDR software such as that supplied by the OSSIE project provides an important resource 49 for education, research, and rapid prototyping in this interdisciplinary field that 50 integrates several areas within Electrical Engineering, Computer Engineering, and 51 Computer Science. Rapid development tools are needed to abstract the complexities 52 of the SCA from developers and speed application development. The Waveform Workshop, 53 a collection of tools for use with the OSSIE software, enables rapid development, 54 observation, and debugging of OSSIE SDR waveform applications. We describe the 55 functionality and implementation of these tools as well as their use in an SDR 56 application development work flow, and outline planned enhancements.\end{abstract} 39 A set of rapid development, control, and monitoring tools have been developed as part of the OSSIE open source Software Defined Radio (SDR) project, which is based on the U.S. Department of Defense Software Communications Architecture (SCA). SDR is an emerging area of wireless communications in which radio functionality that was previously implemented in analog hardware or digital application specific integrated circuits (ASICs) is instead implemented in programmable and reconfigurable processing devices. 40 By moving this functionality into software, radios can be made more flexible to support a wide range of communications standards or waveforms, limited only by the capabilities of the software developers and the hardware on which the applications will run. Open source SDR software such as that supplied by the OSSIE project provides an important resource for education, research, and rapid prototyping in this interdisciplinary field that integrates several areas within Electrical Engineering, Computer Engineering, and Computer Science. Rapid development tools are needed to abstract the complexities of the SCA from developers and speed application development. The Waveform Workshop, a collection of tools for use with the OSSIE software, enables rapid development, observation, and debugging of OSSIE SDR waveform applications. We describe the functionality and implementation of these tools as well as their use in an SDR application development work flow, and outline planned enhancements.\end{abstract} 57 41 % 58 42 \section{Introduction} … … 61 45 part of the OSSIE open source Software Defined Radio (SDR) project 62 46 \cite{Aguayo2009b}, \cite{ossieweb}, which is based on the U.S. Defense 63 Department's Software Communications Architecture (SCA) \cite{sca}, \cite{bard}, \cite{Aguayo2009a}. These tools allow SDR students, 64 researchers, and developers to create signal processing components and 65 waveform applications for radio communications and to run, configure, control, 66 and monitor operation of these applications in real time. 47 Department's Software Communications Architecture (SCA) \cite{sca}, \cite{bard}, \cite{Aguayo2009a}. These tools solve several problems frequently experienced by developers working on SDR projects. First, they bring modern IDE technology to the SDR development life cycle. While developers have always been able to use a modern IDE when writing source code, there are no IDEs built with SDR development in mind specifically. The tools also automate much of the development process, making development easier and drastically reducing opportunities to make mistakes. Finally, the tools provide a means of monitoring and reconfiguring SDR applications in real time, making it much easier for developers to debug and refine their software. 67 48 68 49 \subsection{Software Defined Radio} … … 81 62 The 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. We have confirmed that students and engineers at over 20 different universities, companies, nonprofit research centers, and government laboratories have used OSSIE. In addition, over US\$3 million in funding for OSSIE projects has supported over 20 graduate and undergraduate students, and more than 10 graduate theses at Virginia Tech, the Naval Postgraduate School, and elsewhere have used the software. OSSIE has served as the basis for three peer-reviewed journal articles, four online articles, and more than 20 conference papers, along with approximately 10 short courses and tutorials serving over 200 participants. 82 63 83 \subsection{Direct Manipulation Tools}84 \label{introduction:directmanipulationtools}85 OSSIE existed before the Waveform Workshop, but was much more difficult to use.86 Component and waveform XML descriptors had to written and installed by hand.87 Controlling waveforms was limited to starting and stopping them, and there was88 no way to monitor or manipulate running waveforms. The Waveform Workshop89 addresses this by providing a direct manipulation interface when creating and90 running waveforms and components. For example, a user might want to create a91 waveform that consists of two components called A and B with a connection from92 A's output port to B's input port. Before the Waveform Workshop, the user would93 have to hand edit the XML descriptors for the waveform, adding elements for each94 component, as well as for the ports and the connection itself. With the Waveform95 Workshop, waveforms are created by simply dragging together icons96 that represent components. The component ports are automatically displayed, and97 connections can be made by dragging one port onto another. The Waveform Workshop then takes care of generating the correct XML descriptors. The Waveform Workshop also provides a direct manipulation interface for running and monitoring waveforms. The user can see a block diagram of a waveform showing each component, and can plot the output of any port. Finally, the user can view and update component property values in realtime, allowing him or her to observe the effects of changing properties.98 99 64 \subsection{Motivation for SCA-Based SDR Tools} 100 65 \label{introduction:toolmotivation} 101 102 66 The 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 communciations engineers who develop signal processing compnents 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. Commercial tools for SCA-based SDR development are available \cite{SpectraCX}, but open source tools that work with OSSIE are needed for educational and research purposes. The Waveform Workshop provides these capabilities to researchers, students, and other SDR developers who use the OSSIE SDR software. Section \ref{waveformworkshoptools} introduces the tools, and Sections \ref{sdrapplicationdevelopment-oef} - \ref{sdrapplicationdevelopment-alf} describe their use in developing, configuring, and monitoring a waveform application. 103 67 104 %-------------------- FIGURE: EMPTY WORKSPACE IN OEF--------------------68 %-------------------- FIGURE: SDR Development using Waveform Workshop -------------------- 105 69 \begin{figure*} 106 70 \centering … … 114 78 \section{The Waveform Workshop Tools} 115 79 \label{waveformworkshoptools} 80 SDR frameworks such as OSSIE can be used without a set of specially designed developer tools, but it is a difficult and error-prone process. Component and waveform XML descriptors have to 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 addresses this by providing a direct manipulation interface when creating and running waveforms and components. For example, a user might want to create a waveform that consists of two components called A and B with a connection from A's output port to B's input port. Prior to the introduction of the Waveform Workshop, the user would have to hand edit the XML descriptors for the waveform, adding elements for each component, as well as for the ports and the connection itself. With the Waveform Workshop, waveforms are created by simply dragging together icons that represent components. The component ports are automatically displayed, and connections can be made by dragging one port onto another. The Waveform Workshop then takes care of generating the correct XML descriptors. The Waveform Workshop also provides a direct manipulation interface for running and monitoring waveforms. The user can see a block diagram of a waveform showing each component, and can plot the output of any port. Finally, the user can view and update component property values in realtime, allowing him or her to observe the effects of changing properties. 116 81 117 82 Currently, three tools make up the Waveform Workshop. These tools can be used in an iterative process of creating, testing, and improving OSSIE signal processing components and waveform applications. The tools are: 118 83 \begin{enumerate} 119 \item The OSSIE Eclipse Feature (OEF), a plug-in for the Eclipse open-source integrated development environmentthat provides capability for creation of both waveform applications and individual signal processing components.84 \item The OSSIE Eclipse Feature (OEF), a plug-in for the Eclipse open-source IDE that provides capability for creation of both waveform applications and individual signal processing components. 120 85 121 86 \item The Waveform Dashboard (WaveDash), a tool that uses information and capabilities available through the SCA to provide an easily reconfigurable graphical interface for interacting with OSSIE waveform applications. … … 126 91 \subsection{The OSSIE Eclipse Feature (OEF)} 127 92 \label{toolsdescription:oef} 128 129 OEF is a port of the OSSIE Waveform Developer (OWD), an open source python tool for rapid component and waveform prototyping. OWD generated the necessary XML descriptors and CORBA-enabled skeleton implementations for SCA-based signal processing components and XML files that specify instantiation, interconnection, and deployment of these components to form waveform applications that implement end-to-end communications waveforms. In the case of signal processing components, the SDR developer who used OWD then had to fill in the implementation using his or her editor of choice. Finally, the component or waveform files had to be built and installed from the command line using automake tools. The motivation behind OEF was to duplicate the automatic generation functionality of OWD, while adding support for the rest of the development process. To do so, OEF was developed as a plug-in for the Eclipse IDE. 93 OEF is a port of the OSSIE Waveform Developer (OWD), an open source python tool for rapid component and waveform prototyping. OWD automatically generated the necessary XML descriptors and CORBA-enabled skeleton implementations for SCA-based signal processing components and XML files that specify instantiation, interconnection, and deployment of these components to form waveform applications that implement end-to-end communications waveforms. In the case of signal processing components, the SDR developer who used OWD then had to fill in the implementation using his or her editor of choice. Finally, the component or waveform files had to be built and installed from the command line using automake tools. The motivation behind OEF was to duplicate the automatic generation functionality of OWD, while adding support for the rest of the development process. To do so, OEF was developed as a plug-in for the Eclipse IDE. 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. 130 94 131 95 \subsection{The Waveform Dashboard (WaveDash)} 132 96 \label{toolsdescription:wavedash} 133 134 97 The Waveform Dashboard (WaveDash) is an interactive and configurable 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. It provides a direct manipulation interface to control and configure SDR waveforms interactively. Users can install, start, stop and uninstall a waveform application, and also can configure the properties of its components in real time. Further, this tool allows the user to customize the interface 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. 135 98 136 99 \subsubsection{WaveDash Architecture} 137 100 \label{toolsdescription:wavedasharchitecture} 138 139 WaveDash was written using a Model-View-Controller (MVC) architecture. The model keeps track of the currently running waveforms along with waveforms on the system available to install. The controller maintains a connection with CORBA and the naming service and can query and configure components running on waveforms in real time. Finally, the view displays information from both the model and the controller. The WaveDash GUI front end was the first view written to work with the model and controller, but two others are currently under development. The first is a server to enable control of an OSSIE radio over http. The second is a command line interface to allow a user to control an OSSIE radio over an ssh session or via scripts. Both of these applications are simply alternative views that use the same model and controller as WaveDash. This allows them to easily connect to and manipulate an OSSIE Radio. 101 WaveDash was written using a Model-View-Controller (MVC) architecture. The model keeps track of the currently running waveforms along with waveforms on the system available to install. The controller maintains a connection with CORBA and the naming service and can query and configure components running on waveforms in real time. Finally, the view displays information from both the model and the controller. The WaveDash GUI front end was the first view written to work with the model and controller, but two others are currently under development. The first is a server to enable control of an OSSIE SDR application over http. The second is a command line interface to allow a user to control an OSSIE SDR application over an ssh session or via scripts. Both of these applications are simply alternative views that use the same model and controller as WaveDash. This allows them to easily connect to and manipulate an OSSIE SDR application. 140 102 141 103 \subsection{The ALF Waveform Application Visualization and Debugging Environment} 142 104 \label{toolsdescription:alf} 143 144 105 The initial ALF tool was contributed to the 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 the waveforms in block-diagram form. 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, and users can develop their own plug-in tools using code from the supplied plug-ins as an example. Additional features allow building ad-hoc applications from individual components at run time. 145 106 … … 147 108 \label{sdrapplicationdevelopment-oef} 148 109 149 150 151 152 153 110 \subsection{Creating a Component} 154 111 \label{sdrapplicationdevelopment-oef:creatingcomponent} 155 156 112 OEF helps developers to create signal processing components. The developer specifies characteristics of the component such as ports and reconfigurable properties, and generates CORBA-enabled skeletal code for OSSIE. 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. 157 113 %-------------------- FIGURE: GENERATING NEW COMPONENT -------------------- … … 186 142 \subsection{Adding Ports to a Component} 187 143 \label{sdrapplicationdevelopment-oef:addingports} 188 189 144 The 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 Fig $\ref{fig:oef:addport}$. Next, the user enters ``amp\_output'' for the port name and selects. As defined by the SCA, a uses port is an output port while a provides port is an input port. Since this port will be an output port, the user selects uses from the 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 amp\_input that is also a complexShort, so the user adds another port using the same process 190 145 … … 201 156 \subsection{Adding Properties to a Component} 202 157 \label{sdrapplicationdevelopment-oef:addingproperties} 203 204 158 The final step to configure a component is to add any reconfigurable properties it will need. Our amplifier needs two properties: I\_gain and 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 CE to bring up the Add Property dialog as shown in Fig. $\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 Q\_gain property. 205 159 … … 218 172 219 173 At 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 make commands and show the output in the console view. After generation is complete, the new files will appear in the project explorer, as seen in Fig. $\ref{fig:oef:generatedproject}$. 220 221 174 222 175 %-------------------- FIGURE: EDITING CODE IN OEF -------------------- 223 176 \begin{figure*} … … 230 183 \end{figure*} 231 184 232 233 185 \subsection{Filling in Implementation Code} 234 186 \label{sdrapplicationdevelopment-oef:implementation} 235 236 187 Once the component has been generated, the user has to fill in the skeleton with implementation code. The user double-clicks on amplifierIQ.cpp in the Project Explorer to open the file in a C++ editor as shown in Fig $\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, he saves the file. As long as there are no errors, OEF automatically builds and installs the component to the filesystem. 237 188 … … 285 236 \subsection{Install a new waveform application} 286 237 \label{sdrapplicationdevelopment-wavedash:installingwaveformapplication} 287 288 238 The 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. 289 239 … … 300 250 \subsection{Show/Hide Components} 301 251 \label{sdrapplicationdevelopment-wavedash:showhidecomponents} 302 303 The Component menu lists the components present in the waveform application denoted by the active tab. The user deselects the component RxDemo from the Component menu (Fig. $\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. 252 The Component menu lists the components present in the waveform application denoted by the active tab. The user deselects the component RxDemo from the Component menu (Fig. $\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. 304 253 305 254 \subsection{Configure Component Properties of a Waveform} 306 255 \label{sdrapplicationdevelopment-wavedash:configurecomponentproperties} 307 308 256 The 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 and restart the waveform to configure the component property values. 309 257 … … 322 270 \end{figure} 323 271 324 325 326 272 %-------------------- FIGURE: WAVEDASH - CHANGE PROPERTY CONTROL WIDGETS -------------------- 327 273 \begin{figure} … … 336 282 \subsection{Change Property Configuration Control Widgets} 337 283 \label{sdrapplicationdevelopment-wavedash:configurewidgets} 338 339 The component PRF files determine the data type for each property of the component. WaveDash does a default mapping of data type (mentioned in PRF files) to a GUI widget (control) and also provides an optional list of widgets which users can customize to their preferences. In this example, packet\_delay\_ms of TxDemo is mapped to a spin box by default. User right clicks on the spin box that brings a context menu with the list of optional widgets configurable for packet\_delay. The user selects slider (Fig $\ref{fig:wavedash:changepropertywidgets}$) and that changes the widget on the application GUI also. The configure option in the context menu is used to set minimum and maximum values for spin box and slider controls. 284 The component PRF files determine the data type for each property of the component. WaveDash does a default mapping of data type (mentioned in PRF files) to a GUI widget (control) and also provides an optional list of widgets which users can customize to their preferences. In this example, packet\_delay\_ms of TxDemo is mapped to a spin box by default. User right clicks on the spin box that brings a context menu with the list of optional widgets configurable for packet\_delay. The user selects slider (Fig $\ref{fig:wavedash:changepropertywidgets}$) and that changes the widget on the application GUI also. The configure option in the context menu is used to set minimum and maximum values for spin box and slider controls. 340 285 341 286 %-------------------- FIGURE: WAVEDASH - SELECT/DESELECT COMPONENT PROPERTIES -------------------- … … 351 296 \subsection{Show/Hide Component Properties} 352 297 \label{sdrapplicationdevelopment-wavedash:showhidecomponentproperties} 353 354 It is highly 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 the frequently used properties on screen. In this example (Fig $\ref{fig:wavedash:selectdeselectproperties}$), the user right clicks on a component and deselects phase\_offset from the pop-up menu. 298 It is highly 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 the frequently used properties on screen. In this example (Fig $\ref{fig:wavedash:selectdeselectproperties}$), the user right clicks on a component and deselects phase\_offset from the pop-up menu. 355 299 356 300 %-------------------- FIGURE: ALF - BLOCK DIAGRAM WITH PLUG-IN MENU -------------------- … … 366 310 \section{SDR Application Development Work Flow Part III: Use of ALF Waveform Application Visualization and Debugging Environment} 367 311 \label{sdrapplicationdevelopment-alf} 368 369 312 The ALF environment provides several capabilities that are helpful for troubleshooting and debugging waveform applications. Like WaveDash, ALF allows users to install/uninstall and start/stop waveform applications. ALF also lets users display running applications in block diagram form as shown in Fig. $\ref{fig:alf:block_diagram_plugin_menu}$, and inject and monitor signals at various component ports in the application 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 shwon in Fig. $\ref{fig:alf:block_diagram_plugin_menu}$. Additional features enable creation and installation of single-component waveform applications, and connections between ports on components in the same or different waveforms at run time. 370 313 371 314 \subsection {ALF Plug-In Tools} 372 315 \label{sdrapplicationdevelopment-alf:plugins} 373 374 316 Several plug-in tools for ALF are provided as part of the OSSIE distribution. These tools are used to inject signals into component provides ports, and to display, record, or otherwise process the signals coming out of component uses ports. The plugins are implemented in Python, and users can modify the plug-ins or develop their own based on those provided. 375 317 … … 386 328 \subsubsection{Speaker Tool} 387 329 \label{sdrapplicationdevelopment-alf:plugins:soundtool} 388 389 330 The speaker tool, shown in Fig. $\ref{fig:alf:plugins:speaker}$, accepts signals in OSSIE's 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. 390 331 … … 401 342 \subsubsection{Plot Tool} 402 343 \label{sdrapplicationdevelopment-alf:plugins:plottool} 403 404 344 The plot tool (Fig. $\ref{fig:alf:plugins:plot}$) also accepts signals from uses ports that employ the complexShort interface. 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 under ideal conditions would typically map to regularly spaced points, 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 anomolies. 405 406 345 407 346 %-------------------- FIGURE: ALF - AWG TOOL -------------------- … … 417 356 \subsubsection{Arbitrary Waveform Generator (AWG) Tool} 418 357 \label{sdrapplicationdevelopment-alf:plugins:AWGtool} 419 420 358 Using this tool, shown in Fig. $\ref{fig:alf:plugins:awg}$, users can select from among available signal functions, or read signals that are stored in data files. This allows generation of signals off-line using software such as MATLAB or replaying signals that are captured over the air. 421 359 422 360 \subsection{Launching Individual Components as Waveform Applications} 423 361 \label{sdrapplicationdevelopment-alf:compform} 424 425 362 ALF 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 (see Fig. $\ref{fig:alf:block_diagram_plugin_menu}$). 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. 426 363 … … 437 374 \subsection{Connect Tool} 438 375 \label{sdrapplicationdevelopment-alf:connecttool} 439 440 376 The Connect Tool, shown in Fig. \ref{fig:alf:connect}, provides the capability 441 377 to 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 configuring properties of its constituent applications using the WaveDash tool. 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}. … … 453 389 \subsection{Relation of ALF with WaveDash} 454 390 \label{sdrapplicationdevelopment-alf:relationwithwavedash} 455 456 391 When 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 Fig. $\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 and start/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 python module or library. 457 392 … … 462 397 \section{Future Work} 463 398 \label{futurework} 464 465 399 The current state of the tools allows for the work flow shown in the preceding sections, and also allows applications such as 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. 466 400 … … 483 417 \section{Conclusion} 484 418 \label{conclusion} 485 486 419 This paper has described a set of open source SCA-based SDR development tools suitable for education, research, and rapid prototyping. These tools hide some of the complexity of the SCA while exploiting the features provided by the SCA to enable an interactive development process. The development process includes creation of signal processing comoponents and waveform applications as well as execution, visualization, monitoring, testing, and run time reconfiguration of waveform applications. 487 420 488 421 \section{Acknowledgements} 489 422 \label{acknowledgements} 490 491 423 This work was supported by the National Science Foundation under Grant No. 0520418, by Science Applications International Corporation, and by U.S. ARMY CERDEC. 424 492 425 \begin{thebibliography}{00} 493 426 … … 515 448 516 449 \bibitem{Vanu} 517 Vanu $^{\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.pdf450 Vanu{\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 518 451 519 452 \bibitem{JTRS}