Re: [Discuss-gnuradio] Raised Cosine Filter design
Yep! Done. fred harris' book helped the most. Thanks On Tue, Jun 28, 2011 at 12:25 PM, Colby Boyer colby.bo...@gmail.com wrote: Look at the source code used to generate the raised cosine, gr_firdes.h should point to it. Making your own should follow directly from that; also the wikipedia page on the raised cosine is also nice. Its not black magic, so do not fear the source. :P --Colby On Tue, Jun 28, 2011 at 9:12 AM, John Andrews gnu.f...@gmail.com wrote: Hi, I want a raised cosine filter for the transmitter and can someone lead me to a place where I can develop one similar to what we have in gr_firdes.h Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot import name VERSION
On Tue, Jun 28, 2011 at 08:41:24AM -0400, Randy Westlund wrote: Problem solved. It works if I launch with the command `gnuradio-companion' and not with `grc.' I still don't know why that changed overnight, but now this machine launches with the first command and my other machines only launch with `grc.' I'm running Ubuntu 10.10 on all of them, and I installed gnuradio in parallel on my machines. But so long as it runs, I'm not complaining. Thanks for the help guys. Hi Randy, the name was changed from grc to gnuradio-companion many, many revisions ago. If you still have a grc executable, you still have old stuff on your machine. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpASsBhAkpCY.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] using fftw for neon with gnuradio
Could somebody post the whole configure call once the vesperix fftw lib was installed? I'm giving this a try here myself but want to make sure I'm on the right track. ./configure --disable-volk --disable-usrp2 --disable-usrp1 --disable-gr-video-sdl --enable-shared CFLAGS=-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O3 -fPIC CXXFLAGS=-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O3 -fPIC -with-qwt-incdir=/usr/include On Wed, Jun 22, 2011 at 5:26 PM, Thomas Tsou tt...@vt.edu wrote: On Wed, Jun 22, 2011 at 2:13 PM, Philip Balister phi...@balister.org wrote: Did you rerun configure adding -fPIC to CFLAGS? I ddi get the library to build as a shared library. That worked for me. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Raised Cosine Filter design
That is the best source currently in my opinion especially his discussion of HOW BAD RAISED COSINE FILTERS ARE AS NYQUIST FILTERS FOR DATA TRANSMISSION. Bob On Jun 29, 2011 4:11 AM, John Andrews gnu.f...@gmail.com wrote: Yep! Done. fred harris' book helped the most. Thanks On Tue, Jun 28, 2011 at 12:25 PM, Colby Boyer colby.bo...@gmail.com wrote: Look at the source code used to generate the raised cosine, gr_firdes.h should point to it. Making your own should follow directly from that; also the wikipedia page on the raised cosine is also nice. Its not black magic, so do not fear the source. :P --Colby On Tue, Jun 28, 2011 at 9:12 AM, John Andrews gnu.f...@gmail.com wrote: Hi, I want a raised cosine filter for the transmitter and can someone lead me to a place where I can develop one similar to what we have in gr_firdes.h Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] E100 Performance
Hi, the simple GRC in the attachment creates lots of underflows on our E100 (U on console) and dropouts when looking at the spectrum. Is this as expected or how can this overload of the embedded Linux be avoided? Thanks, Ralf ?xml version='1.0' encoding='ASCII'? flow_graph timestampWed Jun 29 14:59:09 2011/timestamp block keyuhd_usrp_sink/key param keyid/key valueuhd_usrp_sink_0/value /param param key_enabled/key valueTrue/value /param param keytype/key valuecomplex/value /param param keydev_addr/key value/value /param param keyref_clk/key value/value /param param keysync/key value/value /param param keyclock_rate/key value0.0/value /param param keynum_mboards/key value1/value /param param keysd_spec0/key value:A/value /param param keysd_spec1/key value/value /param param keysd_spec2/key value/value /param param keysd_spec3/key value/value /param param keynchan/key value1/value /param param keysamp_rate/key valuesamp_rate/value /param param keycenter_freq0/key value40/value /param param keygain0/key value3/value /param param keyant0/key value/value /param param keybw0/key value0/value /param param keycenter_freq1/key value0/value /param param keygain1/key value0/value /param param keyant1/key value/value /param param keybw1/key value0/value /param param keycenter_freq2/key value0/value /param param keygain2/key value0/value /param param keyant2/key value/value /param param keybw2/key value0/value /param param keycenter_freq3/key value0/value /param param keygain3/key value0/value /param param keyant3/key value/value /param param keybw3/key value0/value /param param keycenter_freq4/key value0/value /param param keygain4/key value0/value /param param keyant4/key value/value /param param keybw4/key value0/value /param param keycenter_freq5/key value0/value /param param keygain5/key value0/value /param param keyant5/key value/value /param param keybw5/key value0/value /param param keycenter_freq6/key value0/value /param param keygain6/key value0/value /param param keyant6/key value/value /param param keybw6/key value0/value /param param keycenter_freq7/key value0/value /param param keygain7/key value0/value /param param keyant7/key value/value /param param keybw7/key value0/value /param param keycenter_freq8/key value0/value /param param keygain8/key value0/value /param param keyant8/key value/value /param param keybw8/key value0/value /param param keycenter_freq9/key value0/value /param param keygain9/key value0/value /param param keyant9/key value/value /param param keybw9/key value0/value /param param keycenter_freq10/key value0/value /param param keygain10/key value0/value /param param keyant10/key value/value /param param keybw10/key value0/value /param param keycenter_freq11/key value0/value /param param keygain11/key value0/value /param param keyant11/key value/value /param param keybw11/key value0/value /param param keycenter_freq12/key value0/value /param param keygain12/key value0/value /param param keyant12/key value/value /param param keybw12/key value0/value /param param keycenter_freq13/key value0/value /param param keygain13/key value0/value /param param keyant13/key value/value /param param keybw13/key value0/value /param param keycenter_freq14/key value0/value /param param keygain14/key value0/value /param param keyant14/key value/value /param param keybw14/key value0/value /param param keycenter_freq15/key value0/value /param param keygain15/key value0/value /param param
[Discuss-gnuradio] DPSK2 Demodulator
Hi, we are trying to use DPSK2 modulator and demodulator during our first trials. As far as we can see there is hardly any documentation available on this. We would appreciate a few explaining words from somebody who knows how to configure the demodulator so that data is correctly received. What synchronization method(s) is/are included? Raised-cosine-filter for matched filtering seems to be included? We tried like this with no success: Modulator: Type: DQPSK Sample/Symbol: 2 Excess BW: 0.35 GrayCode: YES Verbose: OFF Logging: OFF Demodulator: Sample/Symbol: 2 Excess BW: 0.35 FLL Alpha: 0.01 Phase Alpha: 0.1 Timing Max Dev: 1.5 Omega Relative Limit: 0.005 GrayCode: YES Verbose: OFF Logging: OFF Sync Out: ON Thanks in advance! Ralf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E100 Performance
On 29/06/2011 9:11 AM, Ralf wrote: Hi, the simple GRC in the attachment creates lots of underflows on our E100 (U on console) and dropouts when looking at the spectrum. Is this as expected or how can this overload of the embedded Linux be avoided? Thanks, Ralf Well, for one, 60Khz isn't a proper divisor of the 128MHz sample rate of the DAC, which means it can't be properly interpolated. The minimum sample rate that you can deliver to the USRP-E100 is 128MHz/512 = 250kHz, so you'll have to interpolate your data stream up to 250kHz prior to presentation to the UHD sink block. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error on Assertion `imu = 0' failed when using gr.udp_source/sink
I just solved this problem! The reason is that in gnuradio-examples, UDP default payload size is set to 1471. In gr_udp_source.cc, all received data will be round down to a multiple of d_itemsize. Since sizeof_gr_complex is 8, so only 1464 Bytes are received correctly, while the left 7 byte are abandoned. This will in turn disturb the position of the following data stream, and also affect the mmse_fir_interpolator and make imu negative. Actually, the default UDP payload size in gr_udp_source.h is set to 1472, but in examples, it is set to 1471. I am not sure if this is a bug. A simple way to bypass this problem is to set MTU size as a multiple of itemsize, such as 1464 or 1472, then everything works as expected. 发件人： Zhen zkon...@yahoo.com.cn 收件人： discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org 发送日期： 2011年6月28日, 星期二, 上午 2:34 主题: [Discuss-gnuradio] Error on Assertion `imu = 0' failed when using gr.udp_source/sink Hello, I modified benchmark_tx.py and benchmark_rx.py by replacing the usrp_source/sink with gr.udp_source/sink and gr.file_source/sink, to see if the generated IQ data from tx side can be correctly captured and processed at rx side via UDP socket or trace file instead of USRP. If it does, then I can analyze the signal off-line or transmit the captured data to others via socket. The modified program with gr.file_source/sink works correctly and the results are exactly the same when using usrp_source/sink. But when using udp_source/sink, the tx side can send packets to udp_sink well, but the rx side program is aborted with error python: gri_mmse_fir_interpolator.cc:71: float gri_mmse_fir_interpolator::interpolate(const float*, float) const: Assertion `imu = 0' failed. My python codes are configured like the following: rx side: -- self.u = gr.udp_source(gr.sizeof_gr_complex, options.host, options.port, options.packet_size, not options.no_eof, not options.no_wait) rx_path = receive_path.receive_path(demod_class, rx_callback, options) self.connect(self.u, rx_path) - tx side: -- self.u = gr.udp_sink(gr.sizeof_gr_complex, options.host, options.port, options.packet_size, options.no_eof); tx_path = transmit_path.transmit_path(modulator_class, options) self.connect(tx_path, self.u) -- Then I added a printf in gri_mmse_fir_interpolator.cc, and found imu is −2147483648, .i.e, -0x8000; But in normal situation when using usrp_source/sink or file_source/sink, it is between 63--67. I searched the mailing list and knew that the imu value is used to tell the interpolating filter where in the filter to takethe output from, but got few clues to solve this problem. I wonder if udp_source/sink modifies the complex data stream it transmits then the gnuradio can't process it correctly? Or is there any suggestion to solve it? Thanks in advance! Zhen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A simple flow-graph that is giving me infinite grief
On 29/06/2011 12:12 PM, Johnathan Corgan wrote: On Tue, Jun 28, 2011 at 21:38, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: I'll make the observation that there's just got to be a better buffer allocation policy than the existing one. Should it *really* take Gigabytes of VM, and hundreds of MB of RSS to execute the flow-graph I've attached? The largest inter-block objects--the vectors in front of and behind the FFT, are on the order of a few MB, and even accounting for some ballooning factor so you can have several such vectors in flight, that doesn't add up to hundreds of MB of RSS, and several GB of Virtual Size. GNU Radio achieves its streaming performance in part due to a circular buffer design that maps the same physical memory twice in the virtual memory map for the process, directly adjacent to each other. This allows work function code to avoid doing any bounds checking or modular index arithmetic operations when reading and writing its input and output buffers. Going off the end of the buffer just results in accessing the start of the buffer which is mapped into the next block of memory. Not only does this make the code and I/O much faster, but the work function code gets a lot simpler. I wonder if that assertion is generally true, or only in some cases? Increment and test shouldn't be *that* expensive. In order to make this strategy work, however, the buffer memory must end on an exact multiple of the size of a single stream item. Thus, the allocated buffer size has to be the LCM (least common multiple) of the machine page size and the item size. The machine page size is typically 4096 bytes, so in simple cases when the item size is a small power of two, the minimum buffer size remains 4096 bytes. (In practice, other things the user might ask of the runtime can increase the size by an integer factor of this.) The usual GNU Radio buffer in these cases is 32K, which can hold 16K shorts, 8K floats, 4K complex floats, etc. If your stream item size is larger than 4K, things can get ugly. The best case is that your item size is a power of two, so the LCM will end up being the same as the item size. Then GNU Radio can allocate memory for however many items it needs to hold in the buffer simply as a multiple of that. The worst case is when the item size is relatively prime to the page size, and then LCM is the product of the page size and the item size. Asking GNU Radio to allocate a buffer for items of size 4097 results in a minimum buffer size of 4096*4097 or slightly over 16Mbytes. The virtual memory footprint will be twice that. The worst-case item is the FFT, which is typically large--sometimes as much as 512K, but it's always a power-of-two size, and given that it's complex, the result should also be a power-of-two size, since each complex-float takes 8 bytes. I'm guessing something like this last is what is happening in your flowgraph. I'd trace through all the blocks in your graph and their configuration parameters, then manually calculate what the item size is and the LCM with 4096 that results. My recollection is that sizes get ballooned outwards based on the degree of decimation downstream from the source block, which is a policy I've never quite gotten my head around. The FFT in my flow-graph might get decimated by a factor of 10 or more, which given the policy I mentioned, might lead to chunky allocations. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A simple flow-graph that is giving me infinite grief
On Tue, Jun 28, 2011 at 21:38, Marcus D. Leech mle...@ripnet.com wrote: I'll make the observation that there's just got to be a better buffer allocation policy than the existing one. Should it *really* take Gigabytes of VM, and hundreds of MB of RSS to execute the flow-graph I've attached? The largest inter-block objects--the vectors in front of and behind the FFT, are on the order of a few MB, and even accounting for some ballooning factor so you can have several such vectors in flight, that doesn't add up to hundreds of MB of RSS, and several GB of Virtual Size. GNU Radio achieves its streaming performance in part due to a circular buffer design that maps the same physical memory twice in the virtual memory map for the process, directly adjacent to each other. This allows work function code to avoid doing any bounds checking or modular index arithmetic operations when reading and writing its input and output buffers. Going off the end of the buffer just results in accessing the start of the buffer which is mapped into the next block of memory. Not only does this make the code and I/O much faster, but the work function code gets a lot simpler. In order to make this strategy work, however, the buffer memory must end on an exact multiple of the size of a single stream item. Thus, the allocated buffer size has to be the LCM (least common multiple) of the machine page size and the item size. The machine page size is typically 4096 bytes, so in simple cases when the item size is a small power of two, the minimum buffer size remains 4096 bytes. (In practice, other things the user might ask of the runtime can increase the size by an integer factor of this.) The usual GNU Radio buffer in these cases is 32K, which can hold 16K shorts, 8K floats, 4K complex floats, etc. If your stream item size is larger than 4K, things can get ugly. The best case is that your item size is a power of two, so the LCM will end up being the same as the item size. Then GNU Radio can allocate memory for however many items it needs to hold in the buffer simply as a multiple of that. The worst case is when the item size is relatively prime to the page size, and then LCM is the product of the page size and the item size. Asking GNU Radio to allocate a buffer for items of size 4097 results in a minimum buffer size of 4096*4097 or slightly over 16Mbytes. The virtual memory footprint will be twice that. I'm guessing something like this last is what is happening in your flowgraph. I'd trace through all the blocks in your graph and their configuration parameters, then manually calculate what the item size is and the LCM with 4096 that results. If you are writing your own blocks, there is a technique where you can lie to the GNU Radio runtime and say your item size is the next higher power of two, but your own custom written blocks on either end of the buffer know the real size of the item and how to access them spaced out in the buffer accordingly. But this hack obviously won't work with existing blocks. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error on Assertion `imu = 0' failed when using gr.udp_source/sink
On Wed, Jun 29, 2011 at 07:44, Zhen zkon...@yahoo.com.cn wrote: The reason is that in gnuradio-examples, UDP default payload size is set to 1471. In gr_udp_source.cc, all received data will be round down to a multiple of d_itemsize. Since sizeof_gr_complex is 8, so only 1464 Bytes are received correctly, while the left 7 byte are abandoned. This will in turn disturb the position of the following data stream, and also affect the mmse_fir_interpolator and make imu negative. Actually, the default UDP payload size in gr_udp_source.h is set to 1472, but in examples, it is set to 1471. I am not sure if this is a bug. A simple way to bypass this problem is to set MTU size as a multiple of itemsize, such as 1464 or 1472, then everything works as expected. Very nice catch. I have yet looked at the code to verify this, but your description sounds plausible. Thanks! Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] using fftw for neon with gnuradio
I don't think you have to change the parameters you're giving to ./configure for gnuradio. You actually want to change the parameters used by ./configure for fftw. This worked for me: ./configure --enable-single --enable-neon --enable-shared CFLAGS='-fPIC -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O2' And then I built gnuradio as normal. Morgan On Wed, Jun 29, 2011 at 2:46 AM, Phelps Williams phel...@gmail.com wrote: Could somebody post the whole configure call once the vesperix fftw lib was installed? I'm giving this a try here myself but want to make sure I'm on the right track. ./configure --disable-volk --disable-usrp2 --disable-usrp1 --disable-gr-video-sdl --enable-shared CFLAGS=-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O3 -fPIC CXXFLAGS=-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O3 -fPIC -with-qwt-incdir=/usr/include On Wed, Jun 22, 2011 at 5:26 PM, Thomas Tsou tt...@vt.edu wrote: On Wed, Jun 22, 2011 at 2:13 PM, Philip Balister phi...@balister.org wrote: Did you rerun configure adding -fPIC to CFLAGS? I ddi get the library to build as a shared library. That worked for me. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A simple flow-graph that is giving me infinite grief
On Wed, Jun 29, 2011 at 09:24, Marcus D. Leech mle...@ripnet.com wrote: ** On 29/06/2011 12:12 PM, Johnathan Corgan wrote: GNU Radio achieves its streaming performance in part due to a circular buffer design that maps the same physical memory twice in the virtual memory map for the process, directly adjacent to each other. This allows work function code to avoid doing any bounds checking or modular index arithmetic operations when reading and writing its input and output buffers. Going off the end of the buffer just results in accessing the start of the buffer which is mapped into the next block of memory. Not only does this make the code and I/O much faster, but the work function code gets a lot simpler. I wonder if that assertion is generally true, or only in some cases? Increment and test shouldn't be *that* expensive. I'm sure the benefit varies depending on the situation, including some where there is no benefit. But modulo increments add a conditional operation for every pointer increment, which can cause a processor pipeline stall, and takes up register file space to hold the array boundaries for every input and output stream. It also forces the author of the work() function to know about how GNU Radio handles circular buffers. The double-mapped circular buffer lets the work() function treat all its inputs and outputs as linear arrays in memory, no matter the actual case. My recollection is that sizes get ballooned outwards based on the degree of decimation downstream from the source block, which is a policy I've never quite gotten my head around. The FFT in my flow-graph might get decimated by a factor of 10 or more, which given the policy I mentioned, might lead to chunky allocations. Ah, I think I remember this discussion a while back. It's the gr.keep_one_in_n block used to decimate the sample stream into blocks that update the FFT sink at the requested screen update rate. Decimator blocks tell the runtime their decimation ratio via set_relative_rate(). Knowing this, GNU Radio expands the buffer allocation by twice the decimation rate, to allow enough room for the upstream block thread to be simultaneously writing a full set of inputs and the downstream block thread to be reading a full set of inputs: http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/annotate/gnuradio-core/src/lib/runtime/gr_flat_flowgraph.cc#L106 Since gr.keep_one_in_n is simply discarding n-1 input items, and doesn't need to actually process them like most decimators would, there may be an alternative way to handle this for this particular block. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re g : Building gr-uhd and usrp2-firmware
Hi Marcus I got the answer for the question in this thread.Actually I was using an outdated version of UHD which doesn't had USRP2 firmwares.Hence during configure it was showing the above error. I just downloaded the latest images and firmwares. I need to ask that whether it is needed to uninstall the older UHD before installing the new one. If yes then will make uninstall will work in the directory from which i did make install ? or some other way ... sumitstop wrote: Hi Marcus I have used your script.Its superb! I just wanted to build step by step :) Btw I just got all things build properly.Actually I put mb-gcc in the home folder and set the path variables accordingly.And it worked :) Marcus D. Leech wrote: On 06/23/2011 06:50 PM, sumitstop wrote: I am using ubuntu Lucid 10.04 LTS. Did the following thing Step-1 Installed all the dependencies for ubuntu Lucid 10.04 from the script given here http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall step-2 git clone http://gnuradio.org/git/gnuradio.git then step-3 git clone http://github.com/EttusResearch/UHD-Mirror.git after that step-4 cd gnuradio step-5 ./bootstrap step-6 ./configure I got following messages * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp2-firmware These components will not be built. * The following GNU Radio components have been successfully configured: config gruel volk gnuradio-core usrp usrp2 gr-usrp gr-usrp2 gr-msdd6000 gr-audio gr-atsc gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-noaa gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc docs You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-comedi gr-uhd These components will not be built. Configured GNU Radio release v3.4.0-2-g081497e7 for build. ** I searched a lot and found answer to many of questions From the following link(in the summary) i found that no need to build gr-comedi http://lists.gnu.org/archive/html/discuss-gnuradio/2006-06/msg00225.html Also in the following link I read that gcell and gr-gcell are needed only for IBM cell processor. http://www.ruby-forum.com/topic/201112 So I want to ask what should I do to build gr-uhd and usrp2-firmware I also did ./configure --enable-gr-uhd but it shows following message checking for UHD... no gr-uhd requires libuhd 3.x.x configure: error: Component gr-uhd has errors; stopping. I also did ./configure --enable-usrp2-firmware and got following message checking whether byte ordering is bigendian... no checking for mb-gcc... no usrp2 firmware requires mb-gcc. Not found configure: error: Component usrp2-firmware has errors; stopping. configure: error: ./configure.gnu failed for usrp2/firmware I saw several posts with the same problem but honestly I couldn't understand what to do next. Regards - Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India I'll once again do some personal horn-tooting, if y'all can stand it: http://www.sbrac.org/files/build-gnuradio It takes care of downloading/building UHD+Gnu Radio, including downloading the latest firmware, installing pre-requisites, and uninstalling any installed-from-binary-packages stuff that might interfere with a built from source build of Gnu Radio. It works for Ubuntu and Fedora recent releases. It's a shell script. It takes quite a while to run, and generally operates as silently as is practical. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio - Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India -- View this message in context: http://old.nabble.com/Reg-%3A-Building-gr-uhd-and-usrp2-firmware-tp31915462p31958690.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re g : Building gr-uhd and usrp2-firmware
On 06/29/2011 06:01 PM, sumitstop wrote: Hi Marcus I got the answer for the question in this thread.Actually I was using an outdated version of UHD which doesn't had USRP2 firmwares.Hence during configure it was showing the above error. I just downloaded the latest images and firmwares. I need to ask that whether it is needed to uninstall the older UHD before installing the new one. If yes then will make uninstall will work in the directory from which i did make install ? or some other way ... As long as you're always installing from source, it should be OK. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
