[Discuss-gnuradio] Memory oinking
I have a simple flow-graph, A USRP, single channel, and a large FFT block, followed by a vector to stream, and a file-output block. The FFT is 8M points, which for complex float samples, give something like a 64M memory footprint. But I'm finding that the virtual size of the resulting process is 4.5GB!, with an RSS of about 2.3G. This seems larger than you'd expect, by a fairly large factor! For comparison, I have a C program that processes the samples created by the Gnu Radio front end, which has: 120 8M buffers (unsigned char) 2 x 8M buffers (float) The virtual size of this process is only about 1G, with a similar RSS (it touches those buffers very regularly!). It seems to me that there only needs to be perhaps a couple of buffers per block inside Gnu Radio, which at worst gives you something like 8 complex buffers (about 64M per buffer for complex float) in my flow-graph. Why the massive hugeness in memory footprint? Now, I'll agree that memory is *cheap* these days, but scaling my application is going to be limited by what Gnu Radio is capable of, rather than my back-end C program. -- 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] What is occupied_tones concept?
Hi All, I am working on OFDM. The current OFDM implementation uses occupied_tones concept. Could anyone tell me what the occupied_tones concept is? How to get rid of the occupied_tones concept eventually? Thanks, Brook -- View this message in context: http://www.nabble.com/What-is-occupied_tones-concept--tp21732171p21732171.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] Memory oinking
On Thu, Jan 29, 2009 at 10:33:06AM -0500, Marcus D. Leech wrote: I have a simple flow-graph, A USRP, single channel, and a large FFT block, followed by a vector to stream, and a file-output block. The FFT is 8M points, which for complex float samples, give something like a 64M memory footprint. Sounds right. In the naive interface to FFTW we're using, I'm allocating additional input and output buffers for another 128M. I think I can get rid of that. But I'm finding that the virtual size of the resulting process is 4.5GB!, with an RSS of about 2.3G. That's big! This seems larger than you'd expect, by a fairly large factor! For comparison, I have a C program that processes the samples created by the Gnu Radio front end, which has: 120 8M buffers (unsigned char) 2 x 8M buffers (float) The virtual size of this process is only about 1G, with a similar RSS (it touches those buffers very regularly!). It seems to me that there only needs to be perhaps a couple of buffers per block inside Gnu Radio, which at worst gives you something like 8 complex buffers (about 64M per buffer for complex float) in my flow-graph. Why the massive hugeness in memory footprint? Not sure. Can you post a link to the code (or the code if it's small) and I'll take a look at it. Now, I'll agree that memory is *cheap* these days, but scaling my application is going to be limited by what Gnu Radio is capable of, rather than my back-end C program. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Memory oinking
Eric Blossom wrote: Not sure. Can you post a link to the code (or the code if it's small) and I'll take a look at it. http://www.sbrac.org/files/multi_fft_graph.py http://www.sbrac.org/files/multi_fft.grc I have enough CPU headroom that I could easily double the size of the FFT, but the memory footprint will be a big issue! -- 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
Re: [Discuss-gnuradio] help: cannot send after transport endpoint shutdown
On Thu, Jan 29, 2009 at 01:56:43PM +0800, Joreen Tan wrote: If i want the usrp to act as both of a transmitter and a receiver at one station, meaning i want the usrp to be able to transmit and receive at the same time, which file should i activate instead? Do you want to transmit and receive simultaneously or half-duplex? I was under the impression that you were trying to do half-duplex. Take a look at tunnel.py for a half-duplex example. I don't understand the following statement Auto T/R (Automatic Transmit/Receiver switching) handles it for you. With Auto T/R enabled, the receiver runs unless there are samples in the Transmit FIFO. This is handled in the FGPA, could you provide some sample code or example to illustrate how to achieve this See tunnel.py (it's got a lame MAC, but it demonstrates auto_tr). Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Exploring the world of GNU
On Wed, Jan 28, 2009 at 10:28:36PM -0800, Karthik wrote: Try the following: usrp_wfm_rcv.py -f 104.5 -O plughw:0,0 Be sure to provide the SI suffix on the freq otherwise it's going to try to tune to 104.5 Hz usrp_wfm_rcv.py -f 104.5M -O plughw:0,0 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio and Gumstix
On Thu, Jan 15, 2009 at 2:51 PM, Dan dan@gmail.com wrote: Hi, has anyone had success porting GNU Radio to Gumstix? I would like to install it on the Overo Earth board (OMAP 3503 with ARM Cortex-A8) if possible. I searched around but couldn't find much written about this. It would nice to connect Gumstix to the USRP at least. Any help would be appreciated, OK, I've updated oe.dev so that you can build gnuradio (r10302) with NEON implementation of the fff dotprod. I'm told the files should flow into the overo build system soon also. To build, (short form for people who can build their own sw), Edit the gnuradio_svn.bb and boost_1.36.bb files and comment out the DEFAULT_PREFERENCE=-1 lines with a #. bitbake gnuradio-image wait a long time. After you get it loaded, start testing :) dial_tone.py should work and the benchmark for the fff dotproduct should give you something like this: balis...@beagleboard:~/oe/tmp/work/armv7a-angstrom-linux-gnueabi/gnuradio-3.1.3+svnr10302-r6/trunk/gnuradio-core/src/tests$ ./benchmark_dotprod_fff generic: taps: 256 input: 4e+07 cpu: 1269.242 taps/sec: 8.068e+06 cortex_a8: taps: 256 input: 4e+07 cpu: 49.156 taps/sec: 2.083e+08 Note, I NFS mounted my home dir on teh beagle and ran the benchmark command on the build machine first. This needs work :) Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Exploring the world of GNU
ya I am using SI suffix for Mega Hz. But still not listening FM. no error appear except failed to set initial frequency. I have USRP with DBSRX daughter, and I have two SMA connector RF1 and RF2, actually this is already installed here and it has no LED on it.as these board supports 800MHz to 2.4 GHz. So is it possible to operate it on below 800 MHz like FM. Second I run usrp_oscope.py and usrp_siggen.py but it works only in the range 1.5GHz to 2.0 GHz. Can u explain the reasons. Thanks. 2009/1/30 Eric Blossom e...@comsec.com On Wed, Jan 28, 2009 at 10:28:36PM -0800, Karthik wrote: Try the following: usrp_wfm_rcv.py -f 104.5 -O plughw:0,0 Be sure to provide the SI suffix on the freq otherwise it's going to try to tune to 104.5 Hz usrp_wfm_rcv.py -f 104.5M -O plughw:0,0 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum recursion depth exceeded
On Wed, Jan 28, 2009 at 7:30 AM, Philip Balister philip.balis...@gmail.com wrote: r...@beagleboard:~# python /usr/share/gnuradio/examples/audio/dial_tone.py Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in type 'exceptions.AttributeError' ignored gr_vmcircbuf_createfilemapping: createfilemapping is not available gr_vmcircbuf_sysv_shm: shmat (3): Invalid argument This system runs python 2.6, if that makes a difference/ It does. Thanks for the report. We've put off testing with 2.6 bit it's apparent there are some issues. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Any implementation of Spread Spectrum
On Wed, Jan 28, 2009 at 9:31 AM, Mir Ali mirmurt...@gmail.com wrote: I want to know if ever any work was done on Spread Spectrum (DSSS) in Gnuradio? Yes. I have done both host code and FPGA code implementation of DSSS with the USRP1 and in progress with USRP2. These will eventually make into the public GNU Radio tree, but it might be some time before that happens. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DC offset problem on OOK modulation
Hi all, Now I'm working on OOK modulation/demodulation with RFX2400 d'board. I modified dbpsk.py and psk.py in order to get [1+0*j , 0+0*j] baseband signal and verified this signal is sending to USRP board. Since I'm using tx amplitude=14000, the range is [+14000,0] in real axis. But, I read this post releated with OOK modulation. http://www.nabble.com/On-Off-Keying-td19729627.html#a19746813 I cannot understand DC offset problem. As I know, the signal we transmit is s(t) = sqrt(2)*SI(t)*cos(2*pi*fc*t) - sqrt(2)*SQ(t)*sin(2*pi*fc*t); SI(t) and SQ(t) are the baseband signal we are feeding from PC to USRP, the range is [-32767,32767]. In OOK modulation, SI(t)=+14000 or 0, and SQ(t)=0 assuming that I do not use RRC filter. This signal will be passing through CIC in FPGA and feeded into AD9862. After that, it will be upconverted to carrier frequency. But after DUC, it might still be signed data. So I'm still confused of what the DC offset problem is. I have two questions, 1. Is it true that all bit streams handled in FPGA are signed data? 2. If yes, why do we experience DC offset problem? And in which stage is it occured? -- View this message in context: http://www.nabble.com/DC-offset-problem-on-OOK-modulation-tp21739169p21739169.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
[Discuss-gnuradio] Wideband RF Quadrature Modulator
I was looking through my Circuit Cellar magazine, and came across this 100MHz to 1GHz Quadrature Modulator: http://www.cmlmicro.com/Products/RF/CMX993.htm It even has programmable gain stages built in, so you don't have to play games scaling the IQ values on the host. Not too shabby! Just thought I'd share. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Any implementation of Spread Spectrum
These will eventually make into the public GNU Radio tree, but it might be some time before that happens. Are there CGRAN projects? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
