[Discuss-gnuradio] Re: Analysis_filterbank connect trouble
Hi I got my previous problem to work, so no need to respond. I needed to cast channel to an int. Thanks for any trouble. Sebastiaan On Mon, Jan 12, 2009 at 3:54 PM, Sebastiaan Heunis wrote: > Hi > > Thanks Eric for helping me with the analysis_filterbank and the fact > that all the channels up to the one that I'm interested in should be > connected to something. I do however have another problem now. I > have an app that allows me to pick a channel from a slider. The > slider goes from 1 to 20 (so it's channels 1 to 19)). This is the > slider's callback: > > def set_channel(self,channel): >self.lock() >self.disconnect_all() > >self.connect(self.source_i,(self.conv,0)) >self.connect(self.source_q,(self.conv,1)) >self.connect(self.conv,self.throttle) >self.connect(self.throttle,self.pfb) >self.connect(self.throttle,self.src_fft) > >chan_no = channel-1 >if (chan_no == 0): >self.connect((self.pfb,0),self.final_fft) >else: >for x in range(0,chan_no): > > self.connect((self.pfb,x),gr.null_sink(gr.sizeof_gr_complex)) >print x >self.connect((self.pfb,chan_no),self.final_fft) >self.unlock() > >self.myform['channel'].set_value(channel) >self.myform['channel_slider'].set_value(channel) > > I get the following error when changing the slider value: > > Traceback (most recent call last): > File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/form.py", > line 233, in >lambda evt: callback(self._map_out(evt.GetInt( > File "test_gui.py", line 100, in set_channel >self.connect((self.pfb,chan_no),self.final_fft) > File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py", > line 70, in connect >self._connect(points[i-1], points[i]) > File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py", > line 76, in _connect >dst_block.basic_block(), dst_port) > File > "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", > line 1493, 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_basic_block_sptr) >connect(boost::shared_ptr > *,gr_basic_block_sptr,int,gr_basic_block_sptr,int) > > Where line 100 is this: > > self.connect((self.pfb,chan_no),self.final_fft) > > Can anyone please help with this? > > Thanks a lot. > > Sebastiaan > > -- > Sebastiaan Heunis > Radar and Remote Sensing Group, University of Cape Town > Tel: +27 83 305 5667 > -- Sebastiaan Heunis Radar and Remote Sensing Group, University of Cape Town Tel: +27 83 305 5667 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_wfm_rcv.py and audio underrun aUaUaU
Thanks But it made no difference... /Mikael 2009/1/12 Johnathan Corgan > On Mon, Jan 12, 2009 at 11:19 AM, Mikael Johansson > wrote: > > > In my case CPU usage is below 100%. But I can try to disable OpenGL > anyway, > > how can I do that? > > In /etc/gnuradio/conf.d/gr-wxgui.conf, set the 'style' parameter to > 'nongl'. > > -Johnathan > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] uOuOuO what does it actually mean?
I've been having trouble sustaining decent receive speeds on one of my systems, despite the CPU being *fast*, it doesn't do as well as another system with a wimpier CPU, and slower memory. The system that doesn't do as well is ICH10-based for USB. The system with wimpier CPU has an ICH7-based USB subsystem. Yet the "wimpier" system does better at keeping up with USB data streams faster than 6.4Msps, which just leaves me scratching my head. The "wimpy" system (which does better at handling USB traffic) is a dual-core Pentium-D 925 @ 3.2Ghz, while the "killer" system is a Q6600 running at 3.6Ghz, with faster memory, dual-channel. Any clues? -- Marcus Leech Principal Investigator, Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question on OFDM
Hi All, I am working on OFDM. I use benchmark_ofdm_tx.py and benchmark_ofdm_rx.py to transmit and receive data right now. ./benchmark_ofdm_tx.py -f 440M -T A --tx-amplitude 5000 -v -i 128 --fft-length 128 --occupied-tones 80 --cp-length 32 ./benchmark_ofdm_rx.py -f 440M -R A -v -d 64 --fft-length 128 --occupied-tones 80 --cp-length 32 However, at the receiver side, I can not receive pkt=0 and pkt=1 every time. Most of the time, it receives from pkt=2. Can anyone tell me why is that and how to fix it, please? The second question is, at the TX side, TX actually transmits 503 pkt; but at the RX side, RX only receives part of these. The RX stops receiving when received pktno is 380. The third question is, why the value of decimation should be half of the value of interpolation? Thanks for any reply. Brook -- View this message in context: http://www.nabble.com/Question-on-OFDM-tp21428269p21428269.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Intel Atom is NICE.
I guess all's well that ends well. I have 64 bit Linux and Windows XP running on it. No hitches. I see what you are talking about. Bob On Sun, Jan 11, 2009 at 6:14 PM, Frank Brickle wrote: > > On Sun, Jan 11, 2009 at 3:00 PM, Bob McGwier wrote: > >> >> IF ANYONE CAN SHOW ME WHERE IN THE INSTRUCTIONS IT SAYS THIS IS A TWO PASS >> PROCESS OR WHERE DURING THE COURSE OF DOING THE FLASH IT SAYS THIS IS A >> TWO >> STEP PROCESS, I WOULD BE PLEASED TO BE TOLD I AM BLIND. > > Well, sort of. I'd posted a note about this somewhat in advance of yours, > with a link to the PDF directions. It's mentioned there that the update > takes a fair amount of time, at least 5 minutes, and the process isn't > complete if it hasn't taken that long. Nothing explicit about a two-step > process, though. Quite misleading. > > 73 > Frank > AB2KT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp<->gnuradio<->puredata
Welcome! On Sun, Jan 11, 2009 at 12:18:25PM +, [ Cosmin ] wrote: > > Dears,I would like to develop a patch in puredata [1] that offers > the possibility of using the USRP via GnuRadio trough interactive > programmed-object interface.For this, the GnuRadio GUI is not needed > (I presume), but I have to find out how It could be possible to > pilot every tasks normally provided by a GUI directly from puredata > (like in the way of WebSDR but with no GUI) . This shouldn't be a problem. GNU Radio is not dependent on any GUI. > There are several > "objects" in pd that coulb be used for that:- "netsend" and > "netreceive" via TCP/IP and UDP- pd-py (compiled via pd-flext) [at > this day I was not able to compile it on Debian nor OSX...work in > progress]Maybe netsend and netreceive could do that easely.But first > I would like to know if It's possible to make communicating GnuRadio > and puredata. Sounds possible. TCP, UDP or named pipes should work fine. > This developpment could be very useful for GnuRadio and > the USRP:- possibility to automatize every tasks to the USRP - > interactive processes- network connectivity using pd (like WebSDR > but without Java...)Maybe you can advice me or even work toghether > for the developpment of this project.Best regards,Cosmin[1] I suggest that you look at the interface provided by usrp_standard_rx and usrp_standard_tx. That would be the interface to use. http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/host/lib/legacy/usrp_standard.h http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/host/lib/legacy/usrp_basic.h The USRP FAQ will probably be helpful too: http://gnuradio.org/trac/wiki/UsrpFAQ Or (more or less equivalent) http://gnuradio.org/trac/attachment/wiki/UsrpFAQ/USRP_Documentation.pdf Thanks, Eric [Admin note: please don't post HTML mail to this list.] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: tun/tap OS X for tunneling
On Mon, Jan 12, 2009 at 12:48 PM, Michael Dickens wrote: > IMHO it would be unwise for any current GR component to be dependent on > "tuntaposx", since it's a non-standard addition to the OS (a kernel > extension, not just a library with headers and related files). Got it, it's what I figured. > If this were made into its own component (e.g., "gr-tuntap"), then I'd be > all for it. On Darwin, it would require tuntaposx to be installed, which > shouldn't be difficult to check for. On other platforms, checking might be > easier, but all of this would be done during configure via the config/*.m4 > scripts anyway. Agree. A short-term version would be a cross-platform object you could instantiate with an interface name to create and you'd get two gr.msg_queue's, one each for rx and tx packet data. It really calls for either an mblock (which exists), or the message passing extension to gr-blocks that we've been tossing around. > My US$.01 (during current economic crisis). - MLD The joys of fiat currency :) -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Mac OS X compilation errors
You should be able to bootstrap, configure, compile, check, install, and execute GR on MacOS X 10.4 and 10.5 (any sub-version of these), using any recent XCode tools for that platform (2.2 or newer on 10.4, 3.0 or newer on 10.5). This might mean assigning the "correct" compiler or various environment variables, but it can be done. Since neither posters indicated what the issue(s) was/were, it's difficult to provide any further info. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: tun/tap OS X for tunneling
On Jan 12, 2009, at 1:13 PM, Johnathan Corgan wrote: Not sure about the external dependency on the OS X kernel extension, however--perhaps some Mac users could comment on whether that creates an issue or not. IMHO it would be unwise for any current GR component to be dependent on "tuntaposx", since it's a non-standard addition to the OS (a kernel extension, not just a library with headers and related files). If this were made into its own component (e.g., "gr-tuntap"), then I'd be all for it. On Darwin, it would require tuntaposx to be installed, which shouldn't be difficult to check for. On other platforms, checking might be easier, but all of this would be done during configure via the config/*.m4 scripts anyway. My US$.01 (during current economic crisis). - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_wfm_rcv.py and audio underrun aUaUaU
On Mon, Jan 12, 2009 at 11:19 AM, Mikael Johansson wrote: > In my case CPU usage is below 100%. But I can try to disable OpenGL anyway, > how can I do that? In /etc/gnuradio/conf.d/gr-wxgui.conf, set the 'style' parameter to 'nongl'. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_wfm_rcv.py and audio underrun aUaUaU
On Sun, Jan 11, 2009 at 11:35 PM, Mikael Johansson wrote: > Below is a print-out with the verbose flag set to true. It appears that your audio system is working correctly. I've discovered I get something similar now on one of my test machines that uses Ubuntu 8.10 and an the nvidia graphics driver. Apparently, there is an odd interaction with OpenGL that raises CPU usage to 100%, which goes away when I turn off GL support in GNU Radio. Sound anything like what you're seeing? -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_wfm_rcv.py and audio underrun aUaUaU
In my case CPU usage is below 100%. But I can try to disable OpenGL anyway, how can I do that? Regards /Mikael 2009/1/12 Johnathan Corgan > On Sun, Jan 11, 2009 at 11:35 PM, Mikael Johansson > wrote: > > > Below is a print-out with the verbose flag set to true. > > It appears that your audio system is working correctly. > > I've discovered I get something similar now on one of my test machines > that uses Ubuntu 8.10 and an the nvidia graphics driver. Apparently, > there is an odd interaction with OpenGL that raises CPU usage to 100%, > which goes away when I turn off GL support in GNU Radio. Sound > anything like what you're seeing? > > -Johnathan > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recompile GNURadio
On Mon, Jan 12, 2009 at 12:04 AM, JALLON Pierre 201932 wrote: > I have modified the file usrp_basics.cc to make the soft prints some > information when running. > > When I recompile gnuradio, these modifications are not taken into account > (no information is printed). I have tried several tricks such as: > > Make uninstall > > Make clean > > before recompiling gnuradio but nothing worked. You need to do a 'make install' and possibly 'sudo ldconfig' for your compiled changes to become effective. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: tun/tap OS X for tunneling
On Sat, Jan 10, 2009 at 2:40 PM, Mark Kuhr wrote: > I think it is possible to create a cross-platform abstraction of this > functionality that manages the differences between the OSs. Maybe a tun/tap > module that is part of gnuradio, however the reliance on external pieces > such as the os x tun tap kernel extensions could be problematic. Might want > to roll that into the code base as well to maintain some control of the > versioning. If you'd like to work on this, we'd be happy to include it in the project, subject to GPL license and copyright assignment to FSF. Not sure about the external dependency on the OS X kernel extension, however--perhaps some Mac users could comment on whether that creates an issue or not. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Analysis_filterbank connect trouble
Hi Thanks Eric for helping me with the analysis_filterbank and the fact that all the channels up to the one that I'm interested in should be connected to something. I do however have another problem now. I have an app that allows me to pick a channel from a slider. The slider goes from 1 to 20 (so it's channels 1 to 19)). This is the slider's callback: def set_channel(self,channel): self.lock() self.disconnect_all() self.connect(self.source_i,(self.conv,0)) self.connect(self.source_q,(self.conv,1)) self.connect(self.conv,self.throttle) self.connect(self.throttle,self.pfb) self.connect(self.throttle,self.src_fft) chan_no = channel-1 if (chan_no == 0): self.connect((self.pfb,0),self.final_fft) else: for x in range(0,chan_no): self.connect((self.pfb,x),gr.null_sink(gr.sizeof_gr_complex)) print x self.connect((self.pfb,chan_no),self.final_fft) self.unlock() self.myform['channel'].set_value(channel) self.myform['channel_slider'].set_value(channel) I get the following error when changing the slider value: Traceback (most recent call last): File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/form.py", line 233, in lambda evt: callback(self._map_out(evt.GetInt( File "test_gui.py", line 100, in set_channel self.connect((self.pfb,chan_no),self.final_fft) File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py", line 70, in connect self._connect(points[i-1], points[i]) File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py", line 76, in _connect dst_block.basic_block(), dst_port) File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 1493, 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_basic_block_sptr) connect(boost::shared_ptr *,gr_basic_block_sptr,int,gr_basic_block_sptr,int) Where line 100 is this: self.connect((self.pfb,chan_no),self.final_fft) Can anyone please help with this? Thanks a lot. Sebastiaan -- Sebastiaan Heunis Radar and Remote Sensing Group, University of Cape Town Tel: +27 83 305 5667 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Mac OS X compilation errors
StormsShadow Silverlight wrote: > The hardware is a PPC Mac Mini, 1.42 GHz G4. It's running 10.4.8. > The XCode build is...actually 2.1 rather than 2.4.1, now that I look > at it. Let's upgrade that. > > ...And now it works! Splendid! What a stupid thing to miss. Thanks > a ton for pointing this out; otherwise I would have been confused for > quite a while. > > --Illix I have the same problem on iBook G4 1.33GHz 10.4.8 But my Xcode version is 2.5 So what I have to do? To downgrade to Xcode 2.4.1? Cosmin -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp-gnuradio-puredata
Dears,I would like to develop a patch in puredata [1] that offers the
possibility of using the USRP via GnuRadio trough interactive programmed-object
interface.For this, the GnuRadio GUI is not needed (I presume), but I have to
find out how It could be possible to pilot every tasks normally provided by a
GUI directly from puredata (like in the way of WebSDR but with no GUI) .There
are several "objects" in pd that coulb be used for that:- "netsend" and
"netreceive" via TCP/IP and UDP- pd-py (compiled via pd-flext) [at this day I
was not able to compile it on Debian nor OSX...work in progress]Maybe netsend
and netreceive could do that easely.But first I would like to know if It's
possible to make communicating GnuRadio and puredata.This developpment could be
very useful for GnuRadio and the USRP:- possibility to automatize every tasks
to the USRP - interactive processes- network connectivity using pd (like WebSDR
but without Java...)Maybe you can advice me or even work toghether for the
developpment of this project.Best regards,Cosmin[1] http://puredata.info/"Pd
(aka Pure Data) is a real-time graphical programming environmentfor audio,
video, and graphical processing. It is the third major branch of the family of
patcher programming languages known as Max (Max/FTS, ISPW Max, Max/MSP, jMax,
etc.) originally developed by Miller Puckette and company at IRCAM. The core of
Pd is written and maintained by Miller Puckette and includes the work of many
developers, making the whole package very much a community effort.Pd was
created to explore ideas of how to further refine the Max paradigm with the
core ideas of allowing data to be treated in a more open-ended way and opening
it up to applications outside of audio and MIDI, such as graphics and video.It
is easy to extend Pd by writing object classes ("externals") or patches
("abstractions"). The work of many developers is already available as part of
the standard Pd packages and the Pd developer community is growing rapidly.
Recent developments include a system of abstractionsfor building performance
environments; a library of objects for physical modeling; and a library of
objects for generating and processing video in realtime.Pd is free software and
can be downloaded either as an OS-specific package, source package, or directly
from CVS. Pd was written to be multi-platform and therefore is quite portable;
versions exist for Win32, IRIX, GNU/Linux, BSD, and MacOS X running on anything
from a PocketPC to an old Mac to a brand new PC. It is possible to write
externals and patches that work with Max/MSP and Pd using flext and cyclone."
_
Inédit ! Des Emoticônes Déjantées! Installez les dans votre Messenger !
http://www.ilovemessenger.fr/Emoticones/EmoticonesDejantees.aspx___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Recompile GNURadio
Dear all,
I have modified the file usrp_basics.cc to make the soft prints some
information when running.
When I recompile gnuradio, these modifications are not taken into
account (no information is printed). I have tried several tricks such
as:
Make uninstall
Make clean
before recompiling gnuradio but nothing worked.
Does anyone has one idea of how to do that ?
I give an example: In usrp_basic.cc, If I change
If (verbose)
{
Fprintf(blab la)
}
To
// if (verbose)
// {
Fprintf(blab la)
// }
The text is never print. But if I had in my python script
Self._u.set_verbose(True)
Then the text is printed. So it seems that when I compile gnuradio, my
modifications are not taken into account.
Thanks for your help,
Pierre Jallon
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
