Re: Version compatibility problem
Hi Luke, though I like that guide, I'd **really** recommend not building GNU Radio from source on Ubuntu 19.10, unless you really need to (for example, and that's why Ettus has such a guide, because you're using a different UHD than what is available from Ubuntu). On Ubuntu 19.10, it's really really really simple to get running GNU Radio 3.8: sudo add-apt-repository ppa:gnuradio/gnuradio-releases sudo apt-get update sudo apt install gnuradio Done. Hi Laura, that's a manual installation outside your prefix; I think you really might have had multiple GNU Radio 3.8 installations. Yeah, so honestly, re-installing Ubuntu and using the method I described above instead of trying to fix this (which definitely is possible, but not much fun) is the faster way. Best regards, Marcus On Wed, 2020-02-12 at 23:53 +, Luke Stutters wrote: > Dear Laura, > > If you need to build and run GNU Radio 3.8 on a recent Linux kernel > and not just install it from packages, you may find the following > notes useful: > https://docs.google.com/document/d/17gbDc_l32wbNIrXopUWIr1pOpu_Ty8tTeC4t12Ah_XE/edit?usp=sharing > > This is just a simplified version of the guide on the Ettus wiki, but > for Ubuntu 19.10: > https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux > > I was going to add it to the GNU Radio wiki but it does some things > that are unsuitable for a lot of systems, like installing self- > compiled software in /usr instead of /usr/local and patching numpy > in-place to work round Python 3.7 changes. > > However, the simpler approach avoided Python and C++ environment- > related issues for me, and I just needed to test something quickly. > > Best wishes, > > On Wed, 12 Feb 2020 at 23:07, Laura Arjona wrote: > > sorry, typed it wrong > > ~$ which gnradio-config-info > > /usr/local/bin/gnuradio-config-info > > > > On Wed, Feb 12, 2020 at 3:03 PM Laura Arjona > > wrote: > > > Thank you Marcus. > > > > > > I think I am going to install ubuntu again, since I really need > > > to have gnuradio working asap. > > > > > > It says nothing > > > ~$ which gnradio-config-info > > > > > > :~$ gnuradio-config-info --version > > > 3.8.0.0 > > > > > > On Wed, Feb 12, 2020 at 2:42 PM Müller, Marcus (CEL) < > > > muel...@kit.edu> wrote: > > > > huh. Seems to be more than one installation in the prefix?! > > > > what does `which gnuradio-config-info` say? > > > > > > > > > > > > On Wed, 2020-02-12 at 13:52 -0800, Laura Arjona wrote: > > > > > Thank you, > > > > > > > > > > I got rid of all the folders named gnuradio, and it seems to > > > > be > > > > > uninstalled, because when I run uninstall I get Package > > > > 'gnuradio' > > > > > is not installed, so not removed > > > > > > > > > > But I still get > > > > > # gnuradio-config-info --version > > > > > 3.8.0.0 > > > > > > > > > > > > > > > > > > > > On Wed, Feb 12, 2020 at 12:47 PM Müller, Marcus (CEL) < > > > > > muel...@kit.edu> wrote: > > > > > > Hi Laura, > > > > > > > > > > > > first of all, unless you really want to work *on* GNU > > > > Radio, > > > > > > there's > > > > > > little reason to install it using PyBOMBS. At the very > > > > least, on > > > > > > Debian > > > > > > testing, there's native GNU Radio 3.8 packages, and for > > > > Fedora and > > > > > > Ubuntu, GNU Radio has binary packages that you can just > > > > install and > > > > > > use > > > > > > to develop your out-of-tree modules and GNU Radio > > > > applications. > > > > > > > > > > > > However, PyBOMBS will have installed GNU Radio 3.8 into the > > > > prefix > > > > > > ~/gnuradio. So, if you just move that out of the way, or > > > > delete it, > > > > > > then you should have no access to GNU Radio 3.8.0.0 > > > > anymore. > > > > > > > > > > > > Best regards, > > > > > > Marcus > > > > > > > > > > > > On Wed, 2020-02-12 at 12:12 -0800, Laura Arjona wrote: > > > > > > > Good morning, > > > > > > > > > > > > > > In short, I installed gnuradio 3.8 following the > > > > tutorial in the > > > > > > github site > > > > > > > sudo -H pip3 install PyBOMBS > > > > > > > pybombs auto-config > > > > > > > pybombs recipes add-defaults > > > > > > > pybombs prefix init ~/gnuradio -R gnuradio-default > > > > > > > > > > > > > > but I got problems with the python path, then removed > > > > gnuradio, > > > > > > and re-installed the version 3.7. > > > > > > > > > > > > > > But when I check the version with gnuradio-config-info -- > > > > version > > > > > > > I still get version 3.8.0. > > > > > > > > > > > > > > Because of the version I have other eros when building my > > > > oot- > > > > > > modules. > > > > > > > > > > > > > > > > > > > > > Any advice there? > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Laura Arjona > > > Washington Research Foundation Innovation Postdoctoral Fellow in > > > Neuroengineering > > > > > > Paul G. Allen School of Compu
Re: GNURadio Leaking memory during repeated simulations
Hi, huh. That looks hard to debug; also, the slow down is suspicious (as long as there's memory available, it shouldn't take significantly longer to get some – usually, memory fragmentation isn't *that* bad, and this shouldn't be doing *that* much memory allocation). Could you put all your code in one .py file (or a set of these) that one can simply execute right away? That would allow us to reproduce. Also, could you tell us your specific GNU Radio version (all four digits of it?). Best regards, Marcus On Tue, 2020-02-11 at 16:34 -0800, Roman A Sandler wrote: > Hi, > > I am using GNURadio to decode a large amount of 1024-sample complex > vectors of different modulation schemes. Thus, I have a for loop > which runs gr.top_block.run() at each iteration and uses a vector > sink to collect the results. The issue is that as the simulation > keeps going, each itertion takes longer (e.g. starts of at 120it/sec, > and then after 5000 iterations slows down to 10it/sec). I can see in > task manager (I am on windows) that memory is increasing so clearly > there is a memory leak where somehow the results of the iterations > arent being deleted. > > Is there an explicit way to delete runs or is this a bug? > > CODE: > > calling code: > ``` > for _ in range(1): > decode(sig) > ``` > > decode func: > ``` > def decode(channel_sigs): > tb = gr.top_block() > > ## > # Variables > ## > nfilts = 32 > sps = 4 > timing_loop_bw = 3 * 6.28 / 100.0 # NOTE: this controls > convergence speed! > constellation_scheme, bps = get_constellation_scheme(scheme) > rrc_taps = firdes.root_raised_cosine(nfilts, nfilts, 1.0 / > float(sps), 0.35, 11 * sps * nfilts) > phase_bw = 6.28 / 100.0 > eq_gain = 0.01 > arity = 4 > > Actual blocks > channel_src = blocks.vector_source_c(channel_sigs, False) > digital_pfb_clock_sync = digital.pfb_clock_sync_ccf(sps, > timing_loop_bw, rrc_taps, nfilts, > nfilts / 2, > 1.5, 1) > constellation_soft_decoder = > digital.constellation_soft_decoder_cf(constellation_scheme) > binary_slicer = digital.binary_slicer_fb() > blocks_char_to_float = blocks.char_to_float(1, 1) > recovered_bits_dst = blocks.vector_sink_f() > > ## > # Connections > ## > tb.connect((channel_src, 0), (digital_pfb_clock_sync, 0)) > tb.connect((digital_pfb_clock_sync, 0), > (constellation_soft_decoder, 0)) > tb.connect((constellation_soft_decoder, 0), (binary_slicer, 0)) > tb.connect((binary_slicer, 0), (blocks_char_to_float, 0)) > tb.connect((blocks_char_to_float, 0), (recovered_bits_dst, 0)) > > tb.run() > > recovered_bits = np.array(recovered_bits_dst.data()) > return recovered_bits > ``` smime.p7s Description: S/MIME cryptographic signature
example pfb_sync_test
Hi when i try to run the example i get this error ControlPort Monitor running. python3: /build/gnuradio-6i8Hb6/gnuradio-3.8.0.0~gnuradio~bionic/gnuradio-runtime/lib/controlport/rpcmanager.cc:38: static rpcserver_booter_base* rpcmanager::get(): Assertion `booter_registered || aggregator_registered' failed.
Re: example pfb_sync_test
Can you provide us with a little more info here, and that we can try to replicate your issue: * Is the OS "Ubuntu 18.04.3 LTS (Bionic Beaver)" ... or something else? * Are you trying to use the GNU Radio 3.8.0.0 release? * How did you install GR? * what version of Thrift is installed, and how did you install it? On Thu, Feb 13, 2020 at 9:04 AM sarandis. Doulgeris < sarandis.doulge...@gmail.com> wrote: > Hi when i try to run the example i get this error > > ControlPort Monitor running. > python3: > /build/gnuradio-6i8Hb6/gnuradio-3.8.0.0~gnuradio~bionic/gnuradio-runtime/lib/controlport/rpcmanager.cc:38: > static rpcserver_booter_base* rpcmanager::get(): Assertion > `booter_registered || aggregator_registered' failed. > -- Michael Dickens Ettus Research Technical Support Email: supp...@ettus.com Web: https://ettus.com/
Re: GNURadio Leaking memory during repeated simulations
Hi Marcus, Thanks for the reply! My GNURadio version: *3.8.0.0 (Python 2.7.10)* It is the Windows 3.8.0.0 version downloaded from: http://www.gcndevelopment.com/gnuradio/downloads.htm Complete reproducible code is below. I use the tqdm package to monitor iterations per second. On my PC, the it/sec declines very precipitously (starts at 85it/sec, then down to 22it/s after 40s and keeps dropping. Eventually as low as 1 it/sec). ``` import numpy as np from gnuradio import gr, gr_unittest from gnuradio import blocks from gnuradio import digital from gnuradio.filter import firdes from gnuradio import channels from tqdm import tqdm def decode(channel_sigs): tb = gr.top_block() ## # Variables ## nfilts = 32 sps = 4 timing_loop_bw = 3 * 6.28 / 100.0 # NOTE: this controls convergence speed! constellation_scheme = digital.constellation_8psk().base() rrc_taps = firdes.root_raised_cosine(nfilts, nfilts, 1.0 / float(sps), 0.35, 11 * sps * nfilts) Actual blocks channel_src = blocks.vector_source_c(channel_sigs, False) digital_pfb_clock_sync = digital.pfb_clock_sync_ccf(sps, timing_loop_bw, rrc_taps, nfilts, nfilts / 2, 1.5, 1) constellation_soft_decoder = digital.constellation_soft_decoder_cf(constellation_scheme) binary_slicer = digital.binary_slicer_fb() blocks_char_to_float = blocks.char_to_float(1, 1) recovered_bits_dst = blocks.vector_sink_f() ## # Connections ## tb.connect((channel_src, 0), (digital_pfb_clock_sync, 0)) tb.connect((digital_pfb_clock_sync, 0), (constellation_soft_decoder, 0)) tb.connect((constellation_soft_decoder, 0), (binary_slicer, 0)) tb.connect((binary_slicer, 0), (blocks_char_to_float, 0)) tb.connect((blocks_char_to_float, 0), (recovered_bits_dst, 0)) tb.run() recovered_bits = np.array(recovered_bits_dst.data()) return recovered_bits if __name__ == '__main__': n_trls = 1 n_samples = sig = np.random.normal(size=(n_samples,)) + 1j * np.random.normal(size=(n_samples,)) for n in tqdm(range(n_trls)): decode(sig) ``` On Thu, Feb 13, 2020 at 2:11 AM Müller, Marcus (CEL) wrote: > Hi, > > huh. That looks hard to debug; also, the slow down is suspicious (as > long as there's memory available, it shouldn't take significantly > longer to get some – usually, memory fragmentation isn't *that* bad, > and this shouldn't be doing *that* much memory allocation). > > Could you put all your code in one .py file (or a set of these) that > one can simply execute right away? That would allow us to reproduce. > Also, could you tell us your specific GNU Radio version (all four > digits of it?). > > Best regards, > Marcus > > On Tue, 2020-02-11 at 16:34 -0800, Roman A Sandler wrote: > > Hi, > > > > I am using GNURadio to decode a large amount of 1024-sample complex > > vectors of different modulation schemes. Thus, I have a for loop > > which runs gr.top_block.run() at each iteration and uses a vector > > sink to collect the results. The issue is that as the simulation > > keeps going, each itertion takes longer (e.g. starts of at 120it/sec, > > and then after 5000 iterations slows down to 10it/sec). I can see in > > task manager (I am on windows) that memory is increasing so clearly > > there is a memory leak where somehow the results of the iterations > > arent being deleted. > > > > Is there an explicit way to delete runs or is this a bug? > > > > CODE: > > > > calling code: > > ``` > > for _ in range(1): > > decode(sig) > > ``` > > > > decode func: > > ``` > > def decode(channel_sigs): > > tb = gr.top_block() > > > > ## > > # Variables > > ## > > nfilts = 32 > > sps = 4 > > timing_loop_bw = 3 * 6.28 / 100.0 # NOTE: this controls > > convergence speed! > > constellation_scheme, bps = get_constellation_scheme(scheme) > > rrc_taps = firdes.root_raised_cosine(nfilts, nfilts, 1.0 / > > float(sps), 0.35, 11 * sps * nfilts) > > phase_bw = 6.28 / 100.0 > > eq_gain = 0.01 > > arity = 4 > > > > Actual blocks > > channel_src = blocks.vector_source_c(channel_sigs, False) > > digital_pfb_clock_sync = digital.pfb_clock_sync_ccf(sps, > > timing_loop_bw, rrc_taps, nfilts, > > nfilts / 2, > > 1.5, 1) > > constellation_soft_decoder = > > digital.constellation_soft_decoder_cf(constellation_scheme) > > binary_slicer = digital.binary_slicer_fb() > > blocks_char_to_float = blocks.char_to_float(1, 1) > > recovered_bits_dst = blocks.vector_sink_f() > > > > #
Re: Version compatibility problem
On Wed, 12 Feb 2020 15:04:49 -0800 Laura Arjona wrote: > sorry, typed it wrong > ~$ which gnradio-config-info > /usr/local/bin/gnuradio-config-info In which case you have built and installed gnuradio in the /usr/local prefix by hand, not as a package you can install and uninstall using your distribution's package manager. You should be able to go through /usr/local and delete anything gnuradio related. Then install your distribution's binary package of gnuradio using its package manager. Unless you are a person who likes to do their own compiling, there shouldn't be much in /usr/local. Chris
Re: GNURadio Leaking memory during repeated simulations
Roman, I was able to run your code, and got a consistent 150-160 it/s through the whole run, with about 65MB of memory in use (as reporting by Task Manager). This was on Windows 10 running GR 3.8.0.0. I noticed there was another package installed (tqdm) that's not part of the GR install. So I want to confirm... did you add that package to the python that installed as part of GR, or are you using a different python? If you are using a different python install, a possible explanation is compilers; the GR packages and binaries are all built with VS 2015, but the py2.7 standard is VS 2008 (which won't build GR any more), and mixing (VS) compilers can cause odd issues. So for GR, the entire python 2.7 and every package is built from scratch w/ 2015. tqdm doesn't seem to be affected, I added that to the GR python install using a pip install, nothing fancy, and it seems to have worked. If you are, however, running the script with the GR-installed python after opening with run_gr.bat, then I'm scratching my head what's happening. Geof On Thu, Feb 13, 2020 at 12:00 PM Roman A Sandler wrote: > Hi Marcus, > > Thanks for the reply! > > My GNURadio version: *3.8.0.0 (Python 2.7.10)* > It is the Windows 3.8.0.0 version downloaded from: > http://www.gcndevelopment.com/gnuradio/downloads.htm > > Complete reproducible code is below. I use the tqdm package to monitor > iterations per second. On my PC, the it/sec declines very precipitously > (starts at 85it/sec, then down to 22it/s after 40s and keeps dropping. > Eventually as low as 1 it/sec). > > > ``` > > import numpy as np > from gnuradio import gr, gr_unittest > from gnuradio import blocks > from gnuradio import digital > from gnuradio.filter import firdes > from gnuradio import channels > from tqdm import tqdm > > > def decode(channel_sigs): > tb = gr.top_block() > > ## > # Variables > ## > nfilts = 32 > sps = 4 > timing_loop_bw = 3 * 6.28 / 100.0 # NOTE: this controls convergence > speed! > constellation_scheme = digital.constellation_8psk().base() > rrc_taps = firdes.root_raised_cosine(nfilts, nfilts, 1.0 / float(sps), > 0.35, 11 * sps * nfilts) > > Actual blocks > channel_src = blocks.vector_source_c(channel_sigs, False) > digital_pfb_clock_sync = digital.pfb_clock_sync_ccf(sps, timing_loop_bw, > rrc_taps, nfilts, > nfilts / 2, 1.5, 1) > constellation_soft_decoder = > digital.constellation_soft_decoder_cf(constellation_scheme) > binary_slicer = digital.binary_slicer_fb() > blocks_char_to_float = blocks.char_to_float(1, 1) > recovered_bits_dst = blocks.vector_sink_f() > > ## > # Connections > ## > tb.connect((channel_src, 0), (digital_pfb_clock_sync, 0)) > tb.connect((digital_pfb_clock_sync, 0), (constellation_soft_decoder, 0)) > tb.connect((constellation_soft_decoder, 0), (binary_slicer, 0)) > tb.connect((binary_slicer, 0), (blocks_char_to_float, 0)) > tb.connect((blocks_char_to_float, 0), (recovered_bits_dst, 0)) > > tb.run() > recovered_bits = np.array(recovered_bits_dst.data()) > > return recovered_bits > > > if __name__ == '__main__': > n_trls = 1 > n_samples = > sig = np.random.normal(size=(n_samples,)) + 1j * > np.random.normal(size=(n_samples,)) > > for n in tqdm(range(n_trls)): > decode(sig) > > ``` > > > On Thu, Feb 13, 2020 at 2:11 AM Müller, Marcus (CEL) > wrote: > >> Hi, >> >> huh. That looks hard to debug; also, the slow down is suspicious (as >> long as there's memory available, it shouldn't take significantly >> longer to get some – usually, memory fragmentation isn't *that* bad, >> and this shouldn't be doing *that* much memory allocation). >> >> Could you put all your code in one .py file (or a set of these) that >> one can simply execute right away? That would allow us to reproduce. >> Also, could you tell us your specific GNU Radio version (all four >> digits of it?). >> >> Best regards, >> Marcus >> >> On Tue, 2020-02-11 at 16:34 -0800, Roman A Sandler wrote: >> > Hi, >> > >> > I am using GNURadio to decode a large amount of 1024-sample complex >> > vectors of different modulation schemes. Thus, I have a for loop >> > which runs gr.top_block.run() at each iteration and uses a vector >> > sink to collect the results. The issue is that as the simulation >> > keeps going, each itertion takes longer (e.g. starts of at 120it/sec, >> > and then after 5000 iterations slows down to 10it/sec). I can see in >> > task manager (I am on windows) that memory is increasing so clearly >> > there is a memory leak where somehow the results of the iterations >> > arent being deleted. >> > >> > Is there an explicit way to delete runs or is this a bug? >> > >>
Relink error starting gnuradio
I can't start gnuradio $ gnuradio-companion /usr/bin/python3: Relink `/lib/x86_64-linux-gnu/libmount.so.1' with `/lib/x86_64-linux-gnu/librt.so.1' for IFUNC symbol `clock_gettime' Segmentation fault (core dumped) I installed it like this: sudo add-apt-repository ppa:gnuradio/gnuradio-releases sudo apt-get update sudo apt install gnuradio My environment: $ whereis gnuradio-companion gnuradio-companion: /usr/bin/gnuradio-companion /usr/share/man/man1/gnuradio-companion.1.gz 18.04.4 LTS (Bionic Beaver) USRP B210 radio transceiver History: I originally installed gnuradio from package repo. Then I built it from source. Then I also built it with pybombs. It worked fine until I uninstalled everything and tried to install it with the package ppa. I suspect it's not technically a gnuradio problem, but it's manifesting there through python3. Any idea how to clean this up? I'm not experienced with python. Roger
GSoC 2020 Introduction
Hi everyone! I'm Akhil, a second year undergrad in computer engineering at AIT Pune, India.I wish to participate in GSoC this year under your organization. I'm afraid I'm completely new to GNU Radio however reading your wiki I feel that this community is pretty welcoming and it seems like an organization I would enjoy working with this year. As I mentioned I have no experience with GNU Radio however I'm going through the tutorials in the wiki now and am quite willing to learn whatever I need to help contribute. I'm familiar with programming in C++ as well as Python and have worked a little on Qt so the Qt5 GUI Integrations idea seems like a good fit for me. I'd appreciate it if the mentors could guide me in any way to any code/information related to the project. Working on anything related to the project or even a partial implementation of the idea would help me grasp what is required for the project and what I'm expected to implement. Last of all, this being a Qt related project I'm assuming there's not much theory I should be familiar with, however if there is I'd be glad if you could tell me what to learn. Thanks and Regards, Akhil Nair
