Abstract
GPPs have become fast enough to implement all of the DSP for practical radios. As discussed in Sect. 5.1, an all-software radio is considered the holy grail of SDR development [122]. Presently, the two most popular open-source SDR platforms are GNURadio and OSSIE. In this section,we will explore these platforms in some detail.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
An open-source software tool called SWIG is makes blocks developed in C++ available in Python.
- 2.
For example, an ‘adder’ block can be declared with an arbitrary number of inputs and one output. The block can then be used to sum up multiple data streams, with the number of streams determined at runtime.
- 3.
The naming convention is not enforced and some blocks do not follow it.
- 4.
Only a few items are expected to be tagged since tags are processed much slower than the items themselves.
- 5.
GR defines an abstract polymorphic type, pmt_t. This type acts as a container for arbitrary data types (e.g. doubles, floats, structs, arrays, etc.).
- 6.
The top-level GUI or control application can also call member functions of the blocks directly. Messages provide a higher level interface that is guaranteed to be thread-safe. Messages also make it easy to control radios that execute on multiple computers.
- 7.
Many blocks also define functions to set parameters at runtime (e.g., set the gain on a ‘multiply’ block).
- 8.
The performance improvement is strongly dependent on the coding style. GR developers are actively working on integrating processor-specific optimizations into the GR baseline. The latest version of GR provides a library of hand-coded assembly functions called VOLK to take advantage of modern processors [287]. Users can expect baseline GR performance to improve, making it closer to what is achievable with an optimizing compiler and vendor libraries.
- 9.
Older versions of GR used a single threaded scheduler.
- 10.
This constraint is not always easy to achieve. Multiple blocks generating and consuming data at different rates cause ‘fragmentation.’ Fragmentation means that the scheduler calls the work function with only a few samples. Larger sample sets can be enforced by setting a minimum number of samples a block can accept. The problem is exacerbated if feedback loops exist between blocks. The author has observed scenarios where 90 % of the CPU time was spent in the scheduler itself rather than in the work functions. These anomalous conditions are difficult to identify and debug.
- 11.
More full-featured examples are available at the GR archive network (GRAN) at https://www.cgran.org.
- 12.
A mostly complete list of fundamental blocks is available at http://gnuradio.org/doc/doxygen/modules.html.
- 13.
GR development guidelines suggest using automatic regression testing for every new block.
- 14.
Common sense is usually insufficient. The author came across a design where the noise generation block took significantly more computational resources than a Viterbi decoder. Also see footnote 10 in this chapter.
- 15.
In this section, SCA and OSSIE will be used interchangeably.
- 16.
It is relatively easy to build an application in GR that runs on multiple computers. For example, the UDP source/sink blocks can be used to transfer samples between machines. However, this approach is ad hoc, versus the well-defined ORB architecture.
- 17.
Only the: ProcessData() function is modified to implement the desired signal processing. This is very similar to modifying the: work() function in a GR block.
- 18.
The venerable X-Midas (multiuser interactive digital analysis system for X-windows) framework is a quasi-open-source alternative to GNURadio. X-Midas has been in development since the 1970s and is used exclusively by the intelligence community. It is only available to qualified users from the government. X-Midas provides most of the functionality available in GR, and a simple wrapper can be created to make GR blocks execute ‘as-is’ in X-Midas. A parallel development from the X-Midas community is available to the general public [288].
- 19.
A static scheduler also avoids data the fragmentation problem discussed in footnote 10 in this chapter.
- 20.
Unless the SDR is used for simulation rather than for actual communication.
- 21.
The signal could even be sent over the air, but an enormous antenna is required to efficiently transmit a 15 kHz carrier (wavelength = c/15e3=20 km). Practically, a smaller antenna would work at the cost of reduced SNR.
- 22.
First-generation USRP provides four A/D and D/A channels, but RF daughter boards support only two.
- 23.
The FPGA is relatively small and is not suitable for complex DSP such as FEC decoding.
Author information
Authors and Affiliations
Corresponding author
Rights and permissions
Copyright information
© 2013 Springer Science+Business Media New York
About this chapter
Cite this chapter
Grayver, E. (2013). Software-Centric SDR Platforms. In: Implementing Software Defined Radio. Springer, New York, NY. https://doi.org/10.1007/978-1-4419-9332-8_8
Download citation
DOI: https://doi.org/10.1007/978-1-4419-9332-8_8
Published:
Publisher Name: Springer, New York, NY
Print ISBN: 978-1-4419-9331-1
Online ISBN: 978-1-4419-9332-8
eBook Packages: EngineeringEngineering (R0)