Analysis of GNU Radio and experimental measurements on USRP’s Daughter boards

Get Complete Project Material File(s) Now! »

Interoperability

The interoperability or radio bridging enables heterogeneous radio networks to inter operate by dissimulating their differences. The challenge is to have a multi-standard, multiband and an open radio system. Traditionally, a radio transceiver is limited to communications only with nodes that share the same radio properties. The latter could be waveform, frequency band, modulation type and data communication proto- col. However, a radio bridge acts as a translator between heterogeneous transceivers.
It receives a signal encoded in one format and retransmits it following another specification. Primarily, the interoperability is addressed in military applications [47].

Challenges

In section 2, we saw that the main SDR challenge is to overcome the limited processing power. Consequently, Intermediate Frequency part (see Section 2) is unavoidable to get an SDR processing look like Software Radio. In this section, other challenges of SDR solution are addressed.

Handling of an SDR platform

Numerous SDR platforms have been developed in the last decade with different integration levels of hardware and software architecture. For software-designer, high-level programming could be an easy way to handle software, but at the expense of a high hardware physical dimensions. Furthermore, the type of the architecture, i.e. distributed or centralized, is an important element to understand how to use different components. A centralized architecture could be easier to manage than a distributed one. For example, the SCA [46] is distributed and interoperability is guar- anteed via Common Object Request Broker Architecture (CORBA) middleware. Understanding software architecture and programming with CORBA require more  efforts than programming on a host computer. In CORBA, the software/hardware object locations of architecture are hidden to designers. Whereas, programming on host computer is more simple, since all objects are present in the same physical place. GNU Radio and Universal Software Radio Peripheral (USRP) [37] follow a centralized architecture with a host computer programming. On GNU Radio soft- ware, mastering high-level programming languages is required to construct software communication chains. In fact, source codes are written in C++ and Python and most of the time not commented (lack of comments) making them hard to understand.
In addition, these codes are commonly generated by a machine. RF performances of USRP hardware, which is connected to GNU Radio are not documented. Thus, implementations on USRP and GNU Radio can be time consuming. In spite of these drawbacks, this platform presents several advantages which will be discussed in the next Chapter.

Hardware physical dimensions

Physical dimensions issue comes from the need to integrate SDRs in constrained applications, such as WSNs applications. It affects SDR capabilities, especially, power processing and energy autonomy. Commonly, it depends on the hardware front-end size and on the baseband processing software. Signal processing is a greedy operation, and it is performed at various stages of the transmitting and receiving chains. Thus, the capabilities of baseband processing part can be considered as a reference to define hardware dimensions and programming languages of an SDR platform. In the case of a GPP configuration, a high-level programming language on a host computer is preferred by designers. Thus, the platform is cumbersome and less usable for Wireless Sensor Networks (WSNs). In the case of an interoperable architecture like SCA [46], a middleware manages several technologies, e.g. FPGA, DSP, and GPP, etc. Actually, SDR nodes for WSNs is a futuristic technology, regarding constraints of one SDR.

Radio frequency performances

We have shown in Section 2 the general architecture of an SDR, IF is the bottleneck of an ideal SDR. In fact, SDR performances depend on hardware’s computational resources and front end design. Dedicated purpose and non programmable chips offer high-performances, but they are avoided, since they are limited in terms of flexibility. However, an IF or a baseband filter sets the analog bandwidth from a minimum to a maximum frequency. Furthermore, ADCs and DACs define SDR’s sampling rate or a processing bandwidth.

Baseband processing hardware

Several hardware components of baseband processing could match with SDR require- ments. ASIC is not a reconfigurable processing component, but it is useful when efficient processing is preferred [44]. However, an FPGA is an alternative to an ASIC.
It rapidly reconfigures any waveform component through a specific program. Hence, it is a preferred choice for an environment with real time constraints, particularly when an application needs some permanent connectivity. Furthermore, an FPGA requires significant energy and produces unpleasant heat for a handheld SDR.
A host computer simplifies the reconfiguration of baseband signal processing. It runs SDR’s source codes over GPPs. The Operating System (OS) of host computers creates an abstraction layer over a GPP by running different applications. In fact, the OS handles software programs with little or no knowledge of underlying hardware management [48]. The memory manager of such architecture also combines numerous programs without a special care on Random-Access Memory (RAM) of software development.
DSPs are similar to GPPs, since they can be programmed with a high-level lan- guage such as C or C++ for processing and running under an Operating System (OS). However, the difference comes from instructions set and on memory management. The instructions of a DSP are dedicated to a particular application.

SDR standards and architectures

In this chapter, we quote a list of existing Software Defined Radios. This list is organized in standards and architectures. Furthermore, they are classified, regarding main parameters, i.e. baseband programming languages and front-end hardware.

Software Communication Architecture SCA

Software Communication Architecture (SCA) is an open and common architecture allowing a designer to define hardware and software elements running on Joint Tactical Radio Systems (JTRS) SDR [46]. Software radio programs are defined to process waveforms in different layers while CORBA ensures interactions among them [48]. For an embedded application, CORBA is greedy in processing power and in memory resources. Hence, the focus of embedded SDR community shifted away from CORBA. Architecture improvements have been made by SDR forums and by the Object Management Group (OMG). The objective was to simplify the architecture and to separate the SCA and waveform components from the operating environment (see Figure 2.5). The latest specifications of the SCA in versions 2, 3 and 4 discuss the use of an FPGA [49]. As explained in Section 3.2.4, an FPGA is more reconfigurable and has a higher processing power than a DSP or an ASIC. The FPGA can accomplish digital processing of the IF and that of the baseband processing part of an SDR. It can also performs specific processing such as cryptography algorithms. Figure Core Framework and Waveform. The SDR’s core framework handles all underling software responsible for running waveform processing.

READ  Beam splitting with stimulated Raman transitions

Open Source SCA Implementation::Embedded (OSSIE)

OSSIE is an open-source SDR and Object Oriented SCA architecture [50]. It is implemented over a CORBA middleware working on a Linux operating system and carried out by Intel or Advanced Micro Devices (AMD) based computer. The core framework of OSSIE contains signal-processing components and software interfaces based on CORBA. The objective behind OSSIE is to reduce the designer’s learning curve of the SCA and the cognitive radio. Furthermore, for a proof of concepts, SDR prototyping can be faster than other software architecture. However, CORBA requires a lot of memory resources, and the objects communicate with fewer throughput. In fact, SCA performances depend on the object size, since several objects have to be exchanged within the SCA [44].

Table of contents :

1 Introduction 
1 Historical Elements and Context
2 Definitions
2.1 Software Radio and Software Defined Radio
2.2 Cognitive Radio
2.2.1 Spectrum Sensing
2.2.2 Dynamic Spectrum Access
2.3 Wireless Sensor Networks
2.3.1 IEEE 802.15.4 standard
3 Thesis motivations
3.1 Context of WSNs
3.2 Applications of WSNs and SDRs
4 Thesis objectives
4.1 SDR platform to implement standardized PHY layer of WSNs
4.2 Cognitive Radio for Spectrum Scarcity
5 Thesis Organization and Contributions
5.1 State of the art on Software Defined Radio
5.2 Analysis of GNU Radio and experimental measurements on USRP’s Daughter boards
5.3 SDR implementations of IEEE 802.15.4 standard
5.4 Cognitive Wireless Sensor Network based on IEEE 802.15.4
2 State of the art on Software Defined Radio-SDR 
1 Introduction
2 Typical architecture of an SDR
2.1 SDR Receiver (Receiver (Rx))
2.2 SDR Transmitter (Tx)
3 Features and Challenges of SDR
3.1 Features
3.1.1 Reconfigurability
3.1.2 Portability
22 Contents
3.1.3 Interoperability
3.2 Challenges
3.2.1 Handling of an SDR platform
3.2.2 Hardware physical dimensions
3.2.3 Radio frequency performances
3.2.4 Baseband processing hardware
4 SDR standards and architectures
4.1 Software Communication Architecture SCA
4.1.1 Open Source SCA Implementation::Embedded (OSSIE)
4.2 Reconfigurable Radio System RRS
5 SDR for Embedded Devices
5.1 GPP based architecture
5.2 Reconfigurable hardware based architecture
6 SDR classifications
6.1 Programming model
6.2 Used hardware
6.3 SDR platforms
7 Summary
3 Analysis of GNU Radio and USRP SDR 
1 Introduction
2 GNU Radio
2.1 Programming language layers
2.2 Software blocks
2.3 Flow graphs
2.4 Software scheduler
2.5 SIMD programming (Volk)
3 Universal Software Radio Peripheral
3.1 USRP Architecture
3.2 Transmit and Receive Paths
3.3 RF daughter boards
3.4 Firmware and FPGA images
3.5 Universal Hardware Driver (UHD)
4 GNU Radio and USRP properties
4.1 Latency and throughput
4.2 Buffers organization
4.3 Performance counters and ControlPort
5 Advantages of GNU Radio and USRP
6 Summary
4 Radio Frequency Measurements on USRP Daughter boards 
1 Introduction
2 Problem statement
2.1 An overview of BPSK modulation
2.1.1 The BER and SNR parameters
2.1.2 BER/SNR estimators on GNU Radio simulation
2.1.3 BER/SNR estimators in real experiment
2.2 Related Works
3 Experimental approach
3.1 Hardware Setup
3.2 Software Setup
3.2.1 The expected DAC vs ouput power relationship
4 Spectrum Analyzer measurements
4.1 RFX2400 Daughter board
4.1.1 Frequency bandwidth
4.1.2 Output power versus DAC value
4.2 RFX900 Daughter board
4.2.1 Frequency bandwidth
4.2.2 Output power versus DAC value
4.3 SBX Daughter board
4.3.1 Frequency bandwidth
4.3.2 Total Harmonic Distortion (THD)
4.3.3 Output power versus DAC value
4.4 MIMO USRP B210
4.4.1 Frequency bandwidth
5 Measurements through flow graphs
5.1 RFX and SBX Daughter boards
6 Empirical model for SBX daughter boards
7 Summary
5 SDR implementations for IEEE 802.15.4-based WSN 
1 Introduction
2 Problem statement
3 Related works
4 IEEE 802.15.4 PHY layers
4.1 Common specifications for 868/915 MHz and 2450 MHz PHY layers
4.2 2450 MHz specifications
4.3 868/915 MHz specifications
5 Software Implementations
5.1 Software transmitter/receiver for 2450 MHz PHY
5.1.1 Tx flow graph
5.1.2 Rx flow graph
5.1.3 Packet decoder
5.2 Software transmitter/receiver for 868/915 MHz PHY
5.2.1 Tx flow graph
5.2.2 Rx flow graph
5.2.3 Packet decoder
6 SDR communications for 2450 MHz
6.1 Communications between two SDRs
6.2 Communications between sensor motes and SDRs
7 SDR communications for 868/915 MHz
8 Summary
6 Cognitive Wireless Sensor Network based on IEEE 802.15.4 
1 Introduction
2 Problem statement
3 Related works
3.0.1 Related specifications
3.0.2 Related implementations
4 Dynamic spectrum access on GNU Radio USRP SDR
4.1 Reconfigurable SDR settings
4.2 Energy Detector
4.3 Dynamic frequency selection
5 Experiments and results
6 Summary
7 Conclusions and Future Work 
1 Conclusions
2 Future Work

GET THE COMPLETE PROJECT

Related Posts