Nabble - GnuRadio

Re: No exception... but no transmission

2009-12-05T13:45:42Z

On Tue, Dec 01, 2009 at 01:17:41AM -0800, abbasi9999 wrote:

>
> Hi all,
>
> Actually i pasted this post before but according to the rules, since i was
> not subscribed to the GNU mailing list i have to send it again.
>
> I'm new to Python and gnuradio, so please help me.
>
> My problem doesnot show any exception so i cannot trace it.
> However, i created a program to transmit dbpsk signal (i didnot create the
> receiver yet).
> in the main function I'm doing loop to transmit about 1000 packtet.
> but it start sending the first 4 and then stuck (it did not send them
> correctly), to check what is going on i used the command :
> sys.stderr.write('.')
>
> so it will print "." when there is error but the problem i dont know why its
> stuck.
> there is no exception.
>
> please help ASAP
> regards,

Have you looked at gnuradio-examples/python/digital/benchmark_tx.py?

Try:

benchmark_tx.py --help

Please see also http://gnuradio.org/trac/wiki/ReportingErrors

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: Flowgraph generates output even when the input exhausts

2009-12-05T08:05:34Z

There was a problem in my block. I fixed it. I am using gr_block and cosume_each.

Thanks for the help

On Sat, Dec 5, 2009 at 8:54 AM, Eric Blossom <eb@...> wrote:

On Thu, Dec 03, 2009 at 11:16:01AM -0600, Mir M. Ali wrote:
> Hi,
> I developed a gnuradio block that takes 2 inputs. Input_01 is coming from a
> source that repeats and Input_02 is coming from a source that exhausts after
> a while. The output should only be generated when there is data on both the
> input lines. I see in my flowgraph that even when the data on input_02
> exhausts output is still generated even though I see no problem with my C++
> code. Its a simple operation in which for each input in Input_02 line the
> block outputs 'N' items from Input_01. Once, the data source (in this case
> is a file_source in non-repeat mode) for Input_02 exhausts i.e. the file is
> read completely the output should stop being generated as there is nothing
> coming on Input_02. I expect the previous data stored in the buffer for
> Input_02 is flushed by the scheduler after one work() cycle.
>
> Any help would be appreciated.
> Thanks,
> Mir

GNU Radio does work the way you described. You can confirm this by
doing something like:

src1 = gr.vector_source_f((1,2,3,4,5,6), False)
src2 = gr.vector_source_f((10,11,12,13,14,15), True)
op = gr.add_ff()
dst = gr.vector_sink_f()

tb.connect(src1, (op, 0))
tb.connect(src2, (op, 1))
tb.connect(op, dst)

tb.run()

This will halt.

There is most likely a problem in your block. If you're subclassing
gr_block, are you calling consume or consume_each?

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: Flowgraph generates output even when the input exhausts

2009-12-05T06:54:58Z

On Thu, Dec 03, 2009 at 11:16:01AM -0600, Mir M. Ali wrote:

> Hi,
> I developed a gnuradio block that takes 2 inputs. Input_01 is coming from a
> source that repeats and Input_02 is coming from a source that exhausts after
> a while. The output should only be generated when there is data on both the
> input lines. I see in my flowgraph that even when the data on input_02
> exhausts output is still generated even though I see no problem with my C++
> code. Its a simple operation in which for each input in Input_02 line the
> block outputs 'N' items from Input_01. Once, the data source (in this case
> is a file_source in non-repeat mode) for Input_02 exhausts i.e. the file is
> read completely the output should stop being generated as there is nothing
> coming on Input_02. I expect the previous data stored in the buffer for
> Input_02 is flushed by the scheduler after one work() cycle.
>
> Any help would be appreciated.
> Thanks,
> Mir

GNU Radio does work the way you described. You can confirm this by
doing something like:

src1 = gr.vector_source_f((1,2,3,4,5,6), False)
src2 = gr.vector_source_f((10,11,12,13,14,15), True)
op = gr.add_ff()
dst = gr.vector_sink_f()

tb.connect(src1, (op, 0))
tb.connect(src2, (op, 1))
tb.connect(op, dst)

tb.run()

This will halt.

There is most likely a problem in your block. If you're subclassing
gr_block, are you calling consume or consume_each?

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: how many samples captured with usrp_rx_cfile

2009-12-05T00:36:17Z

You could easily tell by the capture file size. Divide the number of bytes by 8, unless you used shorts, then divide by 4.

- George

On Fri, Dec 4, 2009 at 6:51 PM, dave k <dave_k_420@...> wrote:

hey folks i usually make capture files with usrp_rx_cfile by using the -N option... however if i arbatrialy stop the capture with ctrl-c is how would i figure out how many samples were actually captured?

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Question on howto-write-a-block

2009-12-04T20:29:27Z

Hi All,

I am building a signal processing block following the tutorial under the directory /gnuradio/gr-howto-write-a-block, say 'howto_code' block. I've created howto_code.h and howto_code.cc file under /gnuradio/gr-howto-write-a-block/src/lib, meanwhile, I modified howto.i and Makefile.am in the same directory.

Then, under the directory /gnuradio/gr-howto-write-a-block, I run
./bootstrap
./configure
make
I got error said "/usr/bin/swig -c++ -fvirtual -python -modern -I/usr/local/include/gnuradio/swig -I/usr/local/include/gnuradio -module howto -o howto.cc ../../src/lib/howto.i
howto_addcode.h
/bin/bash: howto_code.h: command not found"

Can anyone advise me how to fix it? What should be the problem?

Thanks in advance,
Brook

Re: Building wxPython in Cygwin

2009-12-04T19:49:42Z

<radio4pm@...> wrote:

>I am attempting to build wxPython under Cyqwin. Like the message posted on
>the listserv September 14, I am getting an error message for a missing
>CreateBitmap member in the class wxGraphicsRenderer. The complete output
>from build step 9 showing all of the error messages follows at the end of
>this message. I made the modifications to both the setup.h file and the
>timer.cpp files as indicated in the build instructions and the
>_gdi_wrap.cpp file as suggested in the previous e-mail. The output below
>indicates that I still am seeing the same problem even with the updated
>files. I have included snips from both setup.h and _gdi_wrap.cpp with the
>modifications in the event that I either entered the information
>incorrectly or that there is another problem in the file that I have
>missed. The widgets installed fine and run the test cases without a
>problem, so I would appreciate any suggestions as to where to go from here
>to complete the wxPython build.
>
> Thanks,
> -CAS
>
> File: Setup.h (starting at line 320)
>
> #define wxUSE_COMBOBOX 1
> #define wxUSE_DATAVIEWCTRL 0
> #define wxUSE_DATEPICKCTRL 1
> #define wxUSE_DATEPICKCTRL_GENERIC 1
> #define wxUSE_DIRPICKERCTRL 1
> #define wxUSE_FILEPICKERCTRL 1
> #define wxUSE_FONTPICKERCTRL 1
> #define wxUSE_GAUGE 1
> #define wxUSE_HYPERLINKCTRL 1
>
>
> File: _gdi_wrap.cpp (starting at line 4055)
>
> virtual wxGraphicsBrush CreateRadialGradientBrush( wxDouble xo, wxDouble
> yo,
> wxDouble xc,
> wxDouble yc, wxDouble radius,
> const wxColour
> &oColor, const wxColour &cColor) { return wxNullGraphicsBrush; }
>
> virtual wxGraphicsFont CreateFont( const wxFont &, const wxColour & )
> { return wxNullGraphicsFont; }
>
> /* Next line added per per web message regarding installation: CAS -
> 11/27/2009 */
> virtual wxGraphicsBitmap CreateBitmap ( const wxBitmap & ) { return
> wxNullGraphicsBitmap; }

This line was added in the wrong place; it should be added at about line
4156. The instructions at http://gnuradio.org/trac/wiki/wxPythonCygwin
include a patch that does this for you.

> wxGraphicsBitmap CreateBitmap( const wxBitmap &bitmap ) const { return
> wxNullGraphicsBitmap; }

-- Don W.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: Building on OSX 10.6

2009-12-04T17:55:10Z

On Dec 4, 2009, at 2:56 PM, Ed Criscuolo wrote:

> I've decided to take this approach for now. I've cloned the latest
> git master, but I'm a total beginner at git. Where's the best place
> to insert the "-arch i386" into CFLAGS to force a 32-bit build? Is
> it as simple as
>
> ./bootstrap
> ./configure
> "make CFLAGS="-arch i386"
> make check
> sudo make install
>
> or does it need to go in as a switch to "configure"?

Into configure, or before then; after bootstrap & before make. You
can just

export CFLAGS="-arch i386"

and so forth, then run 'configure' & it'll pick up your shell
environment. I don't think you can easily change the build
environment directing from 'make'. I haven't tried this approach, but
I see no reason it won't work. Do let me/the list know, and good
luck! - MLD

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Building wxPython in Cygwin

2009-12-04T16:57:21Z

I am attempting to build wxPython under Cyqwin. Like the message posted on the listserv September 14, I am getting an error message for a missing CreateBitmap member in the class wxGraphicsRenderer. The complete output from build step 9 showing all of the error messages follows at the end of this message. I made the modifications to both the setup.h file and the timer.cpp files as indicated in the build instructions and the _gdi_wrap.cpp file as suggested in the previous e-mail. The output below indicates that I still am seeing the same problem even with the updated files. I have included snips from both setup.h and _gdi_wrap.cpp with the modifications in the event that I either entered the information incorrectly or that there is another problem in the file that I have missed. The widgets installed fine and run the test cases without a problem, so I would appreciate any suggestions as to where to go from here to complete the wxPython build.

Thanks,
-CAS

File: Setup.h (starting at line 320)

#define wxUSE_COMBOBOX 1
#define wxUSE_DATAVIEWCTRL 0
#define wxUSE_DATEPICKCTRL 1
#define wxUSE_DATEPICKCTRL_GENERIC 1
#define wxUSE_DIRPICKERCTRL 1
#define wxUSE_FILEPICKERCTRL 1
#define wxUSE_FONTPICKERCTRL 1
#define wxUSE_GAUGE 1
#define wxUSE_HYPERLINKCTRL 1

File: _gdi_wrap.cpp (starting at line 4055)

virtual wxGraphicsBrush CreateRadialGradientBrush( wxDouble xo, wxDouble yo,
wxDouble xc, wxDouble yc, wxDouble radius,
const wxColour &oColor, const wxColour &cColor) { return wxNullGraphicsBrush; }

virtual wxGraphicsFont CreateFont( const wxFont &, const wxColour & ) { return wxNullGraphicsFont; }

/* Next line added per per web message regarding installation: CAS - 11/27/2009 */
virtual wxGraphicsBitmap CreateBitmap ( const wxBitmap & ) { return wxNullGraphicsBitmap; }

wxGraphicsBitmap CreateBitmap( const wxBitmap &bitmap ) const { return wxNullGraphicsBitmap; }

virtual wxGraphicsMatrix CreateMatrix( wxDouble, wxDouble, wxDouble, wxDouble,
wxDouble, wxDouble) { return wxNullGraphicsMatrix; }

virtual void PushState() {}
virtual void PopState() {}

output from attempted build: (I included the Gizmos as I had build them on the system)

python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin BUILD_GLCANVAS=0 UNICODE=0

WARNING: WXWIN not set in environment. Assuming '..'
Found wx-config: /usr/local/bin/wx-config
Using flags: --toolkit=msw --unicode=no --version=2.8
Preparing CORE...
Preparing STC...
Preparing GIZMOS...
running build_ext
building '_gdi_' extension
gcc -mcygwin -mdll -O -Wall -DSWIG_TYPE_TABLE=_wxPython_table -DSWIG_PYTHON_OUTPUT_TUPLE -DWXP_USE_THREAD=1 -UNDEBUG -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DWXUSINGDLL -D__WXMSW__ -Iinclude -Isrc -I/usr/local/lib/wx/include/msw-ansi-release-2.8 -I/usr/local/include/wx-2.8 -I/usr/include/python2.5 -c src/msw/_gdi_wrap.cpp -o build/temp.cygwin-1.5.25-i686-2.5/src/msw/_gdi_wrap.o -O3
src/msw/_gdi_wrap.cpp: In function `wxPalette* new_wxPalette(const wxArrayInt&, const wxArrayInt&, const wxArrayInt&)':
src/msw/_gdi_wrap.cpp:2884: warning: comparison between signed and unsigned integer expressions
src/msw/_gdi_wrap.cpp:2884: warning: comparison between signed and unsigned integer expressions
src/msw/_gdi_wrap.cpp: In member function `virtual bool wxGraphicsContext::SetLogicalFunction(int)':
src/msw/_gdi_wrap.cpp:4076: warning: no return statement in function returning non-void
src/msw/_gdi_wrap.cpp: In function `PyObject* _wrap_GraphicsRenderer_CreateBitmap(PyObject*, PyObject*, PyObject*)':
src/msw/_gdi_wrap.cpp:32229: error: 'class wxGraphicsRenderer' has no member named 'CreateBitmap'
src/msw/_gdi_wrap.cpp: In function `PyObject* _wrap_PenList_AddPen(PyObject*, PyObject*, PyObject*)':
src/msw/_gdi_wrap.cpp:33879: warning: `AddPen' is deprecated (declared at /usr/local/include/wx-2.8/wx/gdicmn.h:516)
src/msw/_gdi_wrap.cpp: In function `PyObject* _wrap_PenList_RemovePen(PyObject*, PyObject*, PyObject*)':
src/msw/_gdi_wrap.cpp:33917: warning: `RemovePen' is deprecated (declared at /usr/local/include/wx-2.8/wx/gdicmn.h:517)
src/msw/_gdi_wrap.cpp: In function `PyObject* _wrap_BrushList_AddBrush(PyObject*, PyObject*, PyObject*)':
src/msw/_gdi_wrap.cpp:34010: warning: `AddBrush' is deprecated (declared at /usr/local/include/wx-2.8/wx/gdicmn.h:526)
src/msw/_gdi_wrap.cpp: In function `PyObject* _wrap_BrushList_RemoveBrush(PyObject*, PyObject*, PyObject*)':
src/msw/_gdi_wrap.cpp:34048: warning: `RemoveBrush' is deprecated (declared at /usr/local/include/wx-2.8/wx/gdicmn.h:527)
src/msw/_gdi_wrap.cpp: In function `PyObject* _wrap_FontList_AddFont(PyObject*, PyObject*, PyObject*)':
src/msw/_gdi_wrap.cpp:34200: warning: `AddFont' is deprecated (declared at /usr/local/include/wx-2.8/wx/gdicmn.h:539)
src/msw/_gdi_wrap.cpp: In function `PyObject* _wrap_FontList_RemoveFont(PyObject*, PyObject*, PyObject*)':
src/msw/_gdi_wrap.cpp:34238: warning: `RemoveFont' is deprecated (declared at /usr/local/include/wx-2.8/wx/gdicmn.h:540)
error: command 'gcc' failed with exit status 1

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

how many samples captured with usrp_rx_cfile

2009-12-04T15:51:57Z

hey folks i usually make capture files with usrp_rx_cfile by using the -N option... however if i arbatrialy stop the capture with ctrl-c is how would i figure out how many samples were actually captured?

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.

2009-12-04T14:49:41Z

I have fixed this error by completely uninstalling GR and removing the associated libraries (including libusrp, which it looks like you missed) from the library directories as well as from the Python module include directory. Then reinstall.

--n

> From: Johan.Mussche@...
> To: discuss-gnuradio@...
> Date: Fri, 4 Dec 2009 14:53:39 +0100
> Subject: RE: [Discuss-gnuradio] Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.
> CC:
>
> I have followed the advise, but it did not work. I am working on Ubuntu 9.04 and use gnuradio 3.2.2.
> The error only occurs when I use the SSRP. Other flow-graphs create no errors.
>
> Are there any other ideas about the cause.
>
> Regards,
> Johan
>
> ##############################################################################################
>
> NotImplementedError: Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.
> Possible C/C++ prototypes are:
> connect(boost::shared_ptr< gr_top_block> *,gr_basic_block_sptr)
> connect(boost::shared_ptr< gr_top_block> *,gr_basic_block_sptr,int,gr_basic_block_sptr,int)
>
> swig/python detected a memory leak of type 'gr_basic_block_sptr *', no destructor found.
>
> ###############################################################################################
> ________________________________________
> Van: Josh Blum [josh@...]
> Verzonden: woensdag 2 december 2009 20:55
> Aan: Johan Mussche
> CC: discuss-gnuradio@...
> Onderwerp: Re: [Discuss-gnuradio] Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.
>
> I have seen this error before on a fedora 11 system, reproducible too. If you make clean, make, and make install your from your source, and try again, it should go away. I have no idea why.
>
> Also, I recommend using gnuradio 3.2 (or from the master) which comes with a way-newer version of grc.
>
> -Josh
>
> On Wed, Dec 2, 2009 at 10:16 AM, Johan Mussche <Johan.Mussche@...<mailto:Johan.Mussche@...>> wrote:
> Hello everyone,
>
> I am trying to use a SSRP with GNU-radio. In the past, with version 3.1 of gnuradio and GRC 0.69, the SSRP worked.
>
> Now I am using the latest version of GNU-radio from the svn trunk in combination with swig 1.3.36 and python 2.6.
> I have installed the ssrp-files into gnuradio and added the SSRP-block to GRC. Loading the firmware into the SSRP is no problem but
> when I want to run the flow-graph I get the following error:
>
> #####################################################################################
>
> ssrp: firmware /usr/share/ssrp/firmware/rxS_512.ihx loaded successfully.
> Traceback (most recent call last):
> File "/root/Desktop/top_block.py", line 62, in <module>
> tb = top_block()
> File "/root/Desktop/top_block.py", line 52, in __init__
> self.connect((self.ssrp_simple_source_x_0, 0), (self.gr_interleaved_short_to_complex_0, 0))
> File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py", line 124, in connect
> self._connect(points[i-1], points[i])
> File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py", line 130, in _connect
> dst_block.basic_block(), dst_port)
> File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 1443, in connect
> return _gnuradio_swig_py_runtime.gr_top_block_sptr_connect(*args)
> NotImplementedError: Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.
> Possible C/C++ prototypes are:
> connect(boost::shared_ptr< gr_top_block> *,gr_basic_block_sptr)
> connect(boost::shared_ptr< gr_top_block> *,gr_basic_block_sptr,int,gr_basic_block_sptr,int)
>
> ########################################################################################
>
> I have also tried to to use the old GRC (0.69) but that gives the same error, so it has nothing to do with GRC.
>
> Can anyone tell me the cause of this error. Is it because of the newer version of swig or gnuradio?
>
> Best regards,
>
> Johan
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@...<mailto:Discuss-gnuradio@...>
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@...
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_________________________________________________________________
Get gifts for them and cashback for you. Try Bing now.
http://www.bing.com/shopping/search?q=xbox+games&scope=cashback&form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_Shopping_Giftsforthem_cashback_1x1

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

library for wrapping simd calls

2009-12-04T14:20:57Z

Found out about these little gems at the gr summit 09:

http://liboil.freedesktop.org/wiki/
http://www.schleef.org/orc/documentation/

If liboil does what I think it does, we only have to write the code once with liboil calls, and this library takes care of giving us a fast vectorized implementation on various platforms.

The internet is a big place, and helpful stuff like liboil could easily get missed. If anyone happens to come across a project that could make gnuradio faster/smarter, please share the knowledge!

-Josh

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Building on OSX 10.6

2009-12-04T11:56:55Z

Michael Dickens wrote:
>
> 2) Move to the GIT master, and limit compilation to just 32-bit mode
> -- and you should get full GNU Radio functionality (assuming you can
> get all of the background dependencies installed, e.g., via MacPorts).
>

Michael,

I've decided to take this approach for now. I've cloned the latest
git master, but I'm a total beginner at git. Where's the best place
to insert the "-arch i386" into CFLAGS to force a 32-bit build? Is
it as simple as

./bootstrap
./configure
"make CFLAGS="-arch i386"
make check
sudo make install

or does it need to go in as a switch to "configure"?

By the way, we missed you at the "GnuRadio Summit '09"
last night after the SDR '09 sessions.

@(^.^)@ Ed

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

libgnuradio-usrp.so.0: undefined symbol: _ZN7db_base4dbidEv

2009-12-04T11:45:47Z

hola,

i've read the archives and i read Eric B suggesting one should:

"remove all traces of GNU Radio from /usr/local,then remake and install a
known version (from svn or a tarball)."

I just did that twice with the latest 2 revs 11665 and 11664 but im still
trapped by:

libgnuradio-usrp.so.0: undefined symbol: _ZN7db_base4dbidEv

could anyone tell me what else to try, im right now under Ubuntu karmic
but will reboot under gentoo in a moment.

Thx for any tip,
/a

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.

2009-12-04T05:53:39Z

I have followed the advise, but it did not work. I am working on Ubuntu 9.04 and use gnuradio 3.2.2.
The error only occurs when I use the SSRP. Other flow-graphs create no errors.

Are there any other ideas about the cause.

Regards,
Johan

##############################################################################################

NotImplementedError: Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.
Possible C/C++ prototypes are:
connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr)
connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr,int,gr_basic_block_sptr,int)

swig/python detected a memory leak of type 'gr_basic_block_sptr *', no destructor found.

###############################################################################################
________________________________________
Van: Josh Blum [josh@...]
Verzonden: woensdag 2 december 2009 20:55
Aan: Johan Mussche
CC: discuss-gnuradio@...
Onderwerp: Re: [Discuss-gnuradio] Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.

I have seen this error before on a fedora 11 system, reproducible too. If you make clean, make, and make install your from your source, and try again, it should go away. I have no idea why.

Also, I recommend using gnuradio 3.2 (or from the master) which comes with a way-newer version of grc.

-Josh

On Wed, Dec 2, 2009 at 10:16 AM, Johan Mussche <Johan.Mussche@...<mailto:Johan.Mussche@...>> wrote:
Hello everyone,

I am trying to use a SSRP with GNU-radio. In the past, with version 3.1 of gnuradio and GRC 0.69, the SSRP worked.

Now I am using the latest version of GNU-radio from the svn trunk in combination with swig 1.3.36 and python 2.6.
I have installed the ssrp-files into gnuradio and added the SSRP-block to GRC. Loading the firmware into the SSRP is no problem but
when I want to run the flow-graph I get the following error:

#####################################################################################

ssrp: firmware /usr/share/ssrp/firmware/rxS_512.ihx loaded successfully.
Traceback (most recent call last):
File "/root/Desktop/top_block.py", line 62, in <module>
tb = top_block()
File "/root/Desktop/top_block.py", line 52, in __init__
self.connect((self.ssrp_simple_source_x_0, 0), (self.gr_interleaved_short_to_complex_0, 0))
File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py", line 124, in connect
self._connect(points[i-1], points[i])
File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py", line 130, in _connect
dst_block.basic_block(), dst_port)
File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 1443, in connect
return _gnuradio_swig_py_runtime.gr_top_block_sptr_connect(*args)
NotImplementedError: Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.
Possible C/C++ prototypes are:
connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr)
connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr,int,gr_basic_block_sptr,int)

########################################################################################

I have also tried to to use the old GRC (0.69) but that gives the same error, so it has nothing to do with GRC.

Can anyone tell me the cause of this error. Is it because of the newer version of swig or gnuradio?

Best regards,

Johan

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...<mailto:Discuss-gnuradio@...>
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

USRP2 stops after several-days-continuous-operation

2009-12-04T01:10:04Z

Hi, folks,

I'm testing my application with USRP2.
After I verify the function works fine logically, I started aging test by letting the program run over a week.
Although it varies, the program hangs eventually after running several days. (from 2~3 days to 8 days)

The followings are part of my python code

# In the top block,
    ~~~
    self.u = usrp2.source_32fc(self.interface, self.MAC_addr)
    s2v = gr.stream_to_vector(gr.sizeof_gr_complex, self.fft_size)
fft = gr.fft_vcc(self.fft_size, True, mywindow)
c2mag = gr.complex_to_mag_squared(self.fft_size)
    self.msgq = gr.msg_queue(1)
    stats = gr.message_sink(gr.sizeof_float * self.fft_size, self.msgq, True)

    self.connect(self.u, s2v, fft, c2mag, stats)
    ~~~

# In main_loop thread
    ~~~
    while(1):
        rcvd_param = rx_msg.check_udp()

        if (rcvd_param[0] == 1):        # Valid UDP packet received
            tb.u.set_decim(cp.decim)    # Set(Update) USRP2 decim
            cp.init_ctrl_param(rcvd_param, tb.fft_size)

        radio.tune(cp.ctr_freq)                                # This is to control other independent receiver
        cp.spectrum_inv = radio.spectrum_status()

        # Force buffer flushing
        samples = msg.payload(tb.msgq.delete_head(), tb.fft_size)
        samples = msg.payload(tb.msgq.delete_head(), tb.fft_size)
        samples = msg.payload(tb.msgq.delete_head(), tb.fft_size)
        samples.make_rawdata()
        tx_msg.send_packet_over_UDP(cp, samples.raw_data)
    ~~~
        cp.update()                                                # End of while loop
    ~~~

In the program, I generated a message queue to get the sample from USRP2, do some process it a bit, and send it to other server over UDP.

In the while loop,
1. Check the user defined control parameter (concerning tuning frequency and USRP2 decim. rate)
    If any control message is delivered, it update the control parameters. Otherwise, skips.
2. Tune the independent receiver module. This is a frontend of USRP2.
3. Flushing sample queue
4. Get the sample out of queue and send it over UDP

The program hangs between first and second buffer flushing after several days of continuous operation.
When it hangs, I figured out that the USRP2 does not send sample data to PC. (I confirmed it with wireshark.)

I attached the program to gdb and found out that the program is stuck waiting for the queue to be filled, as you see in the following gdb back-trace message.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
(gdb) info program
        Using the running image of attached LWP 28651.
Program stopped at 0xa08a32e9.
(gdb) bt
#0 0x00007f26a08a32e9 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
#1 0x00007f269f3ec9c0 in omni_condition::wait (this=<value optimized out>) at posix.cc:152
#2 0x00007f269f794c98 in gr_msg_queue::delete_head (this=0x2aea520) at gr_msg_queue.cc:81
#3 0x00007f269fa3b125 in gr_py_msg_queue__delete_head (q= {px = 0x7fffb561f150, pn = {pi_ = 0xffffffffffffffff}}) at gnuradio_swig_py_runtime.cc:4840
#4 0x00007f269fa43649 in _wrap_gr_py_msg_queue__delete_head (args=<value optimized out>, kwargs=<value optimized out>) at gnuradio_swig_py_runtime.cc:13477
#5 0x000000000041d3bd in PyObject_Call ()
#6 0x00000000004a1460 in PyEval_EvalFrameEx ()
#7 0x00000000004a4649 in PyEval_EvalCodeEx ()
#8 0x00000000004a2cb0 in PyEval_EvalFrameEx ()
#9 0x00000000004a3dae in PyEval_EvalFrameEx ()
#10 0x00000000004a4649 in PyEval_EvalCodeEx ()
#11 0x00000000004a4762 in PyEval_EvalCode ()
#12 0x00000000004c4c3c in PyRun_FileExFlags ()
#13 0x00000000004c4f6b in PyRun_SimpleFileExFlags ()
#14 0x00000000004189ce in Py_Main ()
#15 0x00007f269fca05a6 in __libc_start_main () from /lib/libc.so.6
#16 0x0000000000417ae9 in _start ()
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

So, I am suspicious if this is a problem caused simply by the USRP2 not sending data.
Is there anybody experienced similar case or having any idea?

Regards,

ILKYOUNG.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: problem of compiling FPGA bin files.

2009-12-03T13:59:31Z

Some people have had success with ISE 11.1, and some have not. I have
not tried it yet, and am still on 10.1.03 which is known to work. Early
in the new year I'll be moving to 11.1, but if anyone can figure out the
problems, that would be much appreciated.

Matt

On 12/01/2009 05:36 AM, 周亮 wrote:

>
> Hi,
> I tried to use Xilinx ISE 11.1 to open project
> "usrp2/fpga/top/u2_fpga/u2_fpga.ise".There are some files missing,such
> as"fifo_generator_4_1.v" . And there are errors when implement design...
>
> ==============================================
> ERROR:ConstraintSystem:59 - Constraint <NET "adc_a[0]" LOC = "A14" ;>
> [u2_fpga.ucf(1)]: NET "adc_a[0]" not found. Please verify that:
> 1. The specified design element actually exists in the original design.
> 2. The specified object is spelled correctly in the constraint source file.
> ...
> ERROR:ConstraintSystem:59 - Constraint <NET "clk_muxed" TNM_NET =
> "clk_muxed";>
> [u2_fpga.ucf(216)]: NET "clk_muxed" not found. Please verify that:
> 1. The specified design element actually exists in the original design.
> 2. The specified object is spelled correctly in the constraint source file.
> ...
> ERROR:ConstraintSystem:59 - Constraint <NET "ser_t<15>" IOSTANDARD =
> LVCMOS25
> |> [u2_fpga.ucf(336)]: NET "ser_t<15>" not found. Please verify that:
> 1. The specified design element actually exists in the original design.
> 2. The specified object is spelled correctly in the constraint source file.
> ...
> ERROR:ConstraintSystem:59 - Constraint <DRIVE = 12 |>
> [u2_fpga.ucf(336)]: NET "ser_t<15>" not found. Please verify that:
> 1. The specified design element actually exists in the original design.
> 2. The specified object is spelled correctly in the constraint source file.
> ...
> ERROR:ConstraintSystem:59 - Constraint <SLEW = FAST ;>
> [u2_fpga.ucf(336)]: NET "ser_t<15>" not found. Please verify that:
> 1. The specified design element actually exists in the original design.
> 2. The specified object is spelled correctly in the constraint source file.
> =========================================
>
> How could I fix it??
>
> Thanks!
>
> Liang
>
>
>
> ------------------------------------------------------------------------
> 使用Messenger保护盾2.0，支持多账号登录！现在就下载！
> <http://im.live.cn/safe/>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@...
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: USRP2 firmware + cross compiled GNU Radio question

2009-12-03T13:48:19Z

On 11/29/2009 04:52 AM, Tim Newman wrote:

>
>
> alfayez@... wrote:
>> Hi, I've been working on cross compiling the latest stable GNU Radio
>> release, 3.2.1, onto the TI Davinci DM6446 board using OpenEmbedded as
>> my build environment and Angstrom as my Linux Distro. I've managed to
>> cross compile and download gnuradio onto the board, though I'm going
>> with a console only Linux image so I don't have any of the gnuradio
>> python GUI stuff. Anyways, I am using a USRP2 and the board I'm using
>> doesn't have has 100T ethernet and not 1000T, so I'm using a
>> 1000/100/10T DLink switch to do the translation.
> First, maybe it was a mistype but the latest version of gnuradio is
> 3.2.2 not 3.2.1. Next, if you just want to test transmit, use
> usrp2_siggen.py.
>
> The USRP2 won't work unless you are using a GigE network card on the host.
> Matt has put together a new ethernet MAC here:
> http://gnuradio.org/trac/wiki/NewEthMAC
>
> I don't think this supports 10/100, maybe I'm wrong, but it may be worth
> trying.

We still require Gigabit.

Matt

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: Limited Rx BW on XCVR2450 daugtherboard

2009-12-03T13:30:12Z

Hanwen,

Thanks for confirming the fix. The slope you see with decimation 5 is
indeed the fault of the CIC. Because 5 is odd, we can't use a halfband
filter, and instead need to use the CIC for all decimation.

Decimation or Interpolation which is a multiple of 4 will be the
flattest, and multiples of 2 will be nearly as flat. Odd numbers will
always have that slope.

Matt

On 12/03/2009 06:10 AM, hanwen wrote:

> I've applied the fix to my receiver. It works. The attachment is the
> spectrum before and after the fixing at decimation rate 4 and 5. It
> shows at decimation rate of 4 the 3dB bandwidth is really widened from
> 7.5MHz to 9.5MHz.
> But when decimation rate is 5, the spectrum looks like an arch with over
> 10dB attenuation at age comparing with carrier center. I guess this
> imperfect frequency response is due to the CIC design. Is there a way of
> improve it?
>
> Thanks.
>
> 2009/11/26 Matt Ettus <matt@... <mailto:matt@...>>
>
>
> Thanks for finding this bug. I have applied your fix to my git
> repo. I'm away from any equipment right now, but if someone could
> confirm that this works, Johnathan can get it in the mainline code.
>
> Matt
>
>
>
> On 10/08/2009 01:26 PM, Stephen Lai wrote:
>
> Hi All,
>
> I've been having problems sending a 25 Msym/s BPSK stream
> between two
> USRP2's with XCVR2450 daughterboards. I've tracked it down to the Rx
> circuitry limiting the passband to ~14 MHz when at least 20 MHz
> should
> be available.
>
> Sifting through the db_xcvr2450.c/db_xcvr2450.cc files, I think
> there
> may be a bug which causes the baseband LPF in the MAX2829 device to
> cutoff at 7.5 MHz instead of 9.5 MHz when the board is
> configured for Rx.
>
> Referring to "LPF Register" on the MAX2829 datasheet, the old
> code...
>
> static void
> set_reg_lpf(struct db_xcvr2450_dummy *db){
> int reg_lpf = (
> (db->common->d_rssi_hbw<<15) |
> (db->common->d_txlpf_bw<<10) |
> (db->common->d_rxlpf_bw<<9) |
> (db->common->d_rxlpf_fine<<4) | 7);
> send_reg(reg_lpf);
> }
>
> ...seems like it should read...
>
> static void
> set_reg_lpf(struct db_xcvr2450_dummy *db){
> int reg_lpf = (
> (db->common->d_rssi_hbw<<15) |
> (db->common->d_txlpf_bw<<9) |
> (db->common->d_rxlpf_bw<<7) |
> (db->common->d_rxlpf_fine<<4) | 7);
> send_reg(reg_lpf);
> }
>
> ...to be set correctly.
>
> Has anybody else had problems with this? I'm using
> txrx_edk10.1_r11370.bin. I don't have Xilinx/EDK tools installed
> on my
> setup, but if someone is willing to build a load with the fix, I can
> test it out.
>
> thanks,
> Steve
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@... <mailto:Discuss-gnuradio@...>
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@... <mailto:Discuss-gnuradio@...>
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Require specification for the SMA Connector

2009-12-03T11:43:57Z

Hi All,

I am facing a problem with the type of SMA connector that needed to be connected on the USRP (Rev 4.5) mother board at the J2001 location for the clock input and J2002 for the clock output. It would be really helpful if anybody can provide me the exact specification for this connector and the type of cable to be used with it. I was looking to reuse the cable which I am presently using to connect the SMA connector on the Daughter board and the Antenna. Any help is appreciated.

Thanks & Regards,
Somya Ajmera

Get your preferred Email name!
Now you can @ymail.com and @rocketmail.com.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Flowgraph generates output even when the input exhausts

2009-12-03T09:16:01Z

Hi,
I developed a gnuradio block that takes 2 inputs. Input_01 is coming from a source that repeats and Input_02 is coming from a source that exhausts after a while. The output should only be generated when there is data on both the input lines. I see in my flowgraph that even when the data on input_02 exhausts output is still generated even though I see no problem with my C++ code. Its a simple operation in which for each input in Input_02 line the block outputs 'N' items from Input_01. Once, the data source (in this case is a file_source in non-repeat mode) for Input_02 exhausts i.e. the file is read completely the output should stop being generated as there is nothing coming on Input_02. I expect the previous data stored in the buffer for Input_02 is flushed by the scheduler after one work() cycle.

Any help would be appreciated.
Thanks,
Mir

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: GNUradio debugging and stepping

2009-12-03T09:02:26Z

Hi Jason

I've been wanting something like that also, and one of the tricks
that have been working well is to dump the streams to a file.
If you want to visualize everything in sync, you can interleave
samples from different points of the flow graph and sink it to a file.
You can use audacity to import the raw samples for easy visualization.
I'd be curious to know of other solutions for this.

Charles

On Thu, Dec 3, 2009 at 2:49 PM, Jason Uher <jasonuher@...> wrote:

> All,
>
> I was wondering if there was a simple method that allows someone to
> step through a gnuradio flow graph like you might when using a
> debugger. I have tried using gdb, but the swig/python stuff gives a
> whole lot of clutter.
>
> I'm not even sure it's possible given the way the gnuradio handles
> scheduling, but is there a way to build a graph and step through it
> sample by sample, watching the outputs from each block?
>
> Thanks,
> Jason
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@...
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

GNUradio debugging and stepping

2009-12-03T08:49:23Z

All,

I was wondering if there was a simple method that allows someone to
step through a gnuradio flow graph like you might when using a
debugger. I have tried using gdb, but the swig/python stuff gives a
whole lot of clutter.

I'm not even sure it's possible given the way the gnuradio handles
scheduling, but is there a way to build a graph and step through it
sample by sample, watching the outputs from each block?

Thanks,
Jason

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: Limited Rx BW on XCVR2450 daugtherboard

2009-12-03T06:14:23Z

2009/12/3 hanwen <kidult.hanwen@...>

I've applied the fix to my receiver. It works. The attachment is the spectrum before and after the fixing at decimation rate 4 and 5. It shows at decimation rate of 4 the 3dB bandwidth is really widened from 7.5MHz to 9.5MHz.
But when decimation rate is 5, the spectrum looks like an arch with over 10dB attenuation at age comparing with carrier center. I guess this imperfect frequency response is due to the CIC design. Is there a way of improve it?

Thanks.

2009/11/26 Matt Ettus <matt@...>

Thanks for finding this bug. I have applied your fix to my git repo. I'm away from any equipment right now, but if someone could confirm that this works, Johnathan can get it in the mainline code.

Matt

On 10/08/2009 01:26 PM, Stephen Lai wrote:

Hi All,

I've been having problems sending a 25 Msym/s BPSK stream between two
USRP2's with XCVR2450 daughterboards. I've tracked it down to the Rx
circuitry limiting the passband to ~14 MHz when at least 20 MHz should
be available.

Sifting through the db_xcvr2450.c/db_xcvr2450.cc files, I think there
may be a bug which causes the baseband LPF in the MAX2829 device to
cutoff at 7.5 MHz instead of 9.5 MHz when the board is configured for Rx.

Referring to "LPF Register" on the MAX2829 datasheet, the old code...

static void
set_reg_lpf(struct db_xcvr2450_dummy *db){
int reg_lpf = (
(db->common->d_rssi_hbw<<15) |
(db->common->d_txlpf_bw<<10) |
(db->common->d_rxlpf_bw<<9) |
(db->common->d_rxlpf_fine<<4) | 7);
send_reg(reg_lpf);
}

...seems like it should read...

static void
set_reg_lpf(struct db_xcvr2450_dummy *db){
int reg_lpf = (
(db->common->d_rssi_hbw<<15) |
(db->common->d_txlpf_bw<<9) |
(db->common->d_rxlpf_bw<<7) |
(db->common->d_rxlpf_fine<<4) | 7);
send_reg(reg_lpf);
}

...to be set correctly.

Has anybody else had problems with this? I'm using
txrx_edk10.1_r11370.bin. I don't have Xilinx/EDK tools installed on my
setup, but if someone is willing to build a load with the fix, I can
test it out.

thanks,
Steve

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

USRP2 Carrier Sensing using Raw Samples

2009-12-02T19:17:07Z

Hello,

I recently ran an experiment using the USRP2 to collect I&Q samples using usrp2_rx_cfile.py. I want to detect when the an 802.11b channel is busy using these raw samples.
I've seen the use of the filter y[n] = alpha*x[n] + (1-alpha)*y[n-1] with alpha as 0.001 in the carrier sensing BBN 802.11 code. The default threshold was set to 30 dB.
I've imported the data to Matlab and calculated the magnitude squared of each sample and ran it through this filter, but it appears that the data does not match the packets that I sent.

The carrier sensing code might correspond to the USRP, but are there any direct changes I would need to make for the USRP2 to use the carrier sensing code?

I've read through this post:
http://www.ruby-forum.com/topic/120841
but it deals with the USRP at the FPGA level.

Anyone have any suggestions?

Thanks,
Miklos Christine

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: failed to allocate buffer size error

2009-12-02T16:48:39Z

I think the same too. When I restarted the system it went through without a hitch. I am using Ubuntu 8.10, gnuradio 3.2, Intel Core 2 duo 2.0 Ghz/4MB cache computer with 2 GB RAM.

Thanks,
Mir

On Wed, Dec 2, 2009 at 6:39 PM, Eric Blossom <eb@...> wrote:

On Wed, Dec 02, 2009 at 04:20:16PM -0600, Mir M. Ali wrote:
> Hi,
> Why does this error occur when usrp_sink is replaced with a file_sink in
> the transmit_path?
>
> *gr_fir_fff: using SSE
> gr_vmcircbuf_sysv_shm: shmget (0): No space left on device
> gr_buffer::allocate_buffer: failed to allocate buffer of size 64 KB
> terminate called after throwing an instance of 'std::bad_alloc'
> what(): std::bad_alloc

> Aborted*
>

Sounds like your system is either out of memory (and/or swap), or that
the number of Sys V shared memory segments that is configured on your
system is small. What OS, version, distribution and CPU architecture
are you using?

If you run "make check" from the top of the GNU Radio tree, does it pass?
During the check, it allocates and frees many, many shared memory segments.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: failed to allocate buffer size error

2009-12-02T16:39:20Z

On Wed, Dec 02, 2009 at 04:20:16PM -0600, Mir M. Ali wrote:

> Hi,
> Why does this error occur when usrp_sink is replaced with a file_sink in
> the transmit_path?
>
> *gr_fir_fff: using SSE
> gr_vmcircbuf_sysv_shm: shmget (0): No space left on device
> gr_buffer::allocate_buffer: failed to allocate buffer of size 64 KB
> terminate called after throwing an instance of 'std::bad_alloc'
> what(): std::bad_alloc
> Aborted*
>

Sounds like your system is either out of memory (and/or swap), or that
the number of Sys V shared memory segments that is configured on your
system is small. What OS, version, distribution and CPU architecture
are you using?

If you run "make check" from the top of the GNU Radio tree, does it pass?
During the check, it allocates and frees many, many shared memory segments.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

failed to allocate buffer size error

2009-12-02T14:20:16Z

Hi,
Why does this error occur when usrp_sink is replaced with a file_sink in the transmit_path?

gr_fir_fff: using SSE
gr_vmcircbuf_sysv_shm: shmget (0): No space left on device
gr_buffer::allocate_buffer: failed to allocate buffer of size 64 KB
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted

I want to collect data after the rrc_filter in benchmark_tx as I have no USRP. How can I do this?

Thanks,
Mir

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Did you ever come across this type of error?

2009-12-02T14:13:02Z

Dear Dr. Daigle,
If you remember I told you that I rewrote the transmission side of my system such that there is no usrp involved. But this system doesn't work and it shows an error that I can't resolve. The error is as shown below,
gr_fir_fff: using SSE
gr_vmcircbuf_sysv_shm: shmget (0): No space left on device
gr_buffer::allocate_buffer: failed to allocate buffer of size 64 KB
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted

Apparently, this is due to failure in allocation of enough memory. When I commented out the lines in the original transmit_path.py that involves usrp and replaced the usrp_sink with a file_sink I get the same error. Any ideas?

I first tried to use your model of qa_test to write a transmitter but I am wasn't sure about the way to pass multiple packets to the message_queue. I may need some help on this.

Thanks,
Ali

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: gnuradio companion problem

2009-12-02T14:04:32Z

On Wed, Dec 02, 2009 at 08:57:58PM +0200, mehmet kabasakal wrote:

> Hi everyone,
>
> I am trying to run grc from the terminal. But when i type grc i got:
>
> mehmet@mehmet-laptop:~$ grc
> Traceback (most recent call last):
> File "/usr/bin/grc", line 48, in <module>
> from gnuradio.grc.python.Platform import Platform
> File "/usr/lib/python2.6/dist-packages/gnuradio/grc/python/Platform.py",
> line 22, in <module>
> from .. base.Platform import Platform as _Platform
> File "/usr/lib/python2.6/dist-packages/gnuradio/grc/base/Platform.py",
> line 22, in <module>
> from .. base import ParseXML, odict
> File "/usr/lib/python2.6/dist-packages/gnuradio/grc/base/ParseXML.py",
> line 20, in <module>
> from lxml import etree
> File "lxml.etree.pyx", line 188, in lxml.etree
> (src/lxml/lxml.etree.c:124917)
> LookupError: unknown encoding: ASCII
> Error in sys.excepthook:
> Traceback (most recent call last):
> File "/usr/lib/python2.6/dist-packages/apport_python_hook.py", line 38, in
> apport_excepthook
> from apport.packaging_impl import impl as packaging
> File "/usr/lib/python2.6/dist-packages/apport/__init__.py", line 1, in
> <module>
> from apport.report import Report
> File "/usr/lib/python2.6/dist-packages/apport/report.py", line 20, in
> <module>
> from problem_report import ProblemReport
> File "/usr/lib/python2.6/dist-packages/problem_report.py", line 17, in
> <module>
> from email.Encoders import encode_base64
> File "/usr/lib/python2.6/email/__init__.py", line 47, in <module>
> sys.setrecursionlimit(1500)
> NameError: name 'sys' is not defined
>
> Original exception was:
> Traceback (most recent call last):
> File "/usr/bin/grc", line 48, in <module>
> from gnuradio.grc.python.Platform import Platform
> File "/usr/lib/python2.6/dist-packages/gnuradio/grc/python/Platform.py",
> line 22, in <module>
> from .. base.Platform import Platform as _Platform
> File "/usr/lib/python2.6/dist-packages/gnuradio/grc/base/Platform.py",
> line 22, in <module>
> from .. base import ParseXML, odict
> File "/usr/lib/python2.6/dist-packages/gnuradio/grc/base/ParseXML.py",
> line 20, in <module>
> from lxml import etree
> File "lxml.etree.pyx", line 188, in lxml.etree
> (src/lxml/lxml.etree.c:124917)
> LookupError: unknown encoding: ASCII
>
> Do you have any idea about this?
> I use gnuradio 3.2.2 and ubuntu 9.04

I think somebody else reported something like this a week or two ago.
Can you try searching the archives. The problem might have been
the wrong version of lxml. Try searching for gnuradio+lxml+ascii

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: error of mapping when rebuild FPGA

2009-12-02T13:56:32Z

On Wed, Dec 02, 2009 at 10:06:41PM +0800, 周亮 wrote:
>
> with command
> gnuradio/usrp2/fpga/top/u2_rev3$ make bin

Matt can say more about this, but he's currently at the SDR Forum.
Please note that we've been using ISE 10.1 SP3(?) not 11.* to build
it. In our experience, the xilinx tools "leave something to be
desired..."

Can you try it with 10.1 with the latest service pack?

> I got errors when mapping:
> ERROR:Pack:2310 - Too many comps of type "RAMB16" found to fit this device.
> ERROR:Pack:18 - The design is too large for the given device and package.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.

2009-12-02T11:55:38Z

I have seen this error before on a fedora 11 system, reproducible too. If you make clean, make, and make install your from your source, and try again, it should go away. I have no idea why.

Also, I recommend using gnuradio 3.2 (or from the master) which comes with a way-newer version of grc.

-Josh

On Wed, Dec 2, 2009 at 10:16 AM, Johan Mussche <Johan.Mussche@...> wrote:

Hello everyone,

I am trying to use a SSRP with GNU-radio. In the past, with version 3.1 of gnuradio and GRC 0.69, the SSRP worked.

Now I am using the latest version of GNU-radio from the svn trunk in combination with swig 1.3.36 and python 2.6.
I have installed the ssrp-files into gnuradio and added the SSRP-block to GRC. Loading the firmware into the SSRP is no problem but
when I want to run the flow-graph I get the following error:

#####################################################################################

ssrp: firmware /usr/share/ssrp/firmware/rxS_512.ihx loaded successfully.
Traceback (most recent call last):
File "/root/Desktop/top_block.py", line 62, in <module>
tb = top_block()
File "/root/Desktop/top_block.py", line 52, in __init__
self.connect((self.ssrp_simple_source_x_0, 0), (self.gr_interleaved_short_to_complex_0, 0))
File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py", line 124, in connect
self._connect(points[i-1], points[i])
File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py", line 130, in _connect
dst_block.basic_block(), dst_port)
File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 1443, in connect
return _gnuradio_swig_py_runtime.gr_top_block_sptr_connect(*args)
NotImplementedError: Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.
Possible C/C++ prototypes are:
connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr)
connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr,int,gr_basic_block_sptr,int)

########################################################################################

I have also tried to to use the old GRC (0.69) but that gives the same error, so it has nothing to do with GRC.

Can anyone tell me the cause of this error. Is it because of the newer version of swig or gnuradio?

Best regards,

Johan

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

gnuradio companion problem

2009-12-02T10:57:58Z

Hi everyone,

I am trying to run grc from the terminal. But when i type grc i got:

mehmet@mehmet-laptop:~$ grc
Traceback (most recent call last):
File "/usr/bin/grc", line 48, in <module>
    from gnuradio.grc.python.Platform import Platform
File "/usr/lib/python2.6/dist-packages/gnuradio/grc/python/Platform.py", line 22, in <module>
    from .. base.Platform import Platform as _Platform
File "/usr/lib/python2.6/dist-packages/gnuradio/grc/base/Platform.py", line 22, in <module>
    from .. base import ParseXML, odict
File "/usr/lib/python2.6/dist-packages/gnuradio/grc/base/ParseXML.py", line 20, in <module>
    from lxml import etree
File "lxml.etree.pyx", line 188, in lxml.etree (src/lxml/lxml.etree.c:124917)
LookupError: unknown encoding: ASCII
Error in sys.excepthook:
Traceback (most recent call last):
File "/usr/lib/python2.6/dist-packages/apport_python_hook.py", line 38, in apport_excepthook
    from apport.packaging_impl import impl as packaging
File "/usr/lib/python2.6/dist-packages/apport/__init__.py", line 1, in <module>
    from apport.report import Report
File "/usr/lib/python2.6/dist-packages/apport/report.py", line 20, in <module>
    from problem_report import ProblemReport
File "/usr/lib/python2.6/dist-packages/problem_report.py", line 17, in <module>
    from email.Encoders import encode_base64
File "/usr/lib/python2.6/email/__init__.py", line 47, in <module>
    sys.setrecursionlimit(1500)
NameError: name 'sys' is not defined

Original exception was:
Traceback (most recent call last):
File "/usr/bin/grc", line 48, in <module>
    from gnuradio.grc.python.Platform import Platform
File "/usr/lib/python2.6/dist-packages/gnuradio/grc/python/Platform.py", line 22, in <module>
    from .. base.Platform import Platform as _Platform
File "/usr/lib/python2.6/dist-packages/gnuradio/grc/base/Platform.py", line 22, in <module>
    from .. base import ParseXML, odict
File "/usr/lib/python2.6/dist-packages/gnuradio/grc/base/ParseXML.py", line 20, in <module>
    from lxml import etree
File "lxml.etree.pyx", line 188, in lxml.etree (src/lxml/lxml.etree.c:124917)
LookupError: unknown encoding: ASCII

Do you have any idea about this?
I use gnuradio 3.2.2 and ubuntu 9.04

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: GNU Radio Meetup at SDR Forum

2009-12-02T08:05:16Z

I wanted to update everyone on the plans for the GNU Radio Meetup (or
the newly-named GNU Radio Summit '09) at the SDR Forum Technical
Conference that Matt announced last week.

We will be meeting tomorrow, Thursday Dec. 3 at the Hyatt in Crystal
City, Arlington, VA at 6 PM in Potomac 5 on the lower level. Everyone
in the area is invited to come, no need to be attending the SDR Forum
conference.

We will be at the Hyatt from 6 - 8 and then retire to a more relaxed
atmosphere (read: with beer) at Bailey's Pub on Crystal Dr.

Please come and join us if you can. We'd like to meet as many people
using or interested in GNU Radio as possible and discuss how we can
continue to advance and promote GNU Radio.

Tom

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

GNU Radio Meetup at SDR Forum 09

2009-12-02T07:23:32Z

An Update:

The GNU Radio Meetup at SDR Forum 2009 will be held this Thursday,
December 3rd, from 6-8 PM. The location is the Hyatt Regency Crystal City:

http://www.crystalcity.hyatt.com/groupbooking/wasrc1sdr2009

The room is "Potomac 5". You do NOT need to be registered for the
conference to attend this, so if you're in the area, please stop by.

Afterward we'll be heading over to a pub to continue the conversation.

If you're on Twitter, any last minute updates will be on @MattEttus.

Matt Ettus

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.

2009-12-02T07:16:30Z

Hello everyone,

I am trying to use a SSRP with GNU-radio. In the past, with version 3.1 of gnuradio and GRC 0.69, the SSRP worked.

Now I am using the latest version of GNU-radio from the svn trunk in combination with swig 1.3.36 and python 2.6.
I have installed the ssrp-files into gnuradio and added the SSRP-block to GRC. Loading the firmware into the SSRP is no problem but
when I want to run the flow-graph I get the following error:

#####################################################################################

ssrp: firmware /usr/share/ssrp/firmware/rxS_512.ihx loaded successfully.
Traceback (most recent call last):
File "/root/Desktop/top_block.py", line 62, in <module>
tb = top_block()
File "/root/Desktop/top_block.py", line 52, in __init__
self.connect((self.ssrp_simple_source_x_0, 0), (self.gr_interleaved_short_to_complex_0, 0))
File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py", line 124, in connect
self._connect(points[i-1], points[i])
File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py", line 130, in _connect
dst_block.basic_block(), dst_port)
File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 1443, in connect
return _gnuradio_swig_py_runtime.gr_top_block_sptr_connect(*args)
NotImplementedError: Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.
Possible C/C++ prototypes are:
connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr)
connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr,int,gr_basic_block_sptr,int)

########################################################################################

I have also tried to to use the old GRC (0.69) but that gives the same error, so it has nothing to do with GRC.

Can anyone tell me the cause of this error. Is it because of the newer version of swig or gnuradio?

Best regards,

Johan

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio