Talk:FAQ: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
(add section 3)
(→‎RTL-SDR issues: new section)
 
(8 intermediate revisions by 3 users not shown)
Line 3: Line 3:
<hr>
<hr>


<b>DRAFT REVISIONS TO FAQ</b><br>
== Future Edits: Hardware support ==
<b>Frequently Asked Questions</b>


== Getting Started ==
After inclusion of gr-soapy in an official release, as well as gr-iio: Needs to state something like


=== What is GNU Radio? ===


Check out our page [[WhatIsGR|What is GNU Radio?]] for an introduction to what GNU Radio is and why you would want to use it.
== Does GNU Radio support my SDR hardware? ==


=== How do I get / install GNU Radio? ===
If you've got a


We strongly encourage you to use your distro package manager. Debian/Ubuntu and Fedora/RedHat as well as many of the other popular Linux distros keep these packages well up to date. For Mac OS X, using Macports is strongly encouraged. See [[InstallingGR]] for details.
* Ettus / National Instruments USRP: yes, through the included `gr-uhd` module (use the `USRP Sink` / `USRP Source`)
* a IIO device like the ADALM Pluto SDR: yes, through the included `gr-iio` module (GNU Radio version 3.x.y.z upwards)
* Any other device (e.g. RTL-SDR dongles): if there's a soapysdr plugin [Link to Soapysdr] for it, then it can be used through gr-soapy (GNU Radio version 3.a.b.c upwards)


=== Which operating systems are supported? Does GNU Radio run on Windows or Mac OS X? What about 32, 64 Bits? ===
Generally, gr-soapy is an abstraction that unifies access to many different SDRs. This means your flow graph might also work for others with different hardware, but especially for the more complex hardware (e.g. USRPs), this means you don't get access to all the functionality of your device.


We mostly develop under Linux, and we've gotten GNU Radio to run under most current Linux distros. The best support will be for the latest supported versions of Ubuntu (their Long Term Support versions) and Fedora. Other common distros like Debian are well-maintained and will generally work fine. For Redhat and CentOS, you may find yourself needing to install some dependencies by hand. We highly recommend the use of PyBOMBS with these distros.
Hi,
I recently started using GNURadio. My initial attempts consisted of a simple flow containing an osmocom Source block, a DC Blocker block, and a QT GUI Sink block. The application works under Windows, but not under Linux (Ubuntu 20.04.4 LTS). The message in the console is listed below. Can you help me with some advice? Thank you in advance!


GNU Radio is also maintained on OS X. We have installation instructions and can help doing source builds on OS X. However, we highly recommend that you use the Macports installation of GNU Radio to make sure all of the dependencies are taken care of properly.
Generating: '/home/catalin/Documents/GNURadio/RadioFM.py'


GNU Radio will build and run under Windows. However, we don't have direct, maintained support for Windows and few of us can help you with Windows issues. We hope to have better support in the future, but in the meantime, there are plenty of people with various levels of success working under Windows that you can contact through the discuss-gnuradio Mailing List.
Executing: /usr/bin/python3 -u /home/catalin/Documents/GNURadio/RadioFM.py


GNU Radio supports both 32- and 64-bit operating systems.
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.1.0
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5


For processor support, we generally develop and build on Intel x86 architectures. These processors have the best support for features and speed. However, we are actively developing our support and capabilities on ARM processors, currently only those running the ARMv7 instruction set. Older ARM processors with ARMv6 support have been known to work, but we have no direct support for them. They tend to be severely underpowered for math and signal processing for any serious GNU Radio app. We will be developing support for ARMv8. We also have a [[Embedded|limited list of embedded devices and development kits]] that we are able to support.
RtApiAlsa::getDeviceInfo: snd_pcm_open error for device (hw:1,0), Device or resource busy.


=== What are the system requirements (minimum power, etc.)? ===
Using HackRF One with firmware 2021.03.1
Traceback (most recent call last):
  File "/home/catalin/Documents/GNURadio/RadioFM.py", line 185, in <module>
    main()
  File "/home/catalin/Documents/GNURadio/RadioFM.py", line 163, in main
    tb = top_block_cls()
  File "/home/catalin/Documents/GNURadio/RadioFM.py", line 127, in __init__
    self.connect((self.osmosdr_source_0, 0), (self.dc_blocker_xx_0, 0))
  File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 37, in wrapped
    func(self, src, src_port, dst, dst_port)
  File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 105, in connect
    self.primitive_connect(*args)
TypeError: primitive_connect(): incompatible function arguments. The following argument types are supported:
    1. (self: gnuradio.gr.gr_python.hier_block2_pb, block: gnuradio.gr.gr_python.basic_block) -> None
    2. (self: gnuradio.gr.gr_python.hier_block2_pb, src: gnuradio.gr.gr_python.basic_block, src_port: int, dst: gnuradio.gr.gr_python.basic_block, dst_port: int) -> None


GNU Radio in its core is C++ with lots of user functionality relying on [http://python.org Python]. So basically, as long as there is a feasible compiler for your platform, it '''can''' work.
Invoked with: <gnuradio.gr.gr_python.top_block_pb object at 0x7fe5957525f0>, <Swig Object of type 'gr::basic_block_sptr *' at 0x7fe5905f53f0>, 0, <gnuradio.gr.gr_python.basic_block object at 0x7fe595e22a30>, 0
swig/python detected a memory leak of type 'gr::basic_block_sptr *', no destructor found.


'''Hardware requirements''' basically depend on what you want to do. A modern PC/laptop computer is usually up to most tasks such as receiving broadcast signals, doing audio frequency processing, and many narrowband digital signals.
>>> Done (return code 1)


When dealing with telecommunication signals, however, sample rates of over 5 Msamples/s are not uncommon. The average embedded ARM platform is generally not up to that task. Even rather modern hardware often meets its limits when it comes to doing things in realtime; '''it all depends on your processing requirements''', GNU Radio is only the platform to perform these computationally intensive tasks.
Generating: '/home/catalin/Documents/GNURadio/RadioFM.py'


=== I installed GNU Radio, but some components seem to be missing. ===
Executing: /usr/bin/python3 -u /home/catalin/Documents/GNURadio/RadioFM.py


Missing components are usually seen because blocks are missing from GRC. This usually only happens when you did a source build. After running cmake, you might see something like this at the end of CMake's output (this list is heavily cropped for simplicity, it is much longer in reality):
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.1.0
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
Using HackRF One with firmware 2021.03.1
Traceback (most recent call last):
  File "/home/catalin/Documents/GNURadio/RadioFM.py", line 185, in <module>
    main()
  File "/home/catalin/Documents/GNURadio/RadioFM.py", line 163, in main
    tb = top_block_cls()
  File "/home/catalin/Documents/GNURadio/RadioFM.py", line 127, in __init__
    self.connect((self.osmosdr_source_0, 0), (self.dc_blocker_xx_0, 0))
  File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 37, in wrapped
    func(self, src, src_port, dst, dst_port)
  File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 105, in connect
    self.primitive_connect(*args)
TypeError: primitive_connect(): incompatible function arguments. The following argument types are supported:
    1. (self: gnuradio.gr.gr_python.hier_block2_pb, block: gnuradio.gr.gr_python.basic_block) -> None
    2. (self: gnuradio.gr.gr_python.hier_block2_pb, src: gnuradio.gr.gr_python.basic_block, src_port: int, dst: gnuradio.gr.gr_python.basic_block, dst_port: int) -> None


<pre>-- ######################################################
Invoked with: <gnuradio.gr.gr_python.top_block_pb object at 0x7f9073d0f430>, <Swig Object of type 'gr::basic_block_sptr *' at 0x7f90710f13f0>, 0, <gnuradio.gr.gr_python.basic_block object at 0x7f9073d2d4f0>, 0
-- # Gnuradio enabled components                       
swig/python detected a memory leak of type 'gr::basic_block_sptr *', no destructor found.
-- ######################################################
--  * python-support
--  * testing-support
--  * volk
--  * doxygen
--  * gnuradio-runtime
--  * gr-blocks
--  * gnuradio-companion
--  * gr-fec
--  * gr-fft
--  * gr-filter
--  * [...]
--
-- ######################################################
-- # Gnuradio disabled components                       
-- ######################################################
--  * gr-ctrlport
--  * gr-dtv
--  * gr-atsc
--  * gr-wxgui</pre>
If the components you are missing are listed under the 'disabled' components, there's your problem.<br />
There are two reasons why components are disabled:<br />
- You disabled them yourself, e.g. by supplying a `-DENABLE_GR_DTV=OFF` switch to CMake.<br />
- The component was automatically enabled because CMake could not find certain dependencies.


In both cases, you can read the CMake output to see what the reason is. If dependencies are missing, you might have to install developer packages for something (on Debian and Ubuntu systems, these are packages ending with -dev, on Fedora, they end with -devel). Consult the build manual for which dependencies are required.
>>> Done (return code 1)


If you don't understand or know how to do this, consider installing precompiled binaries. Usually, they will pull in all the required dependencies.
== RTL-SDR issues ==


=== Which Radio Hardware is supported? ===
Hi,


There is a growing list of radio front ends for software radio uses. It is difficult to keep up with, and support for a particular radio front end in GNU Radio is generally left to the hardware manufacturer. The Ettus Research USRP product line, supported by UHD, is the exception since the USRP and GNU Radio have had a long history of developing and working together. See also [[Hardware]].
I am using Ubuntu 20.04, gnuradio 3.10. I am having trouble getting gnuradio to recognize my RTL-SDR. When I add the RTL-SDR source block in gnuradio I am given the option to add a device argument but I don’t know what to put into this section so that gnuradio recognizes my device.  


=== Can you suggest any reading material for DSP/SDR/Digital Comms? ===
Any help is much appreciated.


We have a wiki page for this: [[SuggestedReading]]
Thanks!
 
<!-- Marker section 2 -->
== Using GNU Radio ==
 
=== How do I start? What's the first thing to do after installation? ===
 
Start with our [[Tutorials]] to learn your way around GNU Radio. They are divided into levels of user experience.
 
=== Where can I find a list of GNU Radio blocks? ===
 
All GNU Radio blocks are listed in [https://wiki.gnuradio.org/index.php/Category:Block_Docs Block Docs]. When using GNU Radio Companion, blocks are also listed in the ''Block Tree'' sidebar. You can use the search feature of GNU Radio Companion (a magnifying glass) to find blocks by name.
 
=== What does ''sample rate'' mean in GNU Radio? ===
 
First off: You need to understand the general principle of "Sampling Rate" and the sampling theorem before you do anything with GNU Radio. See [[SuggestedReading]].
 
For a tutorial on sample rate, see [[Sample_Rate_Tutorial]].
 
=== My flowgraph is too slow. What can I do to make it faster? My hardware signals underflows, overflows or dropped samples. ===
 
The most common answer to that question is: It's as fast as it ''can'' run. If your signal processing application really needs that much computing, you need more computational power.
 
There are, however, some cases where your problems can be helped:
 
# If your signal processing relies on a bandwidth that is substantially smaller than your nyquist bandwidth (in case of complex sampling: sampling rate, in case of real sampling: 0.5 * sampling rate) use a lower sampling rate as early as possible. Often, you could also tell your hardware to produce a lower sample rate.
# If your signal processing could as well be done offline (instead of in realtime), write your signal to file (using file_sink) and load it from there in another flowgraph (using file_source)
 
=== When do I use a throttle block? ===
 
GNU Radio is written and designed for real-time streaming signal processing that interfaces with real hardware systems. A GNU Radio application attempts to source data from a hardware source and sink data to a hardware sink as quickly as possible. That means that we are rate limited by the hardware, which will either provide or allow us to push data between GNU Radio and the hardware system based on the rate of the hardware.
 
For other cases, see [[Sample_Rate_Tutorial#When_there_is_no_hardware_block]].
 
=== What is the file format of a file_sink? How can I read files produced by a file sink? ===
 
All files are in pure binary format. Just bits. That's it. A floating point data stream is saved as 32 bits in the file, one after the other. A complex signal has 32 bits for the real part and 32 bits for the imaginary part. Reading back a complex number means reading in 32 bits, saving that to the real part of a complex data structure, and then reading in the next 32 bits as the imaginary part of the data structure. And just keep reading the data.
 
Take a look at the Octave and Python files in gr-utils for reading data using Octave and Python's Scipy module.
 
The exception to the format is when using the metadata file format. These files are produced by the <code>File Meta Sink</code>: http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1file_''meta''_sink.html block and read by the [http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1file__meta__source.html File Meta Source] block. See the manual page on the [http://gnuradio.org/doc/doxygen/page_metadata.html metadata file format] for more information about how to deal with these files.
 
A one-line Python command to read the entire file into a numpy array is:
 
f = scipy.fromfile(open("filename"), dtype=scipy.uint8)
 
Replace the dtype with <code>scipy.int16</code>, <code>scipy.int32</code>, <code>scipy.float32</code>, <code>scipy.complex64</code> or whatever type you were using.
 
<!-- Marker section 3 -->
== GNU Radio Companion ==
 
For a tutorial on GRC, see [[Guided_Tutorial_GRC]].
 
=== How do I change the canvas size? ===
 
It's in the 'Options' block of your flow graph. The dimensions are in pixels, e.g. canvas (1536,1024)
 
=== How do I make the text larger on a HiDPI display like a Retina MacBook? ===
 
Please see [[Tips for MacBooks and other HiDPI displays]].

Latest revision as of 18:13, 15 October 2022

NOTE: This page is not a support forum.

Future Edits: Hardware support

After inclusion of gr-soapy in an official release, as well as gr-iio: Needs to state something like


Does GNU Radio support my SDR hardware?

If you've got a

  • Ettus / National Instruments USRP: yes, through the included `gr-uhd` module (use the `USRP Sink` / `USRP Source`)
  • a IIO device like the ADALM Pluto SDR: yes, through the included `gr-iio` module (GNU Radio version 3.x.y.z upwards)
  • Any other device (e.g. RTL-SDR dongles): if there's a soapysdr plugin [Link to Soapysdr] for it, then it can be used through gr-soapy (GNU Radio version 3.a.b.c upwards)

Generally, gr-soapy is an abstraction that unifies access to many different SDRs. This means your flow graph might also work for others with different hardware, but especially for the more complex hardware (e.g. USRPs), this means you don't get access to all the functionality of your device.

Hi, I recently started using GNURadio. My initial attempts consisted of a simple flow containing an osmocom Source block, a DC Blocker block, and a QT GUI Sink block. The application works under Windows, but not under Linux (Ubuntu 20.04.4 LTS). The message in the console is listed below. Can you help me with some advice? Thank you in advance!

Generating: '/home/catalin/Documents/GNURadio/RadioFM.py'

Executing: /usr/bin/python3 -u /home/catalin/Documents/GNURadio/RadioFM.py

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.1.0 built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp [INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5

RtApiAlsa::getDeviceInfo: snd_pcm_open error for device (hw:1,0), Device or resource busy.

Using HackRF One with firmware 2021.03.1 Traceback (most recent call last): 

 File "/home/catalin/Documents/GNURadio/RadioFM.py", line 185, in <module>
   main()
 File "/home/catalin/Documents/GNURadio/RadioFM.py", line 163, in main
   tb = top_block_cls()
 File "/home/catalin/Documents/GNURadio/RadioFM.py", line 127, in __init__
   self.connect((self.osmosdr_source_0, 0), (self.dc_blocker_xx_0, 0))
 File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 37, in wrapped
   func(self, src, src_port, dst, dst_port)
 File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 105, in connect
   self.primitive_connect(*args)

TypeError: primitive_connect(): incompatible function arguments. The following argument types are supported: 

   1. (self: gnuradio.gr.gr_python.hier_block2_pb, block: gnuradio.gr.gr_python.basic_block) -> None
   2. (self: gnuradio.gr.gr_python.hier_block2_pb, src: gnuradio.gr.gr_python.basic_block, src_port: int, dst: gnuradio.gr.gr_python.basic_block, dst_port: int) -> None

Invoked with: <gnuradio.gr.gr_python.top_block_pb object at 0x7fe5957525f0>, <Swig Object of type 'gr::basic_block_sptr *' at 0x7fe5905f53f0>, 0, <gnuradio.gr.gr_python.basic_block object at 0x7fe595e22a30>, 0 swig/python detected a memory leak of type 'gr::basic_block_sptr *', no destructor found.

>>> Done (return code 1)

Generating: '/home/catalin/Documents/GNURadio/RadioFM.py'

Executing: /usr/bin/python3 -u /home/catalin/Documents/GNURadio/RadioFM.py

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.1.0 built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp Using HackRF One with firmware 2021.03.1 Traceback (most recent call last): 

 File "/home/catalin/Documents/GNURadio/RadioFM.py", line 185, in <module>
   main()
 File "/home/catalin/Documents/GNURadio/RadioFM.py", line 163, in main
   tb = top_block_cls()
 File "/home/catalin/Documents/GNURadio/RadioFM.py", line 127, in __init__
   self.connect((self.osmosdr_source_0, 0), (self.dc_blocker_xx_0, 0))
 File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 37, in wrapped
   func(self, src, src_port, dst, dst_port)
 File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 105, in connect
   self.primitive_connect(*args)

TypeError: primitive_connect(): incompatible function arguments. The following argument types are supported: 

   1. (self: gnuradio.gr.gr_python.hier_block2_pb, block: gnuradio.gr.gr_python.basic_block) -> None
   2. (self: gnuradio.gr.gr_python.hier_block2_pb, src: gnuradio.gr.gr_python.basic_block, src_port: int, dst: gnuradio.gr.gr_python.basic_block, dst_port: int) -> None

Invoked with: <gnuradio.gr.gr_python.top_block_pb object at 0x7f9073d0f430>, <Swig Object of type 'gr::basic_block_sptr *' at 0x7f90710f13f0>, 0, <gnuradio.gr.gr_python.basic_block object at 0x7f9073d2d4f0>, 0 swig/python detected a memory leak of type 'gr::basic_block_sptr *', no destructor found.

>>> Done (return code 1)

RTL-SDR issues

Hi,

I am using Ubuntu 20.04, gnuradio 3.10. I am having trouble getting gnuradio to recognize my RTL-SDR. When I add the RTL-SDR source block in gnuradio I am given the option to add a device argument but I don’t know what to put into this section so that gnuradio recognizes my device.

Any help is much appreciated.

Thanks!

Retrieved from "https://wiki.gnuradio.org/index.php?title=Talk:FAQ&oldid=12619"