Re: [Discuss-gnuradio] Usage of Message Queues
Im sorry that im pushing my question, but its still unsolved for me and need it for my project.. So again, my message queue is filling, i checked that via tb.sink_queue.count(), but if i want to transfer pop a message, it just returns me that message_sptr thing. Can someone help me on that? I cant find a proper manual how to use the message queues/sinks. Again, thanks in advance for any hints :). -- View this message in context: http://gnuradio.4.n7.nabble.com/Usage-of-Message-Queues-tp39295p39455.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Changing Nout_items and Buffer Settings for GNURadio 3.6.2
To clarify, I am interested in making my file sampling rate at 125 k S/s and running the USRP at 250 kS/s. I am using a resampler block in between the file source and usrp sink. The file source reads data from a fifo file and external modulator code writes to that file. Thanks, Tom From: Tom Hendrick To: Tom Rondeau Cc: "discuss-gnuradio@gnu.org" Sent: Wednesday, February 6, 2013 2:54 PM Subject: Re: [Discuss-gnuradio] Changing Nout_items and Buffer Settings for GNURadio 3.6.2 Hi Tom, I appreciate your response and information on setting noutput_items for version 3.6.2. I am not sure if changing the noutput_items or buffer size is going to help at all. Basically when the data rate is lower than the transmission rate (purposely to eliminate latency), I'm noticing that the USRP is outputing random gaps in my packet of data during some of the underruns. Some of the underruns generate a wider gap between packets (this is good) but some of them generate a gap inside the packet data blocks causing problems. This happens when I am using a 125kHz sampling frequency and the USRP's rate set lower than 1M S/s. However with the USRP at 1M S/s it works fine. My goal is to run the USRP at 250k S/s to reduce processor load. For the 125k S/s case and lower than 1 M S/s USRP rate, if I increase my packet size by a factor of two, the gaps caused by underruns happen only between packets not inside them. The problem is the increase in packet size is not desirable for my application. The behavior I observed makes me think the issue could be fixed with changing the Nout_items or buffer settings. Any idea if that might be true? Thank you, Tom From: Tom Rondeau To: Tom Hendrick Cc: "discuss-gnuradio@gnu.org" Sent: Wednesday, February 6, 2013 2:36 PM Subject: Re: [Discuss-gnuradio] Changing Nout_items and Buffer Settings for GNURadio 3.6.2 On Wed, Feb 6, 2013 at 1:34 PM, Tom Hendrick wrote: Hello, > > >I think its possible some of the underrun issues I mentioned in my other posts >(where random gaps occur inside a block of data sent to the USRP when set the >USRP sampling frequency any lower than 1 MHz,) may be solved by tweaking >nout_items and buffer related settings. > > >For GNURadio 3.6.2, Is there a simple way to modify the python code generated >by GRC in order to change those settings? I had seen instructions for doing >this with 3.6.3 but I think they don't apply to the 3.6.2 version. I can >consider upgrading to 3.6.3 if there isn't an easy solution. > > >Thank you, Tom You can tweak the max noutput_items in 3.6.2. You can pass a value to the top block object when you run start/run that will set the maximum value noutput_items can be. In 3.6.3, you now have the ability to change the maximum noutput_items on a per block basis with block.set_max_noutput_items (this might be doable in 3.6.2; I forget when we added it). You can also change the buffer sizes of a block before you start the flowgraph with set_max/min_output_buffer. There should be very little concern going between 3.6.2 and 3.6.3. We maintain API compatibility between those versions. But, having said all of this, I'm not sure this is really going to help you. Are you thinking of decreasing the buffer sizes or the max noutput_items? That's actually going to hurt you computationally. It will lower latency, but it means less time inside a work function and more overhead in the scheduler, moving things around, and context switching. Larger buffers mean more time in work for each block, which is when you get the most power. 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] Changing Nout_items and Buffer Settings for GNURadio 3.6.2
Hi Tom, I appreciate your response and information on setting noutput_items for version 3.6.2. I am not sure if changing the noutput_items or buffer size is going to help at all. Basically when the data rate is lower than the transmission rate (purposely to eliminate latency), I'm noticing that the USRP is outputing random gaps in my packet of data during some of the underruns. Some of the underruns generate a wider gap between packets (this is good) but some of them generate a gap inside the packet data blocks causing problems. This happens when I am using a 125kHz sampling frequency and the USRP's rate set lower than 1M S/s. However with the USRP at 1M S/s it works fine. My goal is to run the USRP at 250k S/s to reduce processor load. For the 125k S/s case and lower than 1 M S/s USRP rate, if I increase my packet size by a factor of two, the gaps caused by underruns happen only between packets not inside them. The problem is the increase in packet size is not desirable for my application. The behavior I observed makes me think the issue could be fixed with changing the Nout_items or buffer settings. Any idea if that might be true? Thank you, Tom From: Tom Rondeau To: Tom Hendrick Cc: "discuss-gnuradio@gnu.org" Sent: Wednesday, February 6, 2013 2:36 PM Subject: Re: [Discuss-gnuradio] Changing Nout_items and Buffer Settings for GNURadio 3.6.2 On Wed, Feb 6, 2013 at 1:34 PM, Tom Hendrick wrote: Hello, > > >I think its possible some of the underrun issues I mentioned in my other posts >(where random gaps occur inside a block of data sent to the USRP when set the >USRP sampling frequency any lower than 1 MHz,) may be solved by tweaking >nout_items and buffer related settings. > > >For GNURadio 3.6.2, Is there a simple way to modify the python code generated >by GRC in order to change those settings? I had seen instructions for doing >this with 3.6.3 but I think they don't apply to the 3.6.2 version. I can >consider upgrading to 3.6.3 if there isn't an easy solution. > > >Thank you, Tom You can tweak the max noutput_items in 3.6.2. You can pass a value to the top block object when you run start/run that will set the maximum value noutput_items can be. In 3.6.3, you now have the ability to change the maximum noutput_items on a per block basis with block.set_max_noutput_items (this might be doable in 3.6.2; I forget when we added it). You can also change the buffer sizes of a block before you start the flowgraph with set_max/min_output_buffer. There should be very little concern going between 3.6.2 and 3.6.3. We maintain API compatibility between those versions. But, having said all of this, I'm not sure this is really going to help you. Are you thinking of decreasing the buffer sizes or the max noutput_items? That's actually going to hurt you computationally. It will lower latency, but it means less time inside a work function and more overhead in the scheduler, moving things around, and context switching. Larger buffers mean more time in work for each block, which is when you get the most power. Tom___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Changing Nout_items and Buffer Settings for GNURadio 3.6.2
On Wed, Feb 6, 2013 at 1:34 PM, Tom Hendrick wrote: > Hello, > > I think its possible some of the underrun issues I mentioned in my other > posts (where random gaps occur inside a block of data sent to the USRP when > set the USRP sampling frequency any lower than 1 MHz,) may be solved by > tweaking nout_items and buffer related settings. > > For GNURadio 3.6.2, Is there a simple way to modify the python code > generated by GRC in order to change those settings? I had seen > instructions for doing this with 3.6.3 but I think they don't apply to the > 3.6.2 version. I can consider upgrading to 3.6.3 if there isn't an easy > solution. > > Thank you, Tom > You can tweak the max noutput_items in 3.6.2. You can pass a value to the top block object when you run start/run that will set the maximum value noutput_items can be. In 3.6.3, you now have the ability to change the maximum noutput_items on a per block basis with block.set_max_noutput_items (this might be doable in 3.6.2; I forget when we added it). You can also change the buffer sizes of a block before you start the flowgraph with set_max/min_output_buffer. There should be very little concern going between 3.6.2 and 3.6.3. We maintain API compatibility between those versions. But, having said all of this, I'm not sure this is really going to help you. Are you thinking of decreasing the buffer sizes or the max noutput_items? That's actually going to hurt you computationally. It will lower latency, but it means less time inside a work function and more overhead in the scheduler, moving things around, and context switching. Larger buffers mean more time in work for each block, which is when you get the most power. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Changing Nout_items and Buffer Settings for GNURadio 3.6.2
Hello, I think its possible some of the underrun issues I mentioned in my other posts (where random gaps occur inside a block of data sent to the USRP when set the USRP sampling frequency any lower than 1 MHz,) may be solved by tweaking nout_items and buffer related settings. For GNURadio 3.6.2, Is there a simple way to modify the python code generated by GRC in order to change those settings? I had seen instructions for doing this with 3.6.3 but I think they don't apply to the 3.6.2 version. I can consider upgrading to 3.6.3 if there isn't an easy solution. Thank you, Tom___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] can SBX change IF bandwidth?
Hi, all, Can i use set_tx_bandwidth() or set_rx_bandwidth() to change the IF bandwidth of SBX? Thanks very much! Best, Gang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test hangs at gr-core-test-all qa_pdu
On Wed, Feb 6, 2013 at 12:03 PM, "Martin Lülf" wrote: > > On Tue, Feb 5, 2013 at 12:42 PM, "Martin Lülf" wrote: > > > >> > On Tue, Feb 5, 2013 at 5:28 AM, "Martin Lülf" > wrote: > >> > > >> >> Hi, > >> >> > >> >> while working on my issue with asynchronous blocks ( > >> >> > >> > https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00488.html > >> >> ). I discovered that the two tests 'gr-core-test-all' and 'qa_pdu' > >> >> sometimes hang up. That means they never return until I interrupt > >> with > >> >> Ctr+C. If I repeat the same make test without changing anything in > >> >> between, the tests sometimes run through and sometimes hang up again. > >> >> > >> >> I am running Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-35-generic x86_64) > >> with > >> >> the gnuradio master branch. > >> >> > >> >> Yours > >> >> Martin Luelf > >> >> > >> > > >> > What version of Boost are you running? If it's 1.46, 1.47, or 1.52, > >> that > >> > would explain the gr-core-test-all. It's a bug in Boost that we get > >> hit > >> > with (and we're supposed to not link against those versions, but > >> > apparently > >> > haven't done that right; see Issue #513). > >> > > >> > The PDU hangup I think is a race condition. I thought that I had fixed > >> > that, but apparently not entirely. I just opened up Issue 514 about > >> this. > >> > > >> > Thanks for reporting. > >> > > >> > Tom > >> > > >> > >> Hi Tom, > >> > >> thank you for your fast reply. Indeed updating to a newer version of > >> boost > >> (I moved from 1.46 to 1.53) seems to fix both of the issues. I repeated > >> make test for 10 times and both tests (as well as all others) ran > >> through > >> without issues every time. Before I hat to retry only once or twice to > >> get > >> a hangup. > >> > >> However I am still curious to learn how flowgraph start/stop works for > >> asynchronous blocks, as they don't have a start/stop function, as far as > >> I > >> understood. Can you point me to some documentation or a certain piece of > >> code where I can learn more about this? > >> > >> Yours > >> Martin > > > > > > I'm not sure what you mean by asynchronous blocks? All blocks run as > > threads. We can join them and interrupt them (all our threads are started > > with a Boost interruption point for this). > > > > Tom > > > > Hi Tom, > > by asynchronous blocks I mean a block that has only message ports as in > and outputs and thus no general_work function. As far as I saw these > block's start()/stop() functions are not called even if I implement them. > So when does such a block start or how/when is it stopped again? > > Especially regarding such a block's start please also see my previous post > to the mailing list > https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00488.html > > Yours > Martin > Ok, yeah, all blocks are launched as part of the start function of the top_block. As I said, they are just threads, so we launch a thread for each block that's a part of the flowgraph. Anything that's connected using the data stream 'connect' or message stream 'msg_connect' is considered part of the flowgraph. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test hangs at gr-core-test-all qa_pdu
> On Tue, Feb 5, 2013 at 12:42 PM, "Martin Lülf" wrote: > >> > On Tue, Feb 5, 2013 at 5:28 AM, "Martin Lülf" wrote: >> > >> >> Hi, >> >> >> >> while working on my issue with asynchronous blocks ( >> >> >> https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00488.html >> >> ). I discovered that the two tests 'gr-core-test-all' and 'qa_pdu' >> >> sometimes hang up. That means they never return until I interrupt >> with >> >> Ctr+C. If I repeat the same make test without changing anything in >> >> between, the tests sometimes run through and sometimes hang up again. >> >> >> >> I am running Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-35-generic x86_64) >> with >> >> the gnuradio master branch. >> >> >> >> Yours >> >> Martin Luelf >> >> >> > >> > What version of Boost are you running? If it's 1.46, 1.47, or 1.52, >> that >> > would explain the gr-core-test-all. It's a bug in Boost that we get >> hit >> > with (and we're supposed to not link against those versions, but >> > apparently >> > haven't done that right; see Issue #513). >> > >> > The PDU hangup I think is a race condition. I thought that I had fixed >> > that, but apparently not entirely. I just opened up Issue 514 about >> this. >> > >> > Thanks for reporting. >> > >> > Tom >> > >> >> Hi Tom, >> >> thank you for your fast reply. Indeed updating to a newer version of >> boost >> (I moved from 1.46 to 1.53) seems to fix both of the issues. I repeated >> make test for 10 times and both tests (as well as all others) ran >> through >> without issues every time. Before I hat to retry only once or twice to >> get >> a hangup. >> >> However I am still curious to learn how flowgraph start/stop works for >> asynchronous blocks, as they don't have a start/stop function, as far as >> I >> understood. Can you point me to some documentation or a certain piece of >> code where I can learn more about this? >> >> Yours >> Martin > > > I'm not sure what you mean by asynchronous blocks? All blocks run as > threads. We can join them and interrupt them (all our threads are started > with a Boost interruption point for this). > > Tom > Hi Tom, by asynchronous blocks I mean a block that has only message ports as in and outputs and thus no general_work function. As far as I saw these block's start()/stop() functions are not called even if I implement them. So when does such a block start or how/when is it stopped again? Especially regarding such a block's start please also see my previous post to the mailing list https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00488.html Yours Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test hangs at gr-core-test-all qa_pdu
On Tue, Feb 5, 2013 at 12:42 PM, "Martin Lülf" wrote: > > On Tue, Feb 5, 2013 at 5:28 AM, "Martin Lülf" wrote: > > > >> Hi, > >> > >> while working on my issue with asynchronous blocks ( > >> > https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00488.html > >> ). I discovered that the two tests 'gr-core-test-all' and 'qa_pdu' > >> sometimes hang up. That means they never return until I interrupt with > >> Ctr+C. If I repeat the same make test without changing anything in > >> between, the tests sometimes run through and sometimes hang up again. > >> > >> I am running Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-35-generic x86_64) with > >> the gnuradio master branch. > >> > >> Yours > >> Martin Luelf > >> > > > > What version of Boost are you running? If it's 1.46, 1.47, or 1.52, that > > would explain the gr-core-test-all. It's a bug in Boost that we get hit > > with (and we're supposed to not link against those versions, but > > apparently > > haven't done that right; see Issue #513). > > > > The PDU hangup I think is a race condition. I thought that I had fixed > > that, but apparently not entirely. I just opened up Issue 514 about this. > > > > Thanks for reporting. > > > > Tom > > > > Hi Tom, > > thank you for your fast reply. Indeed updating to a newer version of boost > (I moved from 1.46 to 1.53) seems to fix both of the issues. I repeated > make test for 10 times and both tests (as well as all others) ran through > without issues every time. Before I hat to retry only once or twice to get > a hangup. > > However I am still curious to learn how flowgraph start/stop works for > asynchronous blocks, as they don't have a start/stop function, as far as I > understood. Can you point me to some documentation or a certain piece of > code where I can learn more about this? > > Yours > Martin I'm not sure what you mean by asynchronous blocks? All blocks run as threads. We can join them and interrupt them (all our threads are started with a Boost interruption point for this). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error messages when running gr_filter_design for gnuradio 4.7 on MacPorts
I just checked in a change in r102664 < https://trac.macports.org/changeset/102664 >, which adds in the runtime dependency. I tried a couple ways to do "active variants" but I don't grok them yet so I went ahead and checked this in along with bumping devel and next to the latest from GIT. If OSX users are up for it, go ahead and experiment with the various QWT versions and see if/how they work. Let me know if you do, and if you come to any conclusions. - MLD On Feb 5, 2013, at 8:04 AM, Tom Rondeau wrote: > I consistently run using Qwt 5.2 (actually version 5.2.2) on some of my > machines. I normally try to run Qwt6, but I test against both. On my OSX > machine, I only run Qwt6, though, so I'm not sure if there's some issue with > 5.2.1/2 on that platform. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] unittest with USRP not finishing
you're correct. In the code I did in this order. -- View this message in context: http://gnuradio.4.n7.nabble.com/unittest-with-USRP-not-finishing-tp39439p39445.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compiling gr-osmosdr with gnuradio 3.7
On Wed, Feb 6, 2013 at 6:51 AM, Alexandru Csete wrote: > On Tue, Feb 5, 2013 at 11:58 PM, Tom Rondeau wrote: > > On Tue, Feb 5, 2013 at 5:23 PM, Alexandru Csete > wrote: > >> > >> With the latest changes I can no longer build the next branch :( > >> > >> Scanning dependencies of target gnuradio-blocks > >> [ 33%] Building CXX object > >> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/add_ss_impl.cc.o > >> In file included from > >> > >> > /home/alc/sdr/gnuradio/v3.6.3-575-g359dec2b-next/build/gr-blocks/lib/add_ss_impl.cc:29:0: > >> > >> > /home/alc/sdr/gnuradio/v3.6.3-575-g359dec2b-next/build/gr-blocks/lib/add_ss_impl.h:28:27: > >> fatal error: blocks/add_ss.h: No such file or directory > >> compilation terminated. > >> make[2]: *** > >> [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/add_ss_impl.cc.o] > >> Error 1 > >> make[1]: *** [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all] Error 2 > >> make: *** [all] Error 2 > >> > >> Seems to be a similar issue. > >> > >> Alex > > > > > > Yeah, because I made a complete hash out of my 'fix.' I forgot to try to > > build from scratch and didn't realize that I actually turned off the > header > > generation. > > > > Just pushed a new fix. Should do it. > > > > Tom > > Hi Tom, > > I can build again. I found noise_type.h to missing as well, but after > I added that manually I could finish building gr-osmosdr against > gnuradio 3.7git. I have attached a patch for gr-osmosdr if anyone is > interested, but I'm sure it will support 3.7 soon. > > PS: for the patch to work one must ensure that gnuradio-analog and > gnuradio-blocks are available - the patch does not include checks for > those. > > Alex > The noise_type.h bug has been fixed. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] unittest with USRP not finishing
On Wed, Feb 6, 2013 at 8:37 AM, maiconkist wrote:
> Resolved.
>
> Its necessary to call gr.top_block::wait() method before the "stop()".
> Anybody know why this is necessary?
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/unittest-with-USRP-not-finishing-tp39439p39441.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
In the thread-per-block scheduler:
void
gr_scheduler_tpb::stop()
{
d_threads.interrupt_all();
}
void
gr_scheduler_tpb::wait()
{
d_threads.join_all();
}
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] unittest with USRP not finishing
Hi, You have to call tb.stop() before the tb.wait(), not the other way around like you mentioned: tb.stop() tb.wait() The tb.wait() is to make sure the flowgraph has fully stopped before doing anything else. Cheers, Mike Mike M0MIK On 6 February 2013 13:37, maiconkist wrote: > Resolved. > > Its necessary to call gr.top_block::wait() method before the "stop()". > Anybody know why this is necessary? > > > > -- > View this message in context: > http://gnuradio.4.n7.nabble.com/unittest-with-USRP-not-finishing-tp39439p39441.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > ___ > 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] unittest with USRP not finishing
Resolved. Its necessary to call gr.top_block::wait() method before the "stop()". Anybody know why this is necessary? -- View this message in context: http://gnuradio.4.n7.nabble.com/unittest-with-USRP-not-finishing-tp39439p39441.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] WX Gui Widget Error
Hi! I am a new GNU Radio user. I will be using it mainly for educational purposes. I use a legit Windows 7 installation. ( the installation was done about 3 years ago, not a clean install). I followed step by step the instructions presented here (on the code.ettus site): http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windows I am able to start GNU Radio. I'm trying to simulate a very basic situation: a signal generator, with the output connected to a throttle and the throttle's output connected to a WX Gui Widget Scope Sink (wxgui_scopesink2_0). When i try to execute the flowgraph. The WX Gui Scope window appears but nothing happens. I am receiving the following error: Traceback (most recent call last): File "F:\Win7\gnuradio\lib\site-packages\gnuradio\wxgui\forms\forms.py", line 100, in widget.Bind(EVT_DATA, lambda x: self._update(x.data)) File "F:\Win7\gnuradio\lib\site-packages\gnuradio\wxgui\forms\forms.py", line 503, in _update def _update(self, i): self._notebook.SetSelection(i) File "C:\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_controls.py", line 3021, in SetSelection return _controls_.BookCtrlBase_SetSelection(*args, **kwargs) ValueError: in method 'BookCtrlBase_SetSelection', expected argument 2 of type 'size_t' NOTE: I managed to see the signal in QT Gui Widget. Everything was fine. Why can't i use the WX Gui Widgets? ( i've tried several more like the waterfall, fft... still nothing ) Hope this is the right place to ask. And hope i'll know how to reply :)) Have a great day! Mihai, Polytechnics University of Bucharest. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] unittest with USRP not finishing
Hello list, I am trying to write a simple unit test from a flow graph I'm writing. The problem is that the flowgraph dont finish. It hangs in the line "self.assertNotEqual(out, 0). The complete code is as follows: from gnuradio import gr_unittest # Project imports from usrpDevice import UsrpFlowGraph from usrpDevice import USRPDevice from time import sleep ## Test DeviceWrapper methods # class qa_device(gr_unittest.TestCase): ## Test USRP communication def test_001_usrp(self): uhd = USRPDevice() uhd.start() out = uhd.sense() self.assertNotEqual(out, 0) if __name__ == '__main__': gr_unittest.main() And the USRPDevice class: class USRPDevice(gr.top_block): ## CTOR def __init__(self): gr.top_block.__init__(self, "Energy Top Block") self.mUhd = uhd.usrp_source(device_addr=options.addr, stream_args=uhd.stream_args(cpu_format='fc32', otw_format='sc16')) self.ed = EnergyDetector(options.fft_size) self.mavg = gr.moving_average_ff(options.moving_avg_size, 1.0/options.moving_avg_size ) self.mOut = gr.probe_signal_f() self.connect(self.mUhd, self.ed, self.mavg, self.mOut) def sense(self): return self.mOut.level() I tried changed the code and verified that USRPDevice::sense is returning when its called. And if I remove the "start()" call in the Unit Test, it works fine. Any suggestion of whats happening ? -- View this message in context: http://gnuradio.4.n7.nabble.com/unittest-with-USRP-not-finishing-tp39439.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compiling gr-osmosdr with gnuradio 3.7
On Tue, Feb 5, 2013 at 11:58 PM, Tom Rondeau wrote: > On Tue, Feb 5, 2013 at 5:23 PM, Alexandru Csete wrote: >> >> With the latest changes I can no longer build the next branch :( >> >> Scanning dependencies of target gnuradio-blocks >> [ 33%] Building CXX object >> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/add_ss_impl.cc.o >> In file included from >> >> /home/alc/sdr/gnuradio/v3.6.3-575-g359dec2b-next/build/gr-blocks/lib/add_ss_impl.cc:29:0: >> >> /home/alc/sdr/gnuradio/v3.6.3-575-g359dec2b-next/build/gr-blocks/lib/add_ss_impl.h:28:27: >> fatal error: blocks/add_ss.h: No such file or directory >> compilation terminated. >> make[2]: *** >> [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/add_ss_impl.cc.o] >> Error 1 >> make[1]: *** [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all] Error 2 >> make: *** [all] Error 2 >> >> Seems to be a similar issue. >> >> Alex > > > Yeah, because I made a complete hash out of my 'fix.' I forgot to try to > build from scratch and didn't realize that I actually turned off the header > generation. > > Just pushed a new fix. Should do it. > > Tom Hi Tom, I can build again. I found noise_type.h to missing as well, but after I added that manually I could finish building gr-osmosdr against gnuradio 3.7git. I have attached a patch for gr-osmosdr if anyone is interested, but I'm sure it will support 3.7 soon. PS: for the patch to work one must ensure that gnuradio-analog and gnuradio-blocks are available - the patch does not include checks for those. Alex gr-osmosdr-gr37.patch Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
