Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'block_name'
Hi,
I have individuated the error and we are near the solution, thanks to all.
I just remember the error that appear when I try to run a simulation of my
new block "power":
Traceback (most recent call last):
File "/home/simone/Scrivania/top_block.py", line 228, in
tb = top_block()
File "/home/simone/Scrivania/top_block.py", line 71, in __init__
self.t1_power_0 = t1.power(0.001, 0.5)
AttributeError: 'module' object has no attribute 'power'
I tried my block just eliminating the use of the class function
gr::uhd::usrp_source and it works.
So, the error is in the way in which I define and call a new USRP source
block.
/*** INSTRUCTION
/
This is my creation of the new UHD object in the _impl.cc file of my new
written block
::uhd::device_addr_t addr;
gr::uhd::usrp_source::sptr my_usrp_source =
gr::uhd::usrp_source::make(addr, ::uhd::stream_args_t("fc32"));
and then I use this function
DB_gain = (float) my_usrp_source->get_gain(0);
/**/
I have some questions:
consider the flowgraph attached in this mail,
first of all, I'm using an usrp (UHD: USRP SOURCE block) with a fixed ip
address (addr=192.168.10.2), and I set "sudo ifconfig eth0 192.168.10.1"
and get "addr 192.168.10.2" to setup the device.
In the same flowgraph, in my created block (my _impl.cc) now I'm creating
another USRP source block and I don't understand which address I need to
use to set correctly the make function (see instruction above) for
modifying parameters of the same USRP that is working, the USRP with
address 192.168.10.2.
In my code I set addr=192.168.10.2
Second, this definition:
gr::uhd::usrp_source::sptr my_usrp_source =
gr::uhd::usrp_source::make(addr, ::uhd::stream_args_t("fc32"));
is sufficient to put it into the general work and no other places to use
this class??? The compilare does not advice me that there is an error, but
my definition for class usage is not clear and wrong and then I get error
in simulation...
Anyway, is well appreciated if someone can show me the correct way to
define and use function of other classes into a new created block!
On Mon, 8 Sep 2014 09:48:32 -0400, Tom Rondeau wrote:
> On Wed, Sep 3, 2014 at 9:57 AM, Simone Ciccia S210664 <
> simone.cic...@studenti.polito.it> wrote:
>
>> Very thanks for the immediate answer,
>>
>> Sorry, I forgot that I passed two arguments when the block was created:
>>
>> $insert valid arguments: float reference, float alpha
>>
>> while "unsigned int d_counter" is a normal variable initialized in the
>> constructor.
>>
>> now, in the file power_control_impl.h (in short) I added the variables:
>>
>> class power_control_impl : public power_control
>> {
>> private:
>> float d_alpha, d_ref;
>> unsigned int d_counter;
>>
>>
>> and then, in the constructor of the file power_control_impl.cc (in
short)
>> I
>> used the settler:
>>
>> power_control_impl::power_control_impl(float alpha, float reference)
>> : gr::block("power_control",gr::io_signature::make2(2, 2,
>> sizeof(float), sizeof(float)),
>> gr::io_signature::make(1, 1, sizeof(float))),
>> d_alpha(alpha),
>> d_ref(reference)
>> {
>> d_counter=0
>> }
>>
>>
>> the xml file (in short) I think is ok:
>>
>> PWagc.power_control($alpha, $reference)
>>
>> Alpha
>> alpha
>> float
>>
>>
>> Reference
>> reference
>> float
>>
>>
>>
>> is there something in the wrong place?
>> thanks for the help!
>> Simone
>
>
> Yeah, I figured there were two arguments. I just put them as x and y.
>
> One thing that can happen here is if there's a declared function in the
> public and/or private header that's not implemented in the .cc file. You
> might have something like that going on, such as not having or deleting
the
> destructor. Using gr_modtool should protect you from things like this,
and
> testing it out on my end here worked fine. Just double-check your work to
> make sure you didn't remove anything you shouldn't have.
>
> Tom
>
>
>
>
>> On Wed, 3 Sep 2014 09:35:35 -0400, Tom Rondeau wrote:
>> > On Wed, Sep 3, 2014 at 9:17 AM, Simone Ciccia S210664 <
>> > simone.cic...@studenti.polito.it> wrote:
>> >
>> >> Hi,
>> >> I created a C++ block with gr_modtool,
>> >> following the commands:
>> >>
>> >> $ gr_modtool newmod PWagc
>> >> $ gr_modtool add -t general power_control
>> >>
>> >> I written and compiled my block with commands:
>> >>
>> >> $cmake ../ && make && sudo make install && sudo ldconfig
>> >>
>> >> Until this point all seems ok, but when I open gnuradio and try to
>> >> simulate
>> >> my block...
>> >> the following error appears:
>> >>
>> >> Traceback (most recent call last):
>> >> File "/home/simone/Scrivania/top_block.py", line 261, in
>> >>
Re: [Discuss-gnuradio] [USRP-users] USRP 2920 doesn't work properly at UHD3.7.2 V.
Did you only update GNU Radio? Can you post some error message so we can help you? M On 09/10/2014 11:26 AM, Taner Tekin via USRP-users wrote: > Hi all, > > I've installed this software gnuradio.v:3.7.5 on ubuntu. I am the > owner of the device USRP2920. There wasn't gnuradio applications. I > UHD USRP applications in version 3.5.4 gnuradio 'could also run > smoothly. But, gnuradio on USRP 't does not work, now. I need to > install the new image version has changed? There USRP images on > devices. Because in the old version works fine. (UHD 3.5.4) What > should I do, I do not understand.:( Thank you in advance for your > interest. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Editing medium-to-large flow-graphs in GRC now *agonizing* slow
On Tue, Sep 9, 2014 at 8:25 PM, Marcus D. Leech wrote: > On 09/09/2014 08:20 PM, Tiankun Hu wrote: > >> Yes, I have the same issue with v3.7.5 >> >> >> >> Thanks >> Tiankun >> >> Mike Jameson 编写： >> >> Yes, even after a fresh reboot there is still a delayed reaction while >> dragging about blocks in GRC. >> >> GNU Radio Companion 3.7.5git-194-g76a271ac >> Ubuntu 14.04 x64 LTS >> Quad Core i7 >> >> Mike >> >> To be sure, there has always been a certain amount of sluggishness with > large flow-graphs (simple_ra, for an example), but what I'm seeing > now is probably 3 or 4 times worse, and affects smaller/less-complicated > graphs as well. I do realize that GRC is doing a lot of dynamic > "stuff" as you add things to the graph--like re-evaluating the > dependency graph on changes, but things have gotten noticably more sluggish. > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > What are you considering smaller/less-complicated? I have a pretty full one on a 5000x5000 canvas running fine. Maybe Sebastian knows what might have changed in the GRC backend to cause this? Obviously it's not fake if multiple people are seeing it, but it's not affecting me at all. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Editing medium-to-large flow-graphs in GRC now *agonizing* slow
Well, look at simple_ra (the name is, clearly, misleading). It's quite ponderous. The sheet isn't anywhere near 5000 x 5000, though. But others as well, like multimode (again, available through CGRAN), which has about half the block count of simple_ra. On 2014-09-10 12:55, Tom Rondeau wrote: > On Tue, Sep 9, 2014 at 8:25 PM, Marcus D. Leech wrote: > On 09/09/2014 08:20 PM, Tiankun Hu wrote: > Yes, I have the same issue with v3.7.5 > > Thanks > Tiankun > > Mike Jameson 编写： > > Yes, even after a fresh reboot there is still a delayed reaction while > dragging about blocks in GRC. > > GNU Radio Companion 3.7.5git-194-g76a271ac > Ubuntu 14.04 x64 LTS > Quad Core i7 > > Mike > > To be sure, there has always been a certain amount of sluggishness with large > flow-graphs (simple_ra, for an example), but what I'm seeing > now is probably 3 or 4 times worse, and affects smaller/less-complicated > graphs as well. I do realize that GRC is doing a lot of dynamic > "stuff" as you add things to the graph--like re-evaluating the dependency > graph on changes, but things have gotten noticably more sluggish. > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org [1] What are you considering smaller/less-complicated? I have a pretty full one on a 5000x5000 canvas running fine. Maybe Sebastian knows what might have changed in the GRC backend to cause this? Obviously it's not fake if multiple people are seeing it, but it's not affecting me at all. Tom Links: -- [1] http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Editing medium-to-large flow-graphs in GRC now *agonizing* slow
Moving about the blocks in a simple GRC flowgraph is very sluggish when my processor is set to 'Performance' or 'Ondemand'. When set to 'Powersave', moving about a block in exactly the same flowgraph works super fast again! The CPU frequency changer I'm using on my installation of Ubuntu 14.04 LTS x64 is called 'indicator-cpufreq' and if installed and run you will be able to access these different processor speed options: sudo apt-get install indicator-cpufreq The speed is confirmed with 'cat /proc/cpuinfo | grep "cpu MHz"' to be 800MHz on 'Powersave' and 2201MHz on 'Performance'. It would be interesting to know if you are seeing the same behaviour. Mike -- Mike Jameson M0MIK BSc MIET Email: m...@scanoo.com Web: http://scanoo.com On Wed, Sep 10, 2014 at 6:01 PM, wrote: > Well, look at simple_ra (the name is, clearly, misleading). It's quite > ponderous. The sheet isn't anywhere near 5000 x 5000, though. > > > > But others as well, like multimode (again, available through CGRAN), which > has about half the block count of simple_ra. > > > > > > > On 2014-09-10 12:55, Tom Rondeau wrote: > > On Tue, Sep 9, 2014 at 8:25 PM, Marcus D. Leech > wrote: > >> On 09/09/2014 08:20 PM, Tiankun Hu wrote: >> >>> Yes, I have the same issue with v3.7.5 >>> >>> >>> >>> Thanks >>> Tiankun >>> >>> Mike Jameson 编写： >>> >>> Yes, even after a fresh reboot there is still a delayed reaction while >>> dragging about blocks in GRC. >>> >>> GNU Radio Companion 3.7.5git-194-g76a271ac >>> Ubuntu 14.04 x64 LTS >>> Quad Core i7 >>> >>> Mike >>> >>> To be sure, there has always been a certain amount of sluggishness with >> large flow-graphs (simple_ra, for an example), but what I'm seeing >> now is probably 3 or 4 times worse, and affects smaller/less-complicated >> graphs as well. I do realize that GRC is doing a lot of dynamic >> "stuff" as you add things to the graph--like re-evaluating the >> dependency graph on changes, but things have gotten noticably more >> sluggish. >> >> -- >> Marcus Leech >> Principal Investigator >> Shirleys Bay Radio Astronomy Consortium >> http://www.sbrac.org >> > > What are you considering smaller/less-complicated? I have a pretty full > one on a 5000x5000 canvas running fine. > > Maybe Sebastian knows what might have changed in the GRC backend to cause > this? Obviously it's not fake if multiple people are seeing it, but it's > not affecting me at all. > > Tom > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Editing medium-to-large flow-graphs in GRC now *agonizing* slow
That is spectacularly counter-intuitive On 2014-09-10 14:16, Mike Jameson wrote: > Moving about the blocks in a simple GRC flowgraph is very sluggish when my > processor is set to 'Performance' or 'Ondemand'. > > When set to 'Powersave', moving about a block in exactly the same flowgraph > works super fast again! > > The CPU frequency changer I'm using on my installation of Ubuntu 14.04 LTS > x64 is called 'indicator-cpufreq' and if installed and run you will be able > to access these different processor speed options: > > sudo apt-get install indicator-cpufreq > > The speed is confirmed with 'cat /proc/cpuinfo | grep "cpu MHz"' to be 800MHz > on 'Powersave' and 2201MHz on 'Performance'. > > It would be interesting to know if you are seeing the same behaviour. > > Mike > > -- > Mike Jameson M0MIK BSc MIET > Email: m...@scanoo.com > Web: http://scanoo.com [1] > > On Wed, Sep 10, 2014 at 6:01 PM, wrote: > > Well, look at simple_ra (the name is, clearly, misleading). It's quite > ponderous. The sheet isn't anywhere near 5000 x 5000, though. > > But others as well, like multimode (again, available through CGRAN), which > has about half the block count of simple_ra. > > On 2014-09-10 12:55, Tom Rondeau wrote: > > On Tue, Sep 9, 2014 at 8:25 PM, Marcus D. Leech wrote: > On 09/09/2014 08:20 PM, Tiankun Hu wrote: > Yes, I have the same issue with v3.7.5 > > Thanks > Tiankun > > Mike Jameson 编写： > > Yes, even after a fresh reboot there is still a delayed reaction while > dragging about blocks in GRC. > > GNU Radio Companion 3.7.5git-194-g76a271ac > Ubuntu 14.04 x64 LTS > Quad Core i7 > > Mike > > To be sure, there has always been a certain amount of sluggishness with large > flow-graphs (simple_ra, for an example), but what I'm seeing > now is probably 3 or 4 times worse, and affects smaller/less-complicated > graphs as well. I do realize that GRC is doing a lot of dynamic > "stuff" as you add things to the graph--like re-evaluating the dependency > graph on changes, but things have gotten noticably more sluggish. > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org [2] What are you considering smaller/less-complicated? I have a pretty full one on a 5000x5000 canvas running fine. Maybe Sebastian knows what might have changed in the GRC backend to cause this? Obviously it's not fake if multiple people are seeing it, but it's not affecting me at all. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3] Links: -- [1] http://scanoo.com [2] http://www.sbrac.org [3] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] USRP 2920 doesn't work properly at UHD3.7.2 V.
Did you upgrade only GNU Radio, or both UHD and GNU Radio? Which version of Ubuntu are you running? --Neel On Wed, Sep 10, 2014 at 9:06 AM, Martin Braun wrote: > Did you only update GNU Radio? > Can you post some error message so we can help you? > > M > > On 09/10/2014 11:26 AM, Taner Tekin via USRP-users wrote: > > Hi all, > > > > I've installed this software gnuradio.v:3.7.5 on ubuntu. I am the > > owner of the device USRP2920. There wasn't gnuradio applications. I > > UHD USRP applications in version 3.5.4 gnuradio 'could also run > > smoothly. But, gnuradio on USRP 't does not work, now. I need to > > install the new image version has changed? There USRP images on > > devices. Because in the old version works fine. (UHD 3.5.4) What > > should I do, I do not understand.:( Thank you in advance for your > > interest. > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] make test error
hi, When I follow Gnuradio using "make test" and "ctest" to test my new how-to block, it returns RuntimeError: square_ff(6): insufficient connected output ports (1 needed, 0 connected) As the following messages, I think there may be something wrong with the test program "qa_square_ff.py" lab@lab-ThinkPad-Edge-E430:~/newblock/gr-howto/build$ ctest -V -R square UpdateCTestConfiguration from :/home/lab/newblock/gr-howto/build/DartConfiguration.tcl UpdateCTestConfiguration from :/home/lab/newblock/gr-howto/build/DartConfiguration.tcl Test project /home/lab/newblock/gr-howto/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 2 Start 2: qa_square_ff 2: Test command: /bin/sh "/home/lab/newblock/gr-howto/build/python/qa_square_ff_test.sh" 2: Test timeout computed to be: 9.99988e+06 2: E 2: == 2: ERROR: test_001_t (__main__.qa_square_ff) 2: -- 2: Traceback (most recent call last): 2: File "/home/lab/newblock/gr-howto/python/qa_square_ff.py", line 43, in test_001_t 2: self.tb.run () 2: File "/usr/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 109, in run 2: self.start(max_noutput_items) 2: File "/usr/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 103, in start 2: top_block_start_unlocked(self._tb, max_noutput_items) 2: File "/usr/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 4585, in top_block_start_unlocked 2: return _runtime_swig.top_block_start_unlocked(*args, **kwargs) 2: RuntimeError: square_ff(6): insufficient connected output ports (1 needed, 0 connected) 2: 2: -- 2: Ran 1 test in 0.000s 2: 2: FAILED (errors=1) 1/1 Test #2: qa_square_ff .***Failed0.17 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.17 sec The following tests FAILED: 2 - qa_square_ff (Failed) Errors while running CTest lab@lab-ThinkPad-Edge-E430:~/newblock/gr-howto/build$ make test Running tests... Test project /home/lab/newblock/gr-howto/build Start 1: test_howto 1/2 Test #1: test_howto ... Passed0.00 sec Start 2: qa_square_ff 2/2 Test #2: qa_square_ff .***Failed0.18 sec 50% tests passed, 1 tests failed out of 2 Total Test time (real) = 0.19 sec The following tests FAILED: 2 - qa_square_ff (Failed) Errors while running CTest make: *** [test] 错误 8 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to install gnuradio with pybombs
Hi Tom,
Thanks for the answers, and sorry for the late response. I'm using Ubuntu
12.04 Server, and i've already try to run volk_profile as you told me. Here
is the result:
openbts@openbts:~/gnuradio/target/bin$ ./volk_profile
./volk_profile: error while loading shared libraries: libvolk.so.0.0.0:
cannot open shared object file: No such file or directory
I also cannot run other function like uhd_fft:
openbts@openbts:~/gnuradio/target/bin$ ./uhd_fft
Traceback (most recent call last):
File "./uhd_fft", line 24, in
from gnuradio import gr, gru
ImportError: No module named gnuradio
This is the list of my ~/gnuradio/target/bin directory:
openbts@openbts:~/gnuradio/target/bin$ ls
dumpdb gr_plot_psd_c gr_time_plot_f
octoclock_firmware_burner uhd_rx_cfile
glacier2router gr_plot_psd_f gr_time_plot_i
slice2cpp uhd_rx_nogui
gnuradio-companion gr_plot_qt gr_time_plot_s
slice2cs uhd_siggen
gnuradio-config-info gr_plot_short gr_time_raster_b
slice2freeze uhd_siggen_gui
grcc gr_psd_plot_b gr_time_raster_f
slice2freezej uhd_usrp_probe
gr_constellation_plot gr_psd_plot_c icebox
slice2html usrp2_card_burner
gr_filter_design gr_psd_plot_f iceboxadmin
slice2java usrp_flex
gr_modtool gr_psd_plot_i iceca
slice2php usrp_flex_all
gr_plot_char gr_psd_plot_s icegridadmin
slice2py usrp_flex_band
gr_plot_const gr_read_file_metadata icegridnode
slice2rb usrp_n2xx_simple_net_burner
gr_plot_fftgr_spectrogram_plot_b icegridregistry
transformdbusrp_x3xx_fpga_burner
gr_plot_fft_c gr_spectrogram_plot_c icepatch2calc
uhd_cal_rx_iq_balance volk-config-info
gr_plot_fft_f gr_spectrogram_plot_f icepatch2client
uhd_cal_tx_dc_offset volk_modtool
gr_plot_float gr_spectrogram_plot_i icepatch2server
uhd_cal_tx_iq_balance volk_profile
gr_plot_intgr_spectrogram_plot_s icestormadmin uhd_fft
gr_plot_iq gr_time_plot_b icestormmigrate
uhd_find_devices
gr_plot_psdgr_time_plot_c nirio_programmer
uhd_images_downloader
I guess there is something went wrong here. Could anyone give clue...???
Any help would be very appreciated.
Thanks
Sammy
On Fri, Sep 5, 2014 at 8:12 PM, Tom Rondeau wrote:
> On Fri, Sep 5, 2014 at 12:34 AM, sammy zada wrote:
>
>> Hi everyone,
>>
>> Thanx for the detail explanation, i have followed some of your advice on
>> the email above. I use default for the option, these is the results:
>> ...
>> Run VOLK Profile to choose fastest kernels[Y]/N?
>> Submit anonymous VOLK performance statistics to stats.gnuradio.org?
>> Y/[N]?
>> please wait ... running volk profile, this will take several minutes...
>> shellexec_long: volk_profile
>> Traceback (most recent call last):
>> File "./pybombs", line 132, in
>> pybombs_ops.install(p, not opts.force);
>> File "/home/openbts/gnuradio/pybombs/mod_pybombs/pybombs_ops.py", line
>> 122, in install
>> run_volk_profile();
>> File "/home/openbts/gnuradio/pybombs/mod_pybombs/pybombs_ops.py", line
>> 82, in run_volk_profile
>> perf = shellexec_getout("volk_profile");
>> File "/home/openbts/gnuradio/pybombs/mod_pybombs/sysutils.py", line
>> 306, in shellexec_getout
>> raise e;
>> OSError: [Errno 2] No such file or directory
>>
>> Can you guys give me clue to solve this problem, thanx for the answers
>> and your patience.
>>
>> Regards,
>> Sammy
>>
>
> Luckily, that's just some stuff that happens at the end once GNU Radio is
> installed. So you should have a fully installed GNU Radio system. Why
> that's happening now, I don't understand. What OS are you using?
>
> Also, you should be able to run volk_profile yourself. Can you do that
> from a command line and see if it works properly on its own?
>
> Tom
>
>
>
>> On Thu, Sep 4, 2014 at 8:45 PM, Tom Rondeau wrote:
>>
>>> Taking Martin and Marcus' responses here, I've added a bit to the
>>> QuickStart guide to briefly explain the options a bit more. See the bottom
>>> of the page:
>>>
>>> http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart
>>>
>>> Tom
>>>
>>>
>>>
>>> On Thu, Sep 4, 2014 at 6:05 AM, Marcus Müller
>>> wrote:
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Sammy!
Just use the default , which is the value in the brackets [], by
hitting enter.
Greetings,
Marcus
On 04.09.2014 11:59, sammy zada wrote:
> Hi Martin,
>
> Thanks for your explanation. I've try to run the instructions on
> the website, i build the new directory ~/gnuradio, and run the
> following commands under the ~/gnuradio directory:
>
> openbts@openbts:~/gnuradio$ git clone
> git://github
