[Discuss-gnuradio] introducing different modulation schemes for each sub carrier in ofdm
Hi, I am trying to implement ofdm transmission using gnu radio and I want to apply different modulation schemes for the different sub carriers. I believe the existing code does not support this. Can somebody point out the exact location in the source code which needs to be modified for the above purpose? Also, is switching on and off of sub carriers possible with the existing code? Thanks in advance, anma -- View this message in context: http://www.nabble.com/introducing-different-modulation-schemes-for-each-sub-carrier-in-ofdm-tp25450159p25450159.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] parallel programming with GNU radio (OpenMP vs MPI)
Hello Guys, I was wondering if any efforts have been made to apply parallel programming techniques in GNU radio projects. I have seen a project of building an OFDM transceiver using a cluster and MPI technique. However, in case of using laptops (where multicore shared memory architecture) instead of clusters, I think that OpenMP might be more applicable for codes that will run on laptop platforms. Any thoughts to share on this topic? Kind regards, Yahia Tachwali ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] about Bui lding GNU Radio System in Cygwin‏
Li Mei-Wen wrote: When I building a Full GNU Radio System (http://gnuradio.org/trac/wiki/CygwinInstallMain on windows) $ cd gnuradio-3.2 $ ./configure I get following error message. And I saw the other discuss, I also did the ./configure --prefix=$BOOST_PREFIX --with-libraries=thread,date_time,program_options on boost_1_36_0.. http://osdir.com/ml/discuss-gnuradio-gnu/2009-07/msg00098.html In the above in boost 1.36 on Cygwin it is mentioned,$ ./configure --with-libraries=thread,date_timefor the configure command. But while configuring I ended up with the following errorconfigure: error: Could not link against libboost_program_options!The solution to this problem is to use the following as a configure cmd.$ ./configure --prefix=$BOOST_PREFIX --with-libraries=thread,date_time,program_options But had the same error message... Did you repeat the make, make install, and cp steps for installing boost? Are the libboost_program_options files listed when you do ls /usr/local/lib/*boost*? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] about USRP2_MIN_RX_SAMPLES
Hi all! I ran into the constant USRP2_MIN_RX_SAMPLES = 371 defined in usrp2_base.h, but I don't get what it is used for (it comes with the comment BIG ASS FIXME: get from lower layer MTU calculation). Does anyone know anything about this constant and what it affects? ... what is depending on that it has the value 371? (I got seg faults when trying to run less than 371 items out of a USRP2 source block, I believe this constant has something to do with that perhaps?) Regards, /Ulrika ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Wireless sensors compatible with usrp
Hi all, I will be working on a project to study various distributed schemes in a wireless sensor network. Before starting I wanted to know few sensors compatible with usrp. I found few papers where authors used MICA2 and MICA z. I heard they are expensive. Can you give me an idea of the sensors compatible with the usrp, so that I can select the sensor within budget. I will be sensing temperature. Thanks. -- View this message in context: http://www.nabble.com/Wireless-sensors-compatible-with-usrp-tp25455371p25455371.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] about USRP2_MIN_RX_SAMPLES
Ulrika Uppman wrote: Hi all! I ran into the constant USRP2_MIN_RX_SAMPLES = 371 defined in usrp2_base.h, but I don't get what it is used for (it comes with the comment BIG ASS FIXME: get from lower layer MTU calculation). Does anyone know anything about this constant and what it affects? ... what is depending on that it has the value 371? (I got seg faults when trying to run less than 371 items out of a USRP2 source block, I believe this constant has something to do with that perhaps?) I think it had something to do with 371items*4bytes = 1484 bytes. I think it was excluding the header, which I can't remember the exact size of on top of my head. But I have a feeling that the size of a packet was 1498 bytes or so. I have a feeling that I sent a code- snippet to Eric Blossom last summer which read/re- wrote the MTU of the NIC, but as he pointed out, the code should work on a whole bunch of platforms and systems. The code should work in most cases, since MTU=1500 is more or less standard, except some odd cards which have 1400 bytes MTU. I think it was set to 371 in order to minimize overhead. //Mattias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using SPI on BasicRX
Thanks for the help.
I have another question:
I noticed that the transfer is done 8-bit at a time.
I need to write a 24-bit word into a ADF4153 Frequency Synthesizer.
Is it possible to transfer 24-bit in a single burst?
Again, thank you for your time.
Eric Blossom wrote:
On Mon, Sep 14, 2009 at 11:02:36AM -0700, E. Ornelas wrote:
Hello.
I'm trying to use the SPI interface of a BasicRX.
I made a small test program.
It basically keeps on writing.
There are a few things I need to know:
1 - is this the right way to use the SPI?
Pretty close. See below.
2 - is the buffer the hex number passed as a string?
It's binary, not hex.
3 - Even though I don't know what to expect with the buffer I used, I at
least expected to see something in the BasicRX SPI pins, which I don't...
I
can see some periodic bursts on the clock pin but nothing on the signal.
We never implemented SPI_FMT_LSB; Use SPI_FMT_MSB instead.
Try this:
from gnuradio import usrp
u = usrp.source_c(0)
spi_cmd = ''.join([chr(x) for x in [0x55, 0xAA, 0x55, 0xAA]])
while True:
r = u._write_spi(0, usrp.SPI_ENABLE_RX_A,
usrp.SPI_FMT_HDR_0|usrp.SPI_FMT_MSB, spi_cmd)
Look at the SDI (into the d'board), SCLK and SEN pins.
Eric
Thanks in advance for any help you can give me.
The code I'm using is the one below:
from gnuradio import gr
from gnuradio import window
from gnuradio import usrp, howto
import wx
import time
from gnuradio import audio
class FlowGraph(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
decimation = 256
center_frequency = 10.7e6
self.u = usrp.source_c(0, decimation,
fpga_filename=std_2rxhb_2tx.rbf)
self.u.set_nchannels(1)
self.subdev_spec = (0,0)
self.subdev = usrp.selected_subdev(self.u, self.subdev_spec)
self.subdev.set_auto_tr(True)
self.subdev.select_rx_antenna('RX2')
self.u.tune(0, self.subdev, center_frequency)
g = self.subdev.gain_range()
gain = float(g[0]+g[1])/2
self.subdev.set_gain(gain)
if __name__ == __main__:
print Creating flowgraph... ,
tb = TunerFlowGraph()
print [DONE]
print Starting flowgraph...,
tb.start()
print [DONE]
while(1):
print Writing to SPI...,
usrp.sink_s()._write_spi(0, usrp.SPI_ENABLE_RX_A,
usrp.SPI_FMT_HDR_0|usrp.SPI_FMT_LSB, @)
time.sleep(.030)
print [DONE]
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
View this message in context:
http://www.nabble.com/Using-SPI-on-BasicRX-tp25440578p25456853.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] parallel programming with GNU radio (OpenMP vs MPI)
On Tue, Sep 15, 2009 at 04:39:49AM -0500, Tachwali, Yahia wrote: Hello Guys, I was wondering if any efforts have been made to apply parallel programming techniques in GNU radio projects. I have seen a project of building an OFDM transceiver using a cluster and MPI technique. However, in case of using laptops (where multicore shared memory architecture) instead of clusters, I think that OpenMP might be more applicable for codes that will run on laptop platforms. Any thoughts to share on this topic? Yes, we are currently applying parallel programming techinques in GNU Radio. Depending on the details of the flow graph that you executing, we have seen near linear scaling up to 24 cores (quad 6-core). This has been done in a way that is completely transparent to the applications themselves. (At this point, we assign a thread per gr_block in the graph). OpenMP may help at some point, but I'm not sure. You'd have to run some experiments and see if using it does better than what we've currently got. In a cluster, you start running into interconnect capacity issues for many graphs. Again it depends on what you're doing, but a single 30MS/s stream (16-bit I Q) will saturate a gigabit connection. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] about USRP2_MIN_RX_SAMPLES
On Tue, Sep 15, 2009 at 04:41:39PM +0200, Ulrika Uppman wrote: Hi all! I ran into the constant USRP2_MIN_RX_SAMPLES = 371 defined in usrp2_base.h, but I don't get what it is used for (it comes with the comment BIG ASS FIXME: get from lower layer MTU calculation). I believe you're referring to USRP2_MAX_RX_SAMPLES. It's the largest number of samples that will fit in a 1500 byte ethernet packet including overhead. The constant sizes some structures. (BTW, it was recently adjusted downward to 370 samples to ensure alignment for dual channel apps). Does anyone know anything about this constant and what it affects? ... what is depending on that it has the value 371? (I got seg faults when trying to run less than 371 items out of a USRP2 source block, I believe this constant has something to do with that perhaps?) How we're you trying to do this? Hint: don't change the constant. We don't currently expose this in the gr-usrp2 interface. We do expose it in the usrp2::usrp2::start_rx_streaming interface. items_per_frame = 0 gets you the default (currently 370 or 371 depending on rev). You can set it lower if you like. usrp2_source_base::start currently passes 0 to get the default. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using SPI on BasicRX
On Tue, Sep 15, 2009 at 09:06:58AM -0700, E. Ornelas wrote: Thanks for the help. I have another question: I noticed that the transfer is done 8-bit at a time. I need to write a 24-bit word into a ADF4153 Frequency Synthesizer. Is it possible to transfer 24-bit in a single burst? The example below writes 32 bits in a single transfer. You can confirm this by looking at the SEN and CLK signals. To send 24-bits, give it 3 bytes. Eric Again, thank you for your time. Eric Blossom wrote: On Mon, Sep 14, 2009 at 11:02:36AM -0700, E. Ornelas wrote: Hello. I'm trying to use the SPI interface of a BasicRX. I made a small test program. It basically keeps on writing. There are a few things I need to know: 1 - is this the right way to use the SPI? Pretty close. See below. 2 - is the buffer the hex number passed as a string? It's binary, not hex. 3 - Even though I don't know what to expect with the buffer I used, I at least expected to see something in the BasicRX SPI pins, which I don't... I can see some periodic bursts on the clock pin but nothing on the signal. We never implemented SPI_FMT_LSB; Use SPI_FMT_MSB instead. Try this: from gnuradio import usrp u = usrp.source_c(0) spi_cmd = ''.join([chr(x) for x in [0x55, 0xAA, 0x55, 0xAA]]) while True: r = u._write_spi(0, usrp.SPI_ENABLE_RX_A, usrp.SPI_FMT_HDR_0|usrp.SPI_FMT_MSB, spi_cmd) Look at the SDI (into the d'board), SCLK and SEN pins. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Disabling the usrp2 in configure
I'm trying to disable the configure stuff for the USRP2 by passing --disable-usrp2 to the configure script. Unfortunately, the usrp2/firmware script is still trying to run. This dies when I am trying to cross compile the code. For the OMAP3, I have no gig-E so I just want the usrp2 stuff out of the way. What is the best way to force the usrp2 configure stuff not to run at all? I've pasted the error from config.log at the bottom of the email. Philip config.status:2173: executing run_tests_sdl commands config.status:2173: executing run_tests_sounder commands config.status:2173: executing run_tests_build commands configure:50300: === configuring in usrp2/firmware (/home/balister/oe/tmp/work/a rmv7a-angstrom-linux-gnueabi/gnuradio-3.2.1-r7.1+gitr9d2c4b0625dac26c86974453518 aa5b034fc849e-r7.1/git/usrp2/firmware) configure:50403: running /bin/sh ./configure.gnu --disable-option-checking '--pr efix=/usr' '--build=x86_64-linux' '--host=armv7a-angstrom-linux-gnueabi' '--tar get=arm-angstrom-linux-gnueabi' '--exec_prefix=/usr' '--bindir=/usr/bin' '--sbin dir=/usr/sbin' '--libexecdir=/usr/libexec' '--datadir=/usr/share' '--sysconfdir= /etc' '--sharedstatedir=/usr/com' '--localstatedir=/var' '--libdir=/usr/lib' '-- includedir=/usr/include' '--oldincludedir=/usr/include' '--infodir=/usr/share/in fo' '--mandir=/usr/share/man' '--program-prefix=' '--with-md-cpu=arm' '--disable -gr-atsc' '--enable-gr-video-sdl' '--enable-gr-audio-alsa' '--enable-gr-audio-ja ck' '--enable-gr-audio-oss' '--enable-mblock' '--disable-html-docs' '--with-pyth ondir=/usr/lib/python2.6/site-packages' 'PYTHON_CPPFLAGS=-I/home/balister/oe/tmp /staging/armv7a-angstrom-linux-gnueabi/usr/include/python2.6' '--with-boost=/hom e/balister/oe/tmp/staging/armv7a-angstrom-linux-gnueabi/usr' 'CXXFLAGS=-DBOOST_S P_USE_PTHREADS' '--disable--usrp2' 'build_alias=x86_64-linux' 'host_alias=armv7a -angstrom-linux-gnueabi' 'target_alias=arm-angstrom-linux-gnueabi' 'CC=ccache ar m-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat- abi=softfp' 'CFLAGS=-isystem/home/balister/oe/tmp/staging/armv7a-angstrom-linux- gnueabi/usr/include -O -fno-omit-frame-pointer -g' 'LDFLAGS=-L/home/balister/oe/ tmp/staging/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-rpath-link,/home/balister /oe/tmp/staging/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-O1 -Wl,--hash-style=g nu' 'CPPFLAGS=-isystem/home/balister/oe/tmp/staging/armv7a-angstrom-linux-gnueab i/usr/include' 'CPP=arm-angstrom-linux-gnueabi-gcc -E' 'CXX=ccache arm-angstrom- linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp' 'F77=ccache arm-angstrom-linux-gnueabi-g77 -march=armv7-a -mtune=cortex-a8 -mfp u=neon -mfloat-abi=softfp' 'USB_LIBS=-L/home/balister/oe/tmp/work/armv7a-angstro m-linux-gnueabi/gnuradio-3.2.1-r7.1+gitr9d2c4b0625dac26c86974453518aa5b034fc849e -r7.1/libusb-0.1.12/.libs/ -l:libusb-gnur.a' --cache-file=/dev/null --srcdir=. configure:50408: error: ./configure.gnu failed for usrp2/firmware ## ## smime.p7s Description: S/MIME Cryptographic Signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wireless sensors compatible with usrp
Micaz work in the 2.4 Ghz band so i guess if you are using a daughterboard that work in that frequency band then that should work. Check this out. https://www.cgran.org/wiki/UCLAZigBee In the US this specification adheres to the 2.4 GHz band. Thanks, Mir On Tue, Sep 15, 2009 at 9:45 AM, tronix bhargava...@gmail.com wrote: Hi all, I will be working on a project to study various distributed schemes in a wireless sensor network. Before starting I wanted to know few sensors compatible with usrp. I found few papers where authors used MICA2 and MICA z. I heard they are expensive. Can you give me an idea of the sensors compatible with the usrp, so that I can select the sensor within budget. I will be sensing temperature. Thanks. -- View this message in context: http://www.nabble.com/Wireless-sensors-compatible-with-usrp-tp25455371p25455371.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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Disabling the usrp2 in configure
On Tue, Sep 15, 2009 at 13:57, Philip Balister phi...@balister.org wrote: I'm trying to disable the configure stuff for the USRP2 by passing --disable-usrp2 to the configure script. Unfortunately, the usrp2/firmware script is still trying to run. This dies when I am trying to cross compile the code. For the OMAP3, I have no gig-E so I just want the usrp2 stuff out of the way. configure --disable-usrp2 --disable-usrp2-firmware Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Disabling the usrp2 in configure
On Tue, Sep 15, 2009 at 04:57:32PM -0400, Philip Balister wrote: I'm trying to disable the configure stuff for the USRP2 by passing --disable-usrp2 to the configure script. Unfortunately, the usrp2/firmware script is still trying to run. This dies when I am trying to cross compile the code. For the OMAP3, I have no gig-E so I just want the usrp2 stuff out of the way. OK. From the log below it looks like you passed --disable--usrp2 (two dashes) instead of --disable-usrp2 (one dash). What is the best way to force the usrp2 configure stuff not to run at all? I've pasted the error from config.log at the bottom of the email. Philip If that doesn't fix it, write again. I've got some more ideas. Eric config.status:2173: executing run_tests_sdl commands config.status:2173: executing run_tests_sounder commands config.status:2173: executing run_tests_build commands configure:50300: === configuring in usrp2/firmware (/home/balister/oe/tmp/work/a rmv7a-angstrom-linux-gnueabi/gnuradio-3.2.1-r7.1+gitr9d2c4b0625dac26c86974453518 aa5b034fc849e-r7.1/git/usrp2/firmware) configure:50403: running /bin/sh ./configure.gnu --disable-option-checking '--pr efix=/usr' '--build=x86_64-linux' '--host=armv7a-angstrom-linux-gnueabi' '--tar get=arm-angstrom-linux-gnueabi' '--exec_prefix=/usr' '--bindir=/usr/bin' '--sbin dir=/usr/sbin' '--libexecdir=/usr/libexec' '--datadir=/usr/share' '--sysconfdir= /etc' '--sharedstatedir=/usr/com' '--localstatedir=/var' '--libdir=/usr/lib' '-- includedir=/usr/include' '--oldincludedir=/usr/include' '--infodir=/usr/share/in fo' '--mandir=/usr/share/man' '--program-prefix=' '--with-md-cpu=arm' '--disable -gr-atsc' '--enable-gr-video-sdl' '--enable-gr-audio-alsa' '--enable-gr-audio-ja ck' '--enable-gr-audio-oss' '--enable-mblock' '--disable-html-docs' '--with-pyth ondir=/usr/lib/python2.6/site-packages' 'PYTHON_CPPFLAGS=-I/home/balister/oe/tmp /staging/armv7a-angstrom-linux-gnueabi/usr/include/python2.6' '--with-boost=/hom e/balister/oe/tmp/staging/armv7a-angstrom-linux-gnueabi/usr' 'CXXFLAGS=-DBOOST_S P_USE_PTHREADS' '--disable--usrp2' 'build_alias=x86_64-linux' 'host_alias=armv7a -angstrom-linux-gnueabi' 'target_alias=arm-angstrom-linux-gnueabi' 'CC=ccache ar m-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat- abi=softfp' 'CFLAGS=-isystem/home/balister/oe/tmp/staging/armv7a-angstrom-linux- gnueabi/usr/include -O -fno-omit-frame-pointer -g' 'LDFLAGS=-L/home/balister/oe/ tmp/staging/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-rpath-link,/home/balister /oe/tmp/staging/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-O1 -Wl,--hash-style=g nu' 'CPPFLAGS=-isystem/home/balister/oe/tmp/staging/armv7a-angstrom-linux-gnueab i/usr/include' 'CPP=arm-angstrom-linux-gnueabi-gcc -E' 'CXX=ccache arm-angstrom- linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp' 'F77=ccache arm-angstrom-linux-gnueabi-g77 -march=armv7-a -mtune=cortex-a8 -mfp u=neon -mfloat-abi=softfp' 'USB_LIBS=-L/home/balister/oe/tmp/work/armv7a-angstro m-linux-gnueabi/gnuradio-3.2.1-r7.1+gitr9d2c4b0625dac26c86974453518aa5b034fc849e -r7.1/libusb-0.1.12/.libs/ -l:libusb-gnur.a' --cache-file=/dev/null --srcdir=. configure:50408: error: ./configure.gnu failed for usrp2/firmware ## ## ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Disabling the usrp2 in configure
Eric Blossom wrote: On Tue, Sep 15, 2009 at 04:57:32PM -0400, Philip Balister wrote: I'm trying to disable the configure stuff for the USRP2 by passing --disable-usrp2 to the configure script. Unfortunately, the usrp2/firmware script is still trying to run. This dies when I am trying to cross compile the code. For the OMAP3, I have no gig-E so I just want the usrp2 stuff out of the way. OK. From the log below it looks like you passed --disable--usrp2 (two dashes) instead of --disable-usrp2 (one dash). What is the best way to force the usrp2 configure stuff not to run at all? I've pasted the error from config.log at the bottom of the email. Philip If that doesn't fix it, write again. I've got some more ideas. Fixing the typo (the problem with automation, it preserves your mistakes across runs) and adding the --disable-usrp2-firmware did not help. The log is at the bottom of the email. Patching out the GRC_GR_USRP2 line solves the problem, but I do not want to carry this patch around anymore. I'll be glad to look at your suggestions in the morning! Philip config.status:2173: executing run_tests_sounder commands config.status:2173: executing run_tests_build commands configure:50300: === configuring in usrp2/firmware (/home/balister/oe/tmp/work/a rmv7a-angstrom-linux-gnueabi/gnuradio-3.2.1-r7.1+gitr9d2c4b0625dac26c86974453518 aa5b034fc849e-r7.1/git/usrp2/firmware) configure:50403: running /bin/sh ./configure.gnu --disable-option-checking '--pr efix=/usr' '--build=x86_64-linux' '--host=armv7a-angstrom-linux-gnueabi' '--tar get=arm-angstrom-linux-gnueabi' '--exec_prefix=/usr' '--bindir=/usr/bin' '--sbin dir=/usr/sbin' '--libexecdir=/usr/libexec' '--datadir=/usr/share' '--sysconfdir= /etc' '--sharedstatedir=/usr/com' '--localstatedir=/var' '--libdir=/usr/lib' '-- includedir=/usr/include' '--oldincludedir=/usr/include' '--infodir=/usr/share/in fo' '--mandir=/usr/share/man' '--program-prefix=' '--with-md-cpu=arm' '--disable -gr-atsc' '--enable-gr-video-sdl' '--enable-gr-audio-alsa' '--enable-gr-audio-ja ck' '--enable-gr-audio-oss' '--enable-mblock' '--disable-html-docs' '--with-pyth ondir=/usr/lib/python2.6/site-packages' 'PYTHON_CPPFLAGS=-I/home/balister/oe/tmp /staging/armv7a-angstrom-linux-gnueabi/usr/include/python2.6' '--with-boost=/hom e/balister/oe/tmp/staging/armv7a-angstrom-linux-gnueabi/usr' 'CXXFLAGS=-DBOOST_S P_USE_PTHREADS' '--disable-usrp2' '--disable-usrp2-firmware' 'build_alias=x86_64 -linux' 'host_alias=armv7a-angstrom-linux-gnueabi' 'target_alias=arm-angstrom-li nux-gnueabi' 'CC=ccache arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cor tex-a8 -mfpu=neon -mfloat-abi=softfp' 'CFLAGS=-isystem/home/balister/oe/tmp/stag ing/armv7a-angstrom-linux-gnueabi/usr/include -O -fno-omit-frame-pointer -g' 'LD FLAGS=-L/home/balister/oe/tmp/staging/armv7a-angstrom-linux-gnueabi/usr/lib -Wl, -rpath-link,/home/balister/oe/tmp/staging/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-O1 -Wl,--hash-style=gnu' 'CPPFLAGS=-isystem/home/balister/oe/tmp/staging/ar mv7a-angstrom-linux-gnueabi/usr/include' 'CPP=arm-angstrom-linux-gnueabi-gcc -E' 'CXX=ccache arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfp u=neon -mfloat-abi=softfp' 'F77=ccache arm-angstrom-linux-gnueabi-g77 -march=arm v7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp' 'USB_LIBS=-L/home/balister/ oe/tmp/work/armv7a-angstrom-linux-gnueabi/gnuradio-3.2.1-r7.1+gitr9d2c4b0625dac2 6c86974453518aa5b034fc849e-r7.1/libusb-0.1.12/.libs/ -l:libusb-gnur.a' --cache-f ile=/dev/null --srcdir=. configure:50408: error: ./configure.gnu failed for usrp2/firmware smime.p7s Description: S/MIME Cryptographic Signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ./usrp_rx_cfile capture and ./benchmark_rx capture differs in bit-rate set even with same parameters
Dear list, I have a question. I just want to make sure I am not hallucinating infront of my comp here. I run this script as follows: 1. ./usrp_rx_cfile.py -f 2.4G -d 128 foo.dat @ the receiver = I get, the bitrate set to 500k But, when I run this script as follows: 2. //benchmark_rx.py -f 2.4G -d 128 @ the receiver = I get the bitrate set to 250k. Even though, both has decimate rate set to the same, 128. Problem is, I am running ./benchmark_tx.py -f 2.4G -i 256 --from-file=foo.txt on the receiver side, and it sets my bitrate to 250k as expected. I would like to get the same bitrate at the receiver side when running usrp_rx_cfile capture [see 1], with (interpolation/decimate) still being equal to 2. Because I want 2 samples per symbol. Can somebody tell me if there is anything obvious about this that i am doing wrong or a parameter configuration that I can pass which will do what i need. Let me know if I need to give more details of the purpose. Thank you very much. Sincerely, ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ./usrp_rx_cfile capture and ./benchmark_rx capture differs in bit-rate set even with same parameters
On Tue, Sep 15, 2009 at 07:17:45PM -0400, Bishal Thapa wrote: Dear list, I have a question. I just want to make sure I am not hallucinating infront of my comp here. I run this script as follows: 1. ./usrp_rx_cfile.py -f 2.4G -d 128 foo.dat @ the receiver = I get, the bitrate set to 500k It looks like you are confusing bitrate and sample rate. There's no bitrate with usrp_rx_cfile. What you get is a sample rate of 500k samples/s But, when I run this script as follows: 2. //benchmark_rx.py -f 2.4G -d 128 @ the receiver = I get the bitrate set to 250k. By default you're using BPSK (1 bit / symbol), but the receiver needs at least two samples / symbol to handle synchronization issues. Thus you've got a baseband sample rate of 500kS/s, but a bit rate of 250kb/s Even though, both has decimate rate set to the same, 128. Problem is, I am running ./benchmark_tx.py -f 2.4G -i 256 --from-file=foo.txt on the receiver side, and it sets my bitrate to 250k as expected. I would like to get the same bitrate at the receiver side when running usrp_rx_cfile capture [see 1], with (interpolation/decimate) still being equal to 2. Because I want 2 samples per symbol. Can somebody tell me if there is anything obvious about this that i am doing wrong or a parameter configuration that I can pass which will do what i need. Let me know if I need to give more details of the purpose. Thank you very much. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] introducing different modulation schemes for each sub carrier in ofdm
anma wrote: Hi, I am trying to implement ofdm transmission using gnu radio and I want to apply different modulation schemes for the different sub carriers. I believe the existing code does not support this. Can somebody point out the exact location in the source code which needs to be modified for the above purpose? Also, is switching on and off of sub carriers possible with the existing code? Thanks in advance, anma Look in gr_ofdm_mapper_bcv and gr_ofdm_demapper_vcb. Others have worked on this problem, too. Has anyone successfully implemented it, yet? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] newbe question
Steve Mitan wrote: Hi all I am new at this and slowly learning Linux, GNU and GNU Radio. In following the installation instructions for GNU Radio Release 3.2, I got as far as Now edit qwtconfig.pri: and have come to standstill. I can't figure out this step. I am sure it is elementary to the rest of you but it has brought me to a stop. Can anyone explain this step in detail? Thank you very much Steve Keep in mind, Steve, that the Qt interface is optional. I'm partial to it, but if you're having problems with it, you can go on and ignore if for now until you get more comfortable. I've never been pleased with the installation of Qwt (and QwtPlot3d) and I hope they make a more friendly/standard installation process soon. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Daughterboards to benchmark tx and rx
Dinart Duarte Braga wrote: Hello, I'm developing a software based on the code of benchmark_tx and benchmark_rx, one of the differences is that it will also work with other modulations, like dqpsk and d8psk. The readme file of the benchmark program suggests the RFX daughterboards to establish a link between two USRP1's. I don't have such boards yet but I do have the basic TX and RX boards (no antenna yet), couldn't I use them to run the benchmark? What level of SNR the basic TX/RX boards can achieve if they are close(~2m) to each other? Thanks in advance, Dinart Yes, you can use the BasicTX/RX boards for running these scripts. I can't tell you the actual SNR you'll achieve, but some basic antennas at 2m should get you up and running. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 Sample 2.4 GHz Channel
Hello,
I'm trying to sample the 802.11b wireless channels but the USRP2. I'm
currently using revision 10689 of Gnuradio.
I've added code to bbn_80211b_rx.py to connect the gr_probe_signal_f() to
the top block.
To sample the channel, I use gr.probe_signal_f().
Here's the code to connect the block:
self.connect(self.u, self.conv_c2f, self.probe2)
Then I use the gr.probe_signal_f().level() to retrieve the signal in a loop.
data_file = open('data.txt', 'w')
T1 = time.asctime()
while cs_samples 100:
CST = self.tb.probe_channel()
data_file.write(str(CST) + '\n')
cs_samples += 1
data_file.close()
T2 = time.asctime()
def probe_channel(self):
return self.probe2.level()
I was wondering if this is the fastest way to sample the channel from
python. When I compute how long this process takes, it appears that I can
get a sample every 8-9 microseconds, which seems a lot slower than what the
USRP2 is built to do. Am I sampling the channel in an incorrect way?
I'm running this on a machine with a Intel Quad Q9650 @ 3GHz.
Thanks,
Miklos Christine
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
