1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
/*! \mainpage
\image html gnuradio-logo.png
Welcome to GNU Radio!
For details about GNU Radio and using it, please see the <a
href="http://gnuradio.org" target="_blank"><b>main project page</b></a>.
Other information about the project and discussion about GNU Radio,
software radio, and communication theory in general can be found at
the <a href="http://gnuradio.squarespace.com" target="_blank"><b>GNU Radio blog</b></a>.
\section build Building GNU Radio
See the \ref page_build page for details about the project's
dependencies and build process.
\section blocks GNU Radio Blocks
GNU Radio uses discrete signal processing blocks that are connected
together to perform your signal processing application. This manual
contain a list of all GNU Radio <a href="modules.html"><b>C++ Blocks</b></a>.
Please note that at this time, we haven't found an acceptable way to
provide unified documentation for the C++ parts of the system and the
parts written in Python (mostly hierarchical blocks). Until this gets
worked out, please bear with us, or better yet, solve it for us!
\section toc Manual Contents
More details on packages in GNU Radio:
\li \ref page_audio
\li \ref page_digital
\li \ref page_qtgui
\li \ref page_uhd
\li \ref page_vocoder
\li \ref page_pfb
\section flowgraph Operating a Flowgraph
The basic data structure in GNU Radio is the flowgraph, which
represents the connections of the blocks through which a continuous
stream of samples flows. The concept of a flowgraph is an acyclic
directional graph with one or more source blocks (to insert samples
into the flowgraph), one or more sink blocks (to terminate or export
samples from the flowgraph), and any signal processing blocks in
between.
A program must at least create a GNU Radio 'top_block', which
represents the top-most structure of the flowgraph. The top blocks
provide the overall control and hold methods such as 'start,' 'stop,'
and 'wait.'
The general construction of a GNU Radio application is to create a top
block, instantiate the blocks, connect the blocks together, and then
start the top block. The following program shows how this is done. A
single source and sink are used with a FIR filter between them.
\code
from gnuradio import gr, filter
class my_topblock(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
amp = 1
taps = filter.firdes.low_pass(1, 1, 0.1, 0.01)
self.src = gr.noise_source_c(gr.GR_GAUSSIAN, amp)
self.flt = filter.fir_filter_ccf(1, taps)
self.snk = gr.null_sink(gr.sizeof_gr_complex)
self.connect(self.src, self.flt, self.snk)
if __name__ == "__main__":
tb = my_topblock()
tb.start()
tb.wait()
\endcode
The 'tb.start()' starts the data flowing through the flowgraph while
the 'tb.wait()' is the equivalent of a thread's 'join' operation and
blocks until the top block is done.
An alternative to using the 'start' and 'wait' methods, a 'run' method is
also provided for convenience that is a blocking start call;
equivalent to the above 'start' followed by a 'wait.'
\subsection latency Latency and Throughput
By default, GNU Radio runs a scheduler that attempts to optimize
throughput. Using a dynamic scheduler, blocks in a flowgraph pass
chunks of items from sources to sinks. The sizes of these chunks will
vary depending on the speed of processing. For each block, the number
of items is can process is dependent on how much space it has in its
output buffer(s) and how many items are available on the input
buffer(s).
The consequence of this is that often a block may be called with a very
large number of items to process (several thousand). In terms of
speed, this is efficient since now the majority of the processing time
is taken up with processing samples. Smaller chunks mean more calls
into the scheduler to retrieve more data. The downside to this is that
it can lead to large latency while a block is processing a large chunk
of data.
To combat this problem, the top block can be passed a limit on the
number of output items a block will ever receive. A block may get less
than this number, but never more, and so it serves as an upper limit
to the latency any block will exhibit. By limiting the number of items
per call to a block, though, we increase the overhead of the
scheduler, and so reduce the overall efficiency of the application.
To set the maximum number of output items, we pass a value into the
'start' or 'run' method of the top block:
\code
tb.start(1000)
tb.wait()
or
tb.run(1000)
\endcode
Using this method, we place a global restriction on the size of items
to all blocks. Each block, though, has the ability to overwrite this
with its own limit. Using the 'set_max_noutput_items(m)' method for an
individual block will overwrite the global setting. For example, in
the following code, the global setting is 1000 items max, except for
the FIR filter, which can receive up to 2000 items.
\code
tb.flt.set_max_noutput_items(2000)
tb.run(1000)
\endcode
\section volk_main Using Volk in GNU Radio
The \ref volk_guide page provides an overview of how to incorporate
and use Volk in GNU Radio blocks.
Many blocks have already been converted to use Volk in their calls, so
they can also serve as examples. See the gr_complex_to_xxx.h file for
examples of various blocks that make use of Volk.
*/
|
