Waveform Development using Software Defined Radio

Full text

(1)Examensarbete LITH-ITN-ED-EX--06/005--SE. Waveform Development using Software Defined Radio Thomas Sundquist 2006-04-25. Department of Science and Technology Linköpings Universitet SE-601 74 Norrköping, Sweden. Institutionen för teknik och naturvetenskap Linköpings Universitet 601 74 Norrköping.

(2) LITH-ITN-ED-EX--06/005--SE. Waveform Development using Software Defined Radio Examensarbete utfört i Elektronikdesign vid Linköpings Tekniska Högskola, Campus Norrköping. Thomas Sundquist Handledare Annica Söderlund Examinator Ole Pedersen Norrköping 2006-04-25.

(3) Datum Date. Avdelning, Institution Division, Department Institutionen för teknik och naturvetenskap. 2006-04-25. Department of Science and Technology. Språk Language. Rapporttyp Report category. Svenska/Swedish x Engelska/English. Examensarbete B-uppsats C-uppsats x D-uppsats. ISBN _____________________________________________________ ISRN LITH-ITN-ED-EX--06/005--SE _________________________________________________________________ Serietitel och serienummer ISSN Title of series, numbering ___________________________________. _ ________________ _ ________________. URL för elektronisk version. Titel Title. Waveform Development using Software Defined Radio. Författare Author. Thomas Sundquist. Sammanfattning Abstract Software. Defined Radio (SDR) is a conception of implementing radio functions in computer software, instead of having electronics performing the functions. This thesis aims to compare two different ways of implementing these functions, or waveforms. The Software Communications Architecture (SCA) is an open standard developed by the United States Department of Defense. It uses a CORBA interface environment to make waveform applications interoperable and platform independent. This method of developing SDR is compared to an open-source initiative going by the name GNU Radio. Two waveform applications are developed, one transmitter using SCA, and one receiver using GNU Radio. The analog radio interface is simulated using the sound cards of two regular PCs. The development is done using the C++ and Python programming languages. This thesis examines pros and cons of the two SDR methods, as well as performing studies of Software Defined Radio in general.. Nyckelord Keyword. SDR, SCA, GNU Radio, CORBA, IDL, XML.

(4) Upphovsrätt Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/ Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/. © Thomas Sundquist.

(5) i. Abstract Software Defined Radio (SDR) is a conception of implementing radio functions in computer software, instead of having electronics performing the functions. This thesis aims to compare two different ways of implementing these functions, or waveforms. The Software Communications Architecture (SCA) is an open standard developed by the United States Department of Defense. It uses a CORBA interface environment to make waveform applications interoperable and platform independent. This method of developing SDR is compared to an open-source initiative going by the name GNU Radio. Two waveform applications are developed, one transmitter using SCA, and one receiver using GNU Radio. The analog radio interface is simulated using the sound cards of two regular PCs. The development is done using the C++ and Python programming languages. This thesis examines pros and cons of the two SDR methods, as well as performing studies of Software Defined Radio in general. Keywords: SDR, SCA, GNU Radio, CORBA, IDL, XML.

(6) ii.

(7) iii. Preface This is a masters thesis on Waveform Development using Software Defined Radio written by Thomas Sundquist and Mansour Fanni. The thesis and development work were performed during the summer and autumn of 2005 at Ericsson Microwave Systems in Gothenburg, Sweden.. Thesis outline This thesis is split into 7 chapters: Chapter 1 is an introduction to the thesis. Chapter 2 deals with Software Defined Radio (SDR) in general. Chapter 3 is all about CORBA. Chapter 4 examines the SCA on a deeper level. Chapter 5 looks into GNU Radio. Chapter 6 introduces the MATH waveform. Chapter 7 reflects our conclusions. There are also several appendixes. Besides the complete source code to our applications, there is an installation guide and a document that deals with platform-specific problems that occurred during our development time. The latter might come in handy when trying to compile and use our applications.. Acknowledgement This thesis wouldn’t have made it this far without the support of several people to whom we would like to offer our thanks. Our supervisors at Ericsson Microwave Systems, Annica S¨oderlund, Daniel Guldbrand and H˚akan Berggren, for helping us and guiding us through the thesis work. Ole Pedersen, our examiner at Link¨oping University, who has read and criticized our report and given us useful tips and pointers. And last but definitely not least, we would like to thank our families and friends, who have supported us in many ways throughout the project..

(8) iv.

(9) v. Contents Abstract. i. Preface and Acknowledgement. iii. 1. Introduction 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1 1 1 1. 2. Software Defined Radio 2.1 Introduction . . . . . . . . . . . . . . . 2.1.1 Waveforms . . . . . . . . . . . 2.1.2 Software Defined Radio . . . . 2.2 GNU Radio . . . . . . . . . . . . . . . 2.3 Software Communications Architecture. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 3 3 3 3 4 5. CORBA 3.1 CORBA in general . . . . . . . 3.1.1 IDL . . . . . . . . . . . 3.1.2 Portable Object Adapter 3.1.3 Naming Service . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 7 7 7 9 9. . . . . . . . . . . . . . .. 11 11 12 12 13 14 14 14 14 15 15 17 18 18 18. 3. 4. . . . .. . . . .. . . . .. . . . .. Software Communications Architecture 4.1 Introduction and abstract . . . . . . . . . . . . 4.2 Core Framework . . . . . . . . . . . . . . . . 4.2.1 Base Application Interfaces . . . . . . 4.2.2 Framework Control Interfaces . . . . . 4.2.2.1 DomainManager . . . . . . . 4.2.2.2 Application . . . . . . . . . 4.2.2.3 ApplicationFactory . . . . . 4.2.2.4 Devices and DeviceManager 4.3 eXtensible Markup Language . . . . . . . . . . 4.4 Domain Profile . . . . . . . . . . . . . . . . . 4.5 SCA and CORBA . . . . . . . . . . . . . . . . 4.6 SCA waveform development . . . . . . . . . . 4.6.1 Development tools . . . . . . . . . . . 4.6.2 The API of SCA . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . ..

(10) vi. 5. 6. 7. GNU Radio 5.1 Overview . . . . . . . . . . . . . . 5.2 SDR Construction using GNU Radio 5.3 Creating your own building block . 5.3.1 SWIG . . . . . . . . . . . . 5.3.2 Boost . . . . . . . . . . . . 5.3.3 Naming Conventions . . . . 5.3.4 Much more to know . . . . 5.3.5 The C++ Class . . . . . . . 5.4 A simple example . . . . . . . . . .. . . . . . . . . .. Implementation of the MATH Waveform 6.1 Introduction . . . . . . . . . . . . . . 6.2 SCA implementation . . . . . . . . . 6.2.1 The beginning steps . . . . . 6.2.2 The MATH implementation . 6.2.3 Functionality . . . . . . . . . 6.2.4 Signaling system . . . . . . . 6.3 GNU Radio implementation . . . . . 6.3.1 First attempt . . . . . . . . . 6.3.2 Two signal-flow-graphs . . . . 6.3.3 The actual implementation . . 6.3.3.1 The C++ code . . . 6.3.3.2 The Python code . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. Conclusions 7.1 Developing waveforms using SCA . . . . 7.1.1 Benefits and advantages . . . . . 7.1.2 Disadvantages of SCA . . . . . . 7.1.3 Conclusions about the SCA . . . 7.2 Developing waveforms using GNU Radio 7.2.1 Advantages of GNU Radio . . . . 7.2.2 Disadvantages and drawbacks . . 7.3 Comparison of the two methods . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . .. 21 21 21 22 22 22 22 23 23 24. . . . . . . . . . . . .. 27 27 28 28 29 30 31 32 32 33 33 34 34. . . . . . . . .. 35 35 35 36 37 37 37 38 39. References. 41. Index. 43. Appendixes A Platform-related issues. 47. B Installation Guide. 51. C MATH GNU Radio Python application. 53. D MATH SCA application. 59.

(11) 1. Chapter 1 Introduction 1.1. Background. The possibility to change waveform in a radio by using software or the ability to use the same software in different platforms have lately become more and more interesting. This technique is called Software Defined Radio. In response to this interest a standardized architecture for creating software waveforms has been developed in the United States by the Department of Defense. This architecture is known as the Software Communications Architecture. There are other methods of developing software waveform applications. One of them is GNU Radio, which is an open-source initiative.. 1.2. Objectives. The purpose of this master thesis is to compare waveform development using SCA versus development using GNU Radio. The comparison will use the sound cards of two regular PCs to simulate the radio interface. Pros and cons of these two ways of deploying waveforms will be studied, and general issues regarding waveform developing in software is to be examined. The thesis includes studies in CORBA, XML, C++ and Python.. 1.3. Methods. Before starting to develop a waveform using SCA or GNU Radio, a lot of studying has to be done. Studies of the SCA specification and Developer’s Guide are needed to learn more about SCA and how to use it for waveform development. The understanding of CORBA is essential for understanding how SCA waveforms are developed and how the SCA Core Framework works, thus a big portion of time is dedicated to studies of CORBA. XML is used to some extent in SCA development, so XML have to be learned. Besides touching up on C++ for the actual development work in both SCA and GNU Radio, GNU Radio uses the powerful scripting language Python which also needs a portion of time to learn and comprehend. Then the actual implementation can be started. The project aims to create an SDR transmitter and receiver using SCA and GNU Radio, and then transmit some sort of signal across two regular PC sound cards..

(12) 2.

(13) 3. Chapter 2 Software Defined Radio This chapter is an introduction to Software Defined Radio (SDR) in general. In section 2.3 and 2.2 two different ways to implement SDR are introduced.. 2.1. Introduction. The “normal” way of implementing waveforms and radio functions is having hardware-based systems do all the work. Generation, modulation/demodulation, filter functions, up/downconversion of frequencies, everything is done with electronics in some way. Therefore, there are some limitations to what a specific machine can do. For example, your normal FM-radio in your kitchen knows how to do exactly one thing, convert FM radio waves into sound you can listen to. Now imagine a radio technology that can turn your kitchen radio into a GSM telephone, or a GPS receiver, or maybe a satellite communications terminal. Or why not a garage door opener? That’s exactly the opportunities that emerge with software radios!. 2.1.1 Waveforms There are a lot of references to the word waveform in this thesis, so we’ll start by explaining what we mean when we talk about waveforms. A waveform can be described as a radio function, everything that is used to describe a specific radio signal is included in the waveform conception. Generation, modulation, filtration etc, all the different components of a radio function are put together and form the conception waveform. For instance, WCDMA (Wideband Code-Division Multiple-Access) is one of the main technologies for the implementation of third-generation (3G) cellular systems. This is an example of a waveform. GSM or FM would be other examples of waveforms. Hence, we do not only talk about the actual electromagnetic waves when we refer to a waveform, as one might think when first encountering the word.. 2.1.2 Software Defined Radio This radio technology is called Software Defined Radio (SDR), where almost all radio functions are moved out of hardware electronic circuits into software. The idea is to get the soft-.

(14) 4. Chapter 2. Software Defined Radio. ware source code as close to the antenna as possible. Waveforms are generated, encoded, modulated, filtered and processed in computer software. So what’s so great about this? At a first glance it might not seem very exciting, but there are a lot of benefits in the world of software radio. • The ability to change waveform and function on-the-fly. One general-purpose device can be configured into whatever kind of radio you are in need of at the moment. GPS receiver one minute, cordless phone the next. Only the imagination sets the limits. • Quick and easy upgrading with new and enhanced features. Upgrading the software can be done over the air. • Cost-effective solutions. When new waveforms are required in a system, there is no need to purchase new hardware equipment, just upload the new software remote and you have a fully functional system with completely new features. • Receive and broadcast multiple channels at the same time. • Portability. An open standard architecture makes it possible for different kinds of communicators to talk to each other. It’s not uncommon today that different types of government organizations such as police and fire departments from different areas can’t communicate with each other due to the fact that they are using different types of radio systems. With SDR the communication devices can reconfigure themselves and thus “learn another language”. The basic idea of SDR is shown in Figure 2.1. If we look at the receiving part, there is an antenna, an RF front end, an analog-to-digital converter, and then the actual software code. The analog-to-digital converter (ADC) is the link between the analog world of continuous signals and the digital world where the signals are discrete. The radio signal is usually broad-casted in high frequencies, several hundred or thousands of MHz, so the job for the RF front end is to translate the signal down to a lower frequency that the ADC is able to handle. After the signal is digitized, it’s all up to the software to do the actual work.. 2.2. GNU Radio. GNU Radio 1 is a free open-source collection of software, that combined with minimal hardware can be used to receive and transmit waveforms. GNU Radio comes with a huge collection of ready-to-use filters, modulators, demodulators, signal sources and other tools that can be used when constructing and/or receiving signals and waveforms. GNU Radio also comes with software tools such as a spectrum analyzer and an oscilloscope. And since it’s a truly free software, if there’s something missing in this vast collection of tools, anyone can develop new functions and modules. More of how this is done is described in chapter 5. An article [12] published in Linux Journal magazine describes the GNU Radio project more in detail. 1. http://www.gnu.org/projects/gnuradio/.

(15) 2.3. Software Communications Architecture. 5. Antenna. RF Front End. AD Converter. Software. Receiving software radio. Antenna. RF Front End. DA Converter. Software. Transmitting software radio. Figure 2.1 Basics of SDR Several projects have been developed using GNU Radio including a complete HDTV receiver and broadcaster and a multichannel FM receiver capable of listening to several channels at the same time. The latter is an example of the strength of software radio.. 2.3. Software Communications Architecture. In 1997 the United States Department of Defense (DoD) initiated the Joint Tactical Radio System (JTRS) program, as a way to try and solve the issue of a programmable, modular, multi-band, multi-mode radio, that would eventually replace over 200 different radio types within the DoD. In late 1998, the first step towards the Software Communications Architecture (SCA) was taken. The SCA is a non-proprietary, open architecture framework, to help promote the development of interoperable software and hardware. The SCA is not a system specification, as it is intended to be implementation independent, but rather a set of design constraints. If a developer designs a system according to the these design rules, his system will be portable with other SCA implementations regardless of what operating system or hardware that implementation is based on. The software structure of the SCA is called the Operating Environment, and consists of the following components: - a Core Framework, this is the collection of interfaces and services that provide an abstraction of the underlying layers for software application designers. The interfaces are described using CORBA IDL, which is described in chapter 3, section 3.1.1..

(16) 6. Chapter 2. Software Defined Radio. - a CORBA middleware that is used for all communications within the waveform. A middleware can be described as the “glue” between software components or between software and the network. - a POSIX-compliable operating system. We have used the GNU/Linux operating system during our work.. Figure 2.2 SCA Software Structure Figure 2.2 shows the relations between the operating environment and the waveform. The application layer at the very top is where the actual SDR components are, i.e. the “waveform” layer. Beneath is the operating environment: the operating system with underlying hardware buses at the bottom layer and the Core Framework and the CORBA middleware on top of that. The CORBA middleware and Core Framework are described more in detail in chapters 3 and 4. Especially, understanding how CORBA and the SCA waveform connect to each other and what an SCA waveform really is, can be read about in chapter 4, section 4.5..

(17) 7. Chapter 3 CORBA Since CORBA is such an important component in the SCA, this chapter explains the essence of CORBA and what is to be understood before reading chapter 4.. 3.1. CORBA in general. CORBA is an acronym for Common Object Request Broker Architecture, and is a standard for producing client/server middleware in a distributed environment. The CORBA standard is created and controlled by the Object Management Group (OMG). The CORBA mechanism allows programs to be running on different machines and written in different programming languages while safely (and portably) exchanging data and the CORBA mechanism is ideal for classic client/server applications. The ORB (Object Request Broker) is the piece of software running on a machine that handles all server/client requests. The protocol used by CORBA to communicate is the General Inter-ORB Protocol (GIOP). The GIOP maps ORB requests to different network transports, and one such implementation is the Internet Inter-ORB Protocol, IIOP. An important issue for object interoperability is how ORBs address, or locate, objects. An object reference can be thought of as a trustworthy name that always symbolizes a specific object. These references are standardized for all ORBs. Thus, any ORB can invoke operations and calls to objects located with other ORBs. The way CORBA handles this is by the Interoperable Object Reference (IOR), which is a sequence of characters that specifies a single CORBA object wherever in the world it is located.. 3.1.1 IDL CORBA uses OMG’s Interface Definition Language (IDL) to specify the interfaces that objects will present to the world. CORBA then specifies a ”mapping” from IDL to a specific implementation language like C++ or Java. Any client that wants to invoke an operation on a CORBA server object, must use the object’s IDL interface to specify which operation it wants to perform. IDL is not a programming language - it’s great for defining interfaces, but it doesn’t have the constructs you’d need to write a program. The IDL interface defines the contract between.

(18) 8. Chapter 3. CORBA. the client and server parts of your application, specifying what operations and attributes are available. The programmer then uses an IDL compiler to generate application code, skeletons for the server part, and stubs for the client part. The stubs and skeletons run on top of an Object Request Broker (ORB), and they work as proxies for servers and clients, respectively. This way, the client and server can be written in different languages and/or be running on different platforms and be able to communicate with each other in a safe, scalable manner [5]. Every CORBA server object has a unique object reference, and there are several ways of which the client can get a hold of this reference. Once obtained, the client can invoke operations on the server object. The invocation is really invoked on the client stub, which uses the ORB to forward the request to the servant object, through the server skeleton. Figure 3.1 shows a model of this.. Figure 3.1 Client-server model in CORBA using stubs and skeletons. The ORB block contains the necessary means to pass over the request from client to server. Usually the client and server are not connected to the same ORB, and the GIOP/IIOP protocol is used to forward the request. A modification showing this is pictured in figure 3.2. This is all transparent from the client and server view. All the client needs is the reference to the servant, and then the ORBs handle the technical stuff such as load balancing, resource control and error handling of the requests.. Figure 3.2 The inter-ORB communication using GIOP/IIOP..

(19) 3.1. CORBA in general. 9. A simple example of IDL is shown below. The interface Modulator has one operation called ModulateData which takes one input argument and returns nothing (void), and has one attribute called ModulatorStatus. It also inherits the Resource and Port interfaces from the Core Framework. interface Modulator : CF::Resource, CF::Port { void ModulateData(in double incoming_data); attribute int ModulatorStatus; }. There are a lot of ORB implementations, for this masters thesis we have used the TAO ORB [11] which has real time capabilities. TAO is a real-time ORB based on the SunSoft IIOP protocol engine. TAO is targeted for applications with deterministic and statistical Quality of Service (QoS) requirements, as well as best effort requirements.. 3.1.2 Portable Object Adapter The Portable Object Adapter (POA) is a way of making implementation objects available to the ORB for servicing requests. All CORBA calls on a CORBA object goes through the POA. The POA maps a CORBA object ID to the actual implementation object. Upon a server object initialization, it registers itself with the POA. This can be seen in our source code in appendix D.. 3.1.3 Naming Service The OMG Naming Service [7] is one of CORBA’s standardized services. The Naming Service provides the principal mechanism through which most clients of an ORB-based system locate objects that they intend to use. The basic function of the naming service is the association of names with object references. A server object creates associations between a name and its object reference, and registers this information in the Naming Service. Then a client that knows the name of an object can retrieve its object reference by querying the Naming Service. This can also be seen in our source code..

(20) 10.

(21) 11. Chapter 4 Software Communications Architecture This chapter features a more detailed description of the SCA environment, the Core Framework and the waveform components, with emphasis on the components that we have used for this thesis. The Domain Profile is described, and the chapter ends with an introduction on how to develop a waveform application.. 4.1. Introduction and abstract. SCA is designed to be an open, standardized architecture providing interoperability, easy insertion of new technology, quick upgrade capability, software reuse and scalability. When designing the structure of an SCA compliant system, all these factors should be kept in mind. An SCA waveform or Application consists of one or more software Resources and/or hardware Devices. A Device is a type of Resource used by applications as software proxies for actual hardware devices. The Application is created in an ApplicationFactory, usually by the DomainManager. Every component in an SCA compliant waveform inherits from the Core Framework interfaces. These interfaces are described in CORBA IDL language, and then compiled into the programming language of your choice. The Domain Profile is a set of XML files to describe the characteristics of the system, the different interfaces that it is composed of and their functional capabilities and inter-dependencies. The Domain Profile is managed by the DomainManager. Legacy software components that don’t have CORBA support can be incorporated in an SCA system by the use of CORBA adapters, which are proxies to wrap the functionality of the component in the CORBA environment. Figure 4.1 shows the relationship between the waveform or Application and the Operating Environment which consists of the CF, the CORBA middleware, and the operating system. Although the SCA uses the CORBA middleware for its software bus, the application layer can reach the OS by other means. However, waveform access to the OS is highly restricted. In section 4.6 the SCA is described from the application developers point of view..

(22) 12. Chapter 4. Software Communications Architecture. Figure 4.1 Relationship between SCA structures. 4.2. Core Framework. As mentioned in chapter 2, section 2.3, the Core Framework (CF) is one of the key components in an SCA system. The CF consists of: • Base Application Interfaces (Port, LifeCycle, TestableObject, PropertySet, PortSupplier, ResourceFactory and Resource) that can be used by all software applications. • Framework Control Interfaces (Application, ApplicationFactory, DomainManager, Device, LoadableDevice, ExecutableDevice, AggregateDevice and DeviceManager) that provide control of the system. • Framework Services Interfaces (File, FileSystem, FileManager and Timer) that support both core and non-core applications. • A Domain Profile that describes the properties of hardware devices (Device Profile) and software components (Software Profile) in the system.. 4.2.1 Base Application Interfaces The Base Application Interfaces are the building blocks used to create an SCA waveform. These interfaces are Port, LifeCycle, TestableObject, PortSupplier, PropertySet, Resource and ResourceFactory..

(23) 4.2. Core Framework. 13. An SCA system is made by several components, these different parts communicate with each other through ports. The Port interface provides two operations to set up communications, connectPort() and disconnectPort(). Components that provide ports inherits from the PortSupplier interface which defines the getPort() operation. This is used to obtain a specific port from a component. The LifeCycle interfaces defines two operations, initialize() and releaseObject(). initialize() is used to set a component to a known initial state, and releaseObject() tears a component down when it’s not to be used any more. TestableObject is inherited by a component to run built-in tests. The system designer can use the runTest() operation to test the component, for example to search for errors within the component. The PropertySet interface is used to access component properties/attributes. It defines two operations: configure(), which makes runtime configuration possible, and query(), to allow a component to be queried of its properties. Every software component in an SCA waveform shall inherit the Resource interface. This in turn inherits from LifeCycle, TestableObject, PortSupplier and PropertySet. Two operations are also provided, start() and stop(), to be able to start and stop the component. A Resource can be created by a ResourceFactory, and if it is, the same ResourceFactory shall be used to tear down the Resource. The ExecutableDevice interface can be used as an alternative way to create a Resource. Figure 4.2 shows the Resource interface and its inheritances depicted in the Unified Modeling Language (UML). For more information on UML see [15]. LifeCycle. PropertySet. initialize() releaseObject(). configure() query(). PortSupplier getPort(). TestableObject runTest(). Resource identifier:string start() stop(). Figure 4.2 Resource Interface UML Diagram. 4.2.2 Framework Control Interfaces The Framework Control Interfaces consist of DomainManager, ApplicationFactory, Application, Device, LoadableDevice, ExecutableDevice, AggregateDevice and DeviceManager. These interfaces can be grouped as Domain Management Interfaces and Device Management Interfaces. Domain Management Interfaces are DomainManager, ApplicationFactory and Application. These three interfaces are coupled together and must always be delivered as.

(24) 14. Chapter 4. Software Communications Architecture. a complete domain management implementation. They manage registration/deregistration of applications and devices within the domain, and also controlling of applications. The Device Management Interfaces are Device, LoadableDevice, ExecutableDevice, AggregateDevice and DeviceManager. The DeviceManager creates and controls the Device interfaces, which act as proxies for actual hardware devices in the SCA environment. 4.2.2.1. DomainManager. The DomainManager manages a set of available hardware devices and applications. It is responsible for the set-up and shut-down of Applications, Devices, Services and DeviceManagers. External applications such as a user interface can obtain a list of the Applications, Services and Devices through the DomainManager. Built-in-tests are also managed by the DomainManager. These operations increase the scalability of an SCA system by allowing runtime insertion and extraction of components. 4.2.2.2. Application. Waveforms are defined as Applications in an SCA system. The Application interface provides the Domain Management interface for the control and configuration of an instantiated application in the domain. A created application instance contains Resource components and may also contain non-CORBA components. The Application inherits the Resource interface, and delegates it’s Resource operations to the Application’s Assembly Controller. 4.2.2.3. ApplicationFactory. The ApplicationFactory interface provides the Domain Management interface to request the creation of a specific type of Application in the domain. The type of Application created and its components is determined by the Software Assembly Descriptor file, which is described in section 4.4. Each Application has an ApplicationFactory of its own. 4.2.2.4. Devices and DeviceManager. Actual hardware devices are represented as Devices in an SCA system. The Device interface inherits the Resource interface and adds additional capacity and state operations. LoadableDevice adds the capability to load and unload files on a particular device. The ExecutableDevice extends the LoadableDevice with the capability to execute and terminate processes on a device. If the designer wants to create and run a Resource on a Device, this is the way go to. Finally, AggregateDevice can be looked upon as a collection of Devices, with operations to add and remove a device from the collection. The DeviceManager is responsible for controlling and managing Devices and services, and it has operations for registering and unregistering. It is not a factory, so it cannot initiate new Devices. There can exist several DeviceManagers at once, each controlling a number of Devices. Upon creation of the DeviceManager several things happen. The DeviceManager use the Device Configuration Descriptor file to discover the services to be deployed and Devices to be.

(25) 4.3. eXtensible Markup Language. 15. created for this DeviceManager. Then, it creates a FileSystem and mounts it to the DomainManager’s FileManager. Finally, the DeviceManager registers itself with the DomainManager. Figure 4.3 shows the sequence diagram for this scenario. Boot Up. : DeviceManager 1: create. : XML Parser. : Device. : DomainManager. 2: create FileSystem. 3: Parse DCD and SPD files. 4: launch Device. 5: registerDevice(in Device). 6: initialize(). 7: configure(in properties). launch, registerDevice, initialize and configure are performed for each Device in the system.. 8: registerDeviceManager(in DeviceManager). Figure 4.3 Sequence Diagram for DeviceManager Startup. 4.3. eXtensible Markup Language. Properties, capabilities, dependencies and assembly of an SCA system is made with the eXtensible Markup Language (XML). XML was developed by an XML Working Group formed under the oversight of the World Wide Web Consortium (W3C) in 1996. XML is a subset of SGML, the Standard Generalized Markup Language. XML can be used to describe data components, records and other data structures - even complex data structures. XML is a markup language much like HTML. It is extensible because it is not a fixed format like HTML (which is a single, predefined markup language). Instead, XML is actually a metalanguage, a language for describing other languages which lets you design your own markup languages for limitless different types of documents. To describe a language in XML, a Document Type Definition (DTD) is used. The DTD specifies what kind of data and attributes a document consists of, and is referenced at the top of an XML document. [16]. 4.4. Domain Profile. The SCA specification requires portable software components to provide common information called a Domain Profile. The domain management functions use the component deployment information expressed in this Domain Profile. The information is used to start, initialize, and maintain the applications that are installed into the SCA-compliant system..

(26) 16. Chapter 4. Software Communications Architecture. The Domain Profile consists of a set of XML files. These files describe the components that make up an SCA system, their identity, capabilities, properties and inter-dependencies of each other. All of the descriptive data about a system is expressed in the XML vocabulary. Figure 4.4 portrays the relationships between the different parts of the Domain Profile in SCA. Green Red. Domain Profile. 0..n. 0..n <<DTDElement>>. <<DTDElement>>. Device Configuration Descriptor. Software Assembly Descriptor 1. DomainManager Configuration Descriptor. 1. 1. 1. <<DTDElement>>. Profile Descriptor 1..n. 1. 1..n. <<DTDElement>>. <<DTDElement>>. Software Package Descriptor 1. 0..n. 0..n <<DTDElement>>. 0..n. Device Package Descriptor. <<DTDElement>>. Properties Descriptor 0..n. Profile Descriptor. 0..1 <<DTDElement>>. Software Component Descriptor. Figure 4.4 Domain Profile Descriptor. Software Package Descriptor The Software Package Descriptor (SPD) is an element of the Domain Profile that identifies one or more software component implementations. General information about a software package, such as the name, author, property file, implementation code information and hardware and/or software dependencies are contained in a Software Package Descriptor file. An SPD is associated with one or more Software Component Descriptors.. Properties Descriptor Basically the Properties Descriptor File is the initial configuration file which contains the detailed settings for a component, and/or attributes for a device. These settings will be used by a CF Resource component’s configure()(), query()(), and runTest() operations. The reference to a component’s Properties Descriptor is obtained from the SPD file.. Software Component Descriptor The Software Component Descriptor (SCD) is an element of the Domain Profile that contains information about a specific SCA software component (CF Resource, CF ResourceFactory, CF Device). The SPD can contain several references to one or more Software Component Descriptors. For instance, there can be more than one implementation of a certain component. They can each be described in their own SCD, and then referenced with different IDs in the SPD..

(27) 4.5. SCA and CORBA. 17. Software Assembly Descriptor The Software Assembly Descriptor (SAD) is the element of the Domain Profile that contains information about the components that make up an application. The SAD describes how the different components of an Application are deployed and interconnected, and is associated with one or more Software Package Descriptor files.. Device Configuration Descriptor The Device Configuration Descriptor provides the means of describing the hardware components (Devices) within an application and the characteristics of a CF DeviceManager. It also contains information on how to obtain the DomainManager object reference.. Domain Configuration Descriptor Finally, the Domain Configuration Descriptor is the file which describes the DomainManager. It contains references to the DomainManagers SPD file, which in turn can be used to describe the CF DomainManager implementation and to specify the uses ports for the domain’s services, for example the the DomainManager’s Log service.. 4.5. SCA and CORBA. The Core Framework interfaces are expressed in CORBA IDL [9]. When implementing a waveform, all components which constitute the waveform are also described in CORBA IDL. As written in chapter 3, section 3.1.1, IDL is a language that defines interfaces. So basically, an SCA waveform is a bunch of interfaces. When compiling the CORBA IDL, server skeletons and client stubs are created. This means, on a deeper level, that all the waveform components such as Resources and Devices are actually CORBA servants and/or clients! The “and/or” has to be emphasized. A component can be (usually is) both server and client at the same time. It can be illustrated with an example. Take some components, A, B and C. A has an interface that B is connected to. B uses the interface provided by A. This makes A a CORBA servant and B the CORBA client that connects to the servant. On the other hand, C has an interface A is connected to. In this case, C is the server and A the client. Thus, A is both server and client at the same time. The various components of the waveform uses the CF Port interface (remember this is also a CORBA IDL interface) to make connections with each other. The terms uses port and provides port are commonly used in SCA development. A uses port requests data or service from another component, while a provides port returns requested data or performs a requested service. Under this model, software assumes the role of a CORBA client when it is calling through a uses port, and the role of a CORBA servant when it is answering at a provides port [13]..

(28) 18. Chapter 4. Software Communications Architecture. 4.6. SCA waveform development. When developing an SCA waveform, the operating environment (Core Framework, CORBA middleware and operating system) is provided as the base structure. The only thing the developer should need to be concerned about is the top layer in figure 2.2 on page 6, the application layer.. 4.6.1 Development tools There exist several development tools and toolkits for the SCA environment. Having access to such a toolkit would probably making development of SCA compliant waveforms a lot easier in comparison to having to do most of the structural work on your own, as we did in this thesis. Examples of companies delivering such tools are Prismtech1 and Pentek2 . However, they are not cheap which can make it difficult for small businesses and hobbyists to make use of them. An article [6] in an Internet forum describes such a development kit going for $85000.. 4.6.2 The API of SCA The SCA specification provides an Application Program Interface (API) which defines structures to simplify the construction of portable SCA applications [13],[8]. These structures are organized much like the OSI model in different layers, with each API describing a layer. This is shown in picture 4.5. Network. Waveform Application. A. A A. Data and Real-Time Control B Non-real-Time Control, Setup and Initialization, from applications, other levels, user interface. Logical Link Layer. B. MAC Layer. B. Logical Link Layer. B. A. A I/O Layer. B. External Network Connection. A Physical Layer. B. Figure 4.5 Organization of the API layers Each API is then divided into what is called “Service Groups”, small groups of functions that are relatively closely related. This way, the developer only has to implement the specific functions of the API which is needed for his waveform application. 1 2. http://www.prismtech.com http://www.pentek.com.

(29) 4.6. SCA waveform development. 19. For more information on the details of the various API components, see the SCA Developer’s Guide [13] and the SCA API supplement [8]..

(30) 20.

(31) 21. Chapter 5 GNU Radio This chapter describes the design concepts of GNU Radio.. 5.1. Overview. As stated in chapter 2, software radio is about getting the software source code as close to the antenna as possible. Besides that all radio functions such as modulation and filtering takes place in software, reconfiguration and even upgrading your radio over the air to handle a completely new waveform can be done on the fly. GNU Radio [3] is a free toolkit for learning about, building and deploying software radios. It provides a library of signal processing blocks and the glue to tie all together. It is free and thus comes with complete source code, so anyone can make changes or see how the system is built. GNU Radio is designed to be easy to use, while still be powerful enough to handle complex data streams at a high sample rate. Therefore, all signal processing blocks are written in C++, while the procedure of putting them together to create a waveform is done with the scripting language Python1 .. 5.2. SDR Construction using GNU Radio. The programmer builds a radio waveform by creating a signal-flow-graph, where signal processing blocks process infinite streams of data flowing from their input ports to their output ports. The signal processing blocks have attributes such as the number of inputs and outputs they have, and what kind of data the streams consist of. The most common types of data are shorts, floats and complex number data. Some building blocks have only output ports or input ports, and these serve as data sources and sinks. Examples of sources include reading from a file or a block which generate sine waves. A sink might be a sound card, an D/A converter or a graphical display. 1. http://www.python.org.

(32) 22. Chapter 5. GNU Radio. 5.3. Creating your own building block. There might come a situation when you need a building block that is not included in the GNU Radio packages. Fortunately, there is a comprehensive guide on how to write your own building block, which is found at the GNU Radio web site [4]. There is also an expanded tutorial version of the guide written by Dawei Shen at the Department of Electrical Engineering at the University of Notre Dame [14]. C++ is the language used to create signal processing blocks in GNU Radio. At a high-level point of view, infinite streams of data flow through the ports as mentioned in the previous section. At the C++ level, these streams are ordinary arrays of the particular data type used. When developing a new building block, we need to construct it as a shared library that can be dynamically loaded into Python using the “import” mechanism. More information on how “import” works can be found in the Python tutorial [17]. It’s similar to the “#include” statement in C or C++. To accomplish this, SWIG comes into the picture!. 5.3.1 SWIG One of GNU Radio’s strengths is that it uses the powerful scripting language Python to build the waveform at a higher level, but uses C++ functions at a lower level of abstraction. To be able to use the C++ functions at the higher level, a “glue” called SWIG [10] is used. SWIG is an abbreviation for Simplified Wrapper and Interface Generator. SWIG connects programs written i C and/or C++ with various high-level scripting languages such as Python, Perl, PHP or TCL.. 5.3.2 Boost One important thing about GNU Radio building blocks, is that they make use of Boost smart pointers. Boost 2 is a collection of C++ libraries, and is required for the installation of GNU Radio. It provides powerful extensions to C++, and GNU Radio uses one of Boost’s useful features: the smart ptr library, so called smart pointers. Smart pointers are objects which stores pointers to dynamically allocated objects. They automatically delete the objects they point to at the appropriate time, since in fact the smart pointers own the object they point to, and therefore are responsible for their destruction. Smart pointers are defined as class templates, so when we need a smart pointer to point to our object, we make a typedef of the template to our particular class. This can be seen in detail in the source code. The point in using smart pointers is that the programmer doesn’t have to be worried about memory leaks and destruction of objects, the Boost library takes care of that. The programmer treats the Boost smart pointer as a regular C++ pointer!. 5.3.3 Naming Conventions GNU Radio uses certain naming conventions of files and classes to help the waveform developer keep track of how a component works and what parameters it uses, and also to keep a consistency in how the blocks are constructed. For instance, suffixes are used to indicate the 2. http://www.boost.org.

(33) 5.3. Creating your own building block. 23. input and output types of a block. The first character in the suffix shows the input type, while the second indicates the type of the output stream. An example is the block gr_add_ff where the output is the sum of all the inputs. Here _ff says that the input and output streams consist of float types. Several other naming conventions exist, and can be found in the tutorial.. 5.3.4 Much more to know Then there are other things needed to be known when creating a new building block, such as the correct directory structure for the files, how to use the GNU autotools for compilation, and how to modify the makefiles. All of these subjects is quite lengthy in detail, and can be read about in the tutorial [14]. We won’t explain them all in this thesis. Some things should be said about the C++ class though.. 5.3.5 The C++ Class When constructing a new building block, one creates three files. The .h file where the class declaration goes, the .cc where the actual class implementation is, and a SWIG file, .i, which tells SWIG the gluing guidelines for the building block. It is common practice when creating the class declaration in GNU Radio to make the constructor private. This of course prevents the programmer from creating a new object like this: square_ff * my_squaring_object = new square_ff();. This is because we always want to make use of the Boost smart pointers! Doing like above would only create a normal C++ pointer. Instead we have a method in the class which returns a Boost smart pointer to the desired object, like this: \\ This is the header file: typedef boost::shared_ptr<square_ff> square_ff_sptr; square_ff_sptr make_square_ff(); class square_ff { private: square_ff(); friend square_ff_sptr make_square_ff(); }. \\ This is the implementation file: square_ff_sptr make_square_ff() { return square_ff_sptr (new howto_square_ff()); }.

(34) 24. Chapter 5. GNU Radio. square_ff::square_ff() { // In this example we do nothing }. In this example, we first make a type definition that square_ff_sptr shall be a Boost smart pointer to a square_ff object. Then we declare the method make_square_ff() which returns a Boost smart pointer to a square_ff object. This method is a friend of the square_ff class, and therefore have access to the square_ff constructor! The implementation of make_square_ff() simply returns a typecast Boost smart pointer to a square_ff object, and we use this method whenever we want a new square_ff object. This way we make sure that there will never be any regular C++ pointers to objects in our program!. 5.4. A simple example. We end this chapter with a small example of how to use GNU Radio from the end user’s point of view. The following Python example illustrates a simple signal generator, and is taken from the article Exploring GNU Radio [12]. #!/usr/bin/env python from gnuradio import gr from gnuradio import audio def build_graph (): sampling_freq = 48000 ampl = 0.1 fg = gr.flow_graph () src0 = gr.sig_source_f (sampling_freq, gr.GR_SIN_WAVE, 350, ampl) src1 = gr.sig_source_f (sampling_freq, gr.GR_SIN_WAVE, 440, ampl) dst = audio.sink (sampling_freq) fg.connect ((src0, 0), (dst, 0)) fg.connect ((src1, 0), (dst, 1)) return fg if __name__ == ’__main__’: fg = build_graph () fg.start () raw_input (’Press Enter to quit: ’) fg.stop (). We start by creating a flow graph to hold the blocks and connections between them. The two sine waves are generated by the gr.sig_source_f calls. The f suffix indicates that the source produces floats. One sine wave is at 350 Hz, and the other is at 440 Hz. Together, they sound like the US dial tone..

(35) 5.4. A simple example. 25. The block audio.sink() is a sink that writes its input to the sound card. It takes one or more streams of floats in the range -1 to +1 as its input. We connect the three blocks together using the connect() method of the flow graph. The connect() method takes two parameters, the source endpoint and the destination endpoint, and creates a connection from the source to the destination. An endpoint has two components: a signal processing block and a port number. The port number specifies which input or output port of the specified block is to be connected. In the most general form, an endpoint is represented as a Python tuple like this: (block, port number). When port number is zero, the block may be used alone. Once the graph is built, we start it. Calling start() forks one or more threads to run the computation described by the graph and returns control immediately to the caller. In this case, we simply wait for any keystroke..

(36) 26.

(37) 27. Chapter 6 Implementation of the MATH Waveform In this chapter the MATH (MAnsour-THomas) Waveform is described, and in section 6.2 and section 6.3 our two different implementations of the MATH waveform are discussed.. 6.1. Introduction. At the stage in our thesis work when we had acquired knowledge about SCA and CORBA, studied GNU Radio and Python and tried some programming in a CORBA environment to learn even more, we sat down and thought about what kind of waveform we would implement. We figured out that maybe a simple FM or AM waveform would be nice, but after some thinking we thought that wasn’t good enough for the SCA implementation. One necessary thing to have in mind was that we would use the sound cards of ordinary PCs as the analog part of the radio system. Instead of having a real radio transmitter and receiver, we would simply connect two sound cards together and send the data, whatever it might be, over this simulated “radio interface”. After some discussion with our supervisor Daniel, he suggested that we should skip the actual modulation of the signal to begin with, and concentrate on the digital signal pathway in the SCA implementation. The important thing wasn’t the modulation, but to understand the SCA way of designing Software Radio. We would just let the sound cards act as regular D/A and A/D converters. We thought that it would be nice to have some sort of configurable waveform, since this is one of the basic ideas of a software radio. So we decided that we should be able to transmit ordinary sound, but also be able to switch to a text mode where regular text messages could be typed in and transmitted. We named this waveform MATH, which is a sort of abbreviation of our names, Mansour and Thomas. Keep in mind that we hadn’t decided anything about what kind of modulation that could or should be used, this was a decision we postponed. To sum things up, we wanted a waveform that should be configurable to transmit and receive ordinary sound or text messages, and it should have no modulation to start with. Then the actual work began, and we started with the SCA implementation since we realized this would consume most of our time..

(38) 28. 6.2. Chapter 6. Implementation of the MATH Waveform. SCA implementation. We figured out almost from the beginning that the SCA implementation would take a lot more time than the GNU Radio implementation. First of all, we had to get a working development environment up and running. We knew that we were supposed to develop an SCA waveform, and for that we needed an SCA Core Framework. It turned out that most Core Frameworks were closed source and had to be purchased. Our supervisors then found a suitable CF called OSSIE, an open source initiative at Virginia Tech University. They gave us the address to the OSSIE web page, and we were off.. 6.2.1 The beginning steps This section is a description on what went on during the first time of our SCA development. Understanding of CORBA Before we approached SCA we had to have understanding of CORBA. A good start was the CORBA FAQ at OMG’s web site [5]. After we had gotten some comprehension of what CORBA was and how it worked, we installed the TAO ORB [11] which our supervisors had suggested we would use. At the TAO web page we found some CORBA tutorials which we examined thoroughly, and we proceeded by implementing a simple client-server application using the tutorials as help. We then extended this application to include support for the CORBA Naming Service. Now we thought we were ready to take on SCA. The test example We started by examining the example of an SCA waveform that was shipped with OSSIE. It was a nasty composition of files which didn’t make much sense to us at all. This was even before we had decided what kind of waveform we would develop, we just wanted some handson feeling on SCA development. After a lot of reading the source code back and forth, we had somewhat sense of how things worked. Or at least how the OSSIE team thought things should work. Our first attempt We then tried to do something similar to what the OSSIE team had done, which were more difficult than we expected. Our first attempt at creating a small test-application took us at least a couple of weeks. A lot of time was spent on debugging the OSSIE source code to find out why our application wouldn’t install in the DomainManager. At last we had a small SCA waveform which did absolutely nothing, but at least it was installed within the SCA Domain and everything worked as expected! SCA Developer’s Guide At this point in time, our supervisor Daniel mentioned a document called “SCA Developer’s Guide” [13]. We had completely missed this highly informative document on the JTRS web.

(39) 6.2. SCA implementation. 29. site! This document turned out to be a huge step forward in understanding SCA and SCA waveform development. The SCA Developer’s Guide is a comprehensive document prepared by the Raytheon Company in 2002. It has an overview of the SCA and all it’s components, on overview of the APIs and domain profile components, and a full chapter with recommendations and procedures the developer can follow during the course of waveform development.. 6.2.2 The MATH implementation After we have studied the developer’s guide and discussed matters with our supervisor, we decided to create a model of our application. This model is shown in figure 6.1.. UI Real Time Non-Real Time. Assembly Controller. Waveform MAC Layer. Waveform Physical Layer. Soundcard "Modem". Figure 6.1 Model of the MATH waveform In this model, we see several blocks. The two most important blocks are the Physical and MAC, which represent the two layers “Physical Layer” and “MAC Layer” mentioned in chapter 4, section 4.6.2. Connected to them is the Assembly Controller. It is a required part of an SCA waveform, and the SCA Application component delegates all Resource operations other than getPort() to the Assembly Controller. It also handles the communication with components outside the waveform, and in picture 6.1 we see that the graphical user interface is connected to the Assembly Controller..

(40) 30. Chapter 6. Implementation of the MATH Waveform. 6.2.3 Functionality During sending, the signal originates in the MAC layer, and is then sent down to the Physical layer which transmits the signal out on the sound card. The Assembly Controller handles configuration of both the Physical and MAC components. There is a signaling system used in the MAC and Physical layer to handle the data communications. This system is described in section 6.2.4. Due to time limitations we never implemented an SCA receiver, therefore only the downstream real-time transmission line in the picture is used, the one from MAC to Physical. Otherwise, in receiving mode, the Physical component would receive the signal and send it upstream to the MAC component which would handle it in the appropriate way. There is some source code for the receiver though, a sort of skeleton which could be made into a receiver. For that same reason as well as a lot of problems with the sound card, we never finished the text function. As recalled, we wanted to be able to send both audio and text messages. But as we didn’t modulate the signal, the text function wasn’t easy to implement. An easy way would be to modulate 1 bit of the text message as a 16 bit word, since the sound card uses 16 bit words. But experiments with the sound card showed that this was not a good idea. A better way to go would be to implement QPSK or BPSK modulation, but this was something we didn’t look much into due to lack of time. The C++ source code to these components can be found in appendix D. MAC component We decided that we would transmit ordinary wave sound files, 16 bit, 2 channels and 44100 kbps. After the application has started, these events occur in the MAC component: 1. A wave file is opened using the Core Framework’s FileSystem. This file is chosen through a file dialog in the user interface. The result is a Core Framework File. 2. A small chunk, which size is configurable, is read from the file. The Core Framework’s File interface reads the data into a CORBA::OctetSequence, which is a sequence of CORBA::Octets that can be unlimited. 3. The file chunk is then repacked and converted into a CORBA::ShortSequence, which is the same as above, but has 16-bit data fields instead of 8-bit. We do this because the sound card is a 16-bit sound card, and therefore it would be nice to have the data in a 16-bit format. 4. Finally, the stream of data packets is sent to the Physical layer. 5. Step 2 to 4 are repeated until the application is stopped. The wave file can be changed when the application is not running. More exactly, it can be changed at any time through the user interface, but it is not until the application is stopped and started again that the old one is replaced..

(41) 6.2. SCA implementation. 31. Physical component This is where the actual transmitting of the signal takes place. Embedded in the Physical component is a C++ class for sound functionality since a sound card is to be used for the actual analog transmission. The sound class developed uses ALSA (Advanced Linux Sound Architecture) [1] to communicate with the sound card. Assembly Controller component The Assembly Controller directs the configure parameters from the user interface to the correct component. It also handles the start() and stop() methods for the whole Application. The Assembly Controller is a component required by the SCA specification. It doesn’t have to be a separate component, another SCA component can act as the Assembly Controller as well. We decided however to put it in a separate block. The Graphical User Interface In figure 6.2, a picture of the user interface is shown. When starting our application, this is what the user see. There are buttons for installing and uninstalling an SCA Application into the Domain Manager. Any SAD file can be chosen to be installed. When installed, the start and stop buttons can be used to start and stop the Application. There are also functions to choose which wave file to be played, if the application should be in audio or text mode and a checkbox to inhibit or shut down the physical transmission.. Figure 6.2 The SCA implementation of MATH. 6.2.4 Signaling system On a lower layer of description, the data that is moved from the MAC component to the Physical is stored in buffers. To prevent these buffer to be congested, a signaling system is used. This system is taken from the SCA API building blocks, and is called SignalsBB. SignalsBB has three methods, signalHighwatermark, signalLowwatermark and signalEmpty. When the receiving buffer in the Physical component is starting to get full, Physical sends a.

(42) 32. Chapter 6. Implementation of the MATH Waveform. signalHighwatermark to MAC to indicate what is happening. MAC then stops the data stream to let the Physical process the data in the buffer. When the receiving buffer in the Physical component is starting to be depleted, Physical sends a signalLowwatermark in order for MAC to start sending more data. The third signal, signalEmpty, is used to check the status of a buffer. This method return “true” if the buffer is empty.. 6.3. GNU Radio implementation. In GNU Radio, the scripting programming language Python is used to connect blocks together, and to start and stop the application. The basic idea is that the waveform developer designs a signal-flow-graph in Python using the GNU Radio building blocks. To start the waveform, the Python application calls the start() method on the signalflow-graph. Then there is a runtime system which does all the work of instantiating the correct classes and libraries, creating threads for execution, and makes sure there is a correct data flow between the different blocks. The runtime system is provided in the GNU Radio Core package, and one doesn’t have to worry about it at all as a waveform developer. When we got to the GNU Radio implementation time was running short, so we decided that we should only try to model and implement the receiving part of MATH in GNU Radio. The SCA implementation was as recalled modeled to be both transmitter and receiver, though only the transmitting part was actually implemented. Since GNU Radio is totally different from SCA in the meaning that a lot of building blocks already exist, we started by examining what blocks already existed, and what we might need for our waveform. We expected that at least one GNU Radio building block had to be implemented, some kind of MATH decoding block.. 6.3.1 First attempt When we first attacked the problem, we thought that a structure as shown in figure 6.3 would be a good start for the MATH waveform. The figure shows the signal-flow-graph which would later be created in Python. The MATH demux building block would take care of the separation of audio and text, and send them to the correct place. The audio sink would play sound, after it had been low pass filtered. The text output block would print the text messages. The FIR filter block comes in the GNU Radio core package for both floats and complex input and output streams, and the audio source and sink are also available in a separate package. So we didn’t have to implement these. It turned out that we couldn’t find a block that simply printed text on a terminal, so besides the MATH demux block this block had to be implemented as well. But after studying the build-your-own-block-tutorial and doing some work on the MATH demux block, we encountered a problem. The current version of GNU Radio only supports the same data rate for all output streams. We couldn’t shut off the pathway to the text box when audio is coming in, or have the audio sink not receiving any data if we are in text mode. This was a major setback, so we had to find another solution..

(43) 6.3. GNU Radio implementation. 33. Figure 6.3 First model for GNU Radio implementation of MATH. 6.3.2 Two signal-flow-graphs One way of solving the problem would be to have two signal flow graphs. One to use in text mode, and one for the audio mode. These two graphs would then be started and stopped in Python, accordingly to which mode we wanted to be in. Figure 6.4 shows a model of this. math_text_graph: audio source. Text decoding. Terminal text output. math_audio_graph: audio source. FIR filter. audio sink. Figure 6.4 Second model for GNU Radio implementation of MATH The text decoding block and the text output block could perhaps be combined to one block as well, as they both needed to be implemented.. 6.3.3 The actual implementation Since stated earlier in this thesis, we never got to implement the text part of the MATH waveform. Therefore, the text decoding block doesn’t contain much. We gave it the name math_console_writer_f, where the _f states that the block takes floats as input. The idea is to decode the input stream, and print the message on stdout or some other output console. Though our block doesn’t perform any signal processing, it integrates and works in the GNU Radio environment nevertheless! The block was implemented as sort of a “black hole”, is just takes data on the input and does nothing with it..

(44) 34. Chapter 6. Implementation of the MATH Waveform. 6.3.3.1. The C++ code. It is not that hard to implement your own building block, we just followed the example in the tutorial [14], which is really good and comprehensive. It mostly involves following a recipe where you besides writing the class for your block, replace some rows in the GNU autotools configuration files and the SWIG configuration file. These files can be downloaded together with the tutorial at the GNU Radio web site. The documentation on these GNU autotools files is very sparse in the tutorial, and it is recommended that anyone who wants to develop own signal processing blocks learns how to use, create and modify them. We ran into some problems when compiling our block, and this was related to the fact we didn’t know how these files worked. But after some troubleshooting things worked as expected. We can mention that there is some SWIG magic behind the scenes when the block compiles. This way, we can access the math_console_writer_f block using the regular Python notation math.console_writer_f(). The C++ source code can be found in appendix C. 6.3.3.2. The Python code. We started off in an uncommon way by implementing the Graphical User Interface (GUI) first. We wanted to have a similar look as the SCA implementation, so wxPython 1 was the way to go. More information about this way of writing portable user interfaces can be found in appendix A. The application consists of two signal-flow-graphs as shown in figure 6.4, which we then could alternate between using two common radio buttons in the GUI. The GUI also provides a way of starting and stopping the waveform. The signal-flow-graphs are quite simple. The first which implements the audio part consist of an audio source, where the signal is received from the sound card. It is followed by a lowpass FIR filter to filter out any high-frequency noise components in the signal. Finally, the signal is connected to an audio sink. The other signal-flow-graph which would implement the text part is even simpler. It starts with an audio source, followed by our math_console_writer block. The Python code can be found in appendix C.. 1. http://www.wxpython.org.

(45) 35. Chapter 7 Conclusions In this chapter we draw conclusions of our work. Pros and cons of the two different ways of developing Software Radio are presented, and we end the chapter with a comparison of the two methods.. 7.1. Developing waveforms using SCA. 7.1.1 Benefits and advantages First of all, the SCA is a well defined, open standard. There are no license costs or other means which may prevent developers of using it. This make it a good base for interoperability and information exchange. Second, the SCA is a strictly defined set of guidelines. If these guidelines are followed, it is very easy to make portable waveforms. Parts of one waveform on one platform can easily be re-used in another waveform on another platform. Benefits using CORBA IDL structures The CORBA IDL is a very strictly defined language, which makes sure that the resulting code behaves exactly the same way regardless of what language it is compiled into, or on what platform. This is good for a developer using CORBA IDL, since he can be 100 % sure that his application will be platform independent, and work in any environment. CORBA itself is developed with high performance and scalability in mind, which makes it a good choice as the SCA middleware. Since the interfaces that the SCA CF consists of are defined in CORBA IDL they can be used on any platform or CPU, and waveforms can be developed using any programming language as long as there is an IDL compiler for it. This way, the SCA makes it very easy to develop portable waveforms. The possibility of easily taking building blocks from one waveform and using them in another can help cut the development time and costs significantly. Also, different parts of a waveform application can run on different machines or devices using different operating systems and CPUs. Using CORBA as middleware does not only ease communications within the waveform and makes sure strict interfaces are defined, it also separates the underlying operating system from the application which aids portability..

(46) 36. Chapter 7. Conclusions. Easy generating new interfaces Once the waveform developer has come across the initial quite high step of gaining the required knowledge regarding SCA, it it fairly easy to create new interfaces and waveform models and integrate these into a waveform application. For instance, one can model the interfaces in UML and then generate the appropriate IDL from the UML.. 7.1.2 Disadvantages of SCA We have found several difficulties with the SCA, and they are presented below. High learning threshold In the beginning of our work we almost immediately came across what we think is the biggest disadvantage of SCA, it takes a lot of time understanding what it is all about! Our first encounter with SCA was the picture on page 6, which didn’t make sense at all, and a printout of the huge SCA specification[9]. It took us weeks just to get an overview of how the structures work, and even now when we are finished it still can be difficult to understand and remember how some things work and are used. The SCA is a very complex specification, with a lot of different files and events that much occur in order to have a working application. This in combination with sparse detailed documentation how to develop waveform applications creates a rather high threshold of understanding to overcome, before being able to begin the work on the actual waveform. Disadvantages regarding CORBA Another major issue we had lots of problems with was the CORBA environment. CORBA itself is not difficult to understand and use. It was when we had several programs that were to interact with each other the problems occurred. Our Physical and MAC resources were both CORBA servers and clients at the same time, and the problem was really how to use the CORBA event loop and the ORB itself in a good fashion without losing performance. We spent many days searching for good ways of doing this, and tried different solutions. We once even rewrote our whole CORBA initialization code from scratch in despair. Here is the scenario: The server part of each resource has to wait for incoming CORBA requests, which is done by a call to the ORB::run() method or to the ORB::perform_work() method. The first is a call which never returns unless the ORB is shut down or destroyed. But in our case it didn’t even return if the ORB was destroyed, for reasons we were unable to find. The latter method performs one unit of work, and then returns. There is also a method called ORB::work_pending() which checks if there is any CORBA work to be done for a particular servant, and this is used in conjunction with ORB::perform_work(). We weren’t able to use the ORB::run() call since we couldn’t shut down our processes upon exiting the application, so our application uses ORB::perform_work(). Our problems showed up as time delays and hang-ups when calling ORB::perform_work() from several processes. At first there was just a major hang-up in all the processes. None of the components worked, they were all waiting for their ORB calls to return, as they depended on each other.

No results found