[Discuss-gnuradio] disabling configuration check while doing ./configure
hi all , i am doing ./configure --with-uhd but i get the following : configure: WARNING: unrecognized options:--with-uhd i think the solution is to disable the configuration option check as i have done it before ,but i forgot the command , so can any one help me with this issue thanks, osama riad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] disabling configuration check while doing ./configure
On Tue, May 8, 2012 at 6:41 AM, osama mohamed wrote: > hi all , > > i am doing ./configure --with-uhd but i get the following : > > configure: WARNING: unrecognized options:--with-uhd > > i think the solution is to disable the configuration option check as i have > done it before ,but i forgot the command , so can any one help me with this > issue > > thanks, > > osama riad It's not clear what you are trying to do. If you want to force the gr-uhd interface to be enabled, you use "--enable-gr-uhd". If you have a problem finding the libuhd library, this is not the way to handle it. The simplest way is to let configuration use pkg-config to find information about the libraries. So make sure that PKG_CONFIG_PATH includes a path to the directory containing uhd.pc. By default, this would be in /usr/local/lib/pkgconfig (if you build and installed by hand) or /usr/lib/pkgconfig (I think, if you installed using one of the pre-packaged binaries). If it's in the latter, configure will automatically find it for you. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MacOS, AVX, GCC, and LLVM
On Sat, May 5, 2012 at 2:16 PM, Jared Boone wrote:
> I spent some time last night getting the the development branch of GNU Radio
> to compile on MacOS X 10.7. In the process, I saw some people having issues
> with compiler/assembler AVX support, Apple's ancient GPLv2 "as", and Xcode's
> LLVM. I succeeded in building and running GNU Radio using Xcode 4.3.2's tools
> (no MacPorts gcc, llvm, or cctools). I'm posting what I learned, in hopes
> somebody knows how to fix this from the GNU Radio source side (instead of
> patching CMake, as I did).
>
> The problem I saw, having to do with Clang compiler flag detection for ORC
> during cmake:
>
> -- Performing Test have_maltivec
> -- Performing Test have_maltivec - Success
> -- Performing Test have_mfpu_neon
> -- Performing Test have_mfpu_neon - Success
> -- Performing Test have_mfloat_abi_softfp
> -- Performing Test have_mfloat_abi_softfp - Success
> -- Performing Test have_funsafe_math_optimizations
> -- Performing Test have_funsafe_math_optimizations - Success
> ...
> -- Performing Test have_mpopcnt
> -- Performing Test have_mpopcnt - Success
>
> Note that I'm compiling on a Sandy Bridge Intel processor, so Altivec (PPC),
> NEON (ARM), and float-ABI (ARM?) aren't available. Also, LLVM 3.0 doesn't
> support -mpopcnt, and apparently doesn't support -munsafe_math_optimizations.
> And yet, the detections are showing "Success". Sure enough, when I "make",
> volk bombs out with:
>
> cc1: error: unrecognized command line option "-mfpu=neon"
> cc1: error: unrecognized command line option "-mfloat-abi=softfp"
>
> Examining build/volk/CMakeFiles/CMakeOutput.log, the command line executed
> for detecting the Altivec flag is:
>
> /usr/bin/c++ -Dhave_maltivec -maltivec -o
> CMakeFiles/cmTryCompileExec.dir/src.cxx.o -c
> /Users/jboone/tmp/gnuradio/build/volk/CMakeFiles/CMakeTmp/src.cxx
>
> Creating my own src.cxx ("int main() { return 0; }") and trying this out
> yields:
>
> clang: warning: argument unused during compilation: '-maltivec'
>
> Clang warns about the unrecognized flag, but CMake doesn't consider it an
> error. Why? Examining volk/lib/CMakeLists.txt, I see that CMake's
> CheckCXXCompilerFlag is included, and CHECK_CXX_COMPILER_FLAG is called with
> each flag to test.
>
> Looking at CMake's CHECK_CXX_COMPILER_FLAG, I see it tests the compiler's
> stdout (or stderr?) against these regular expressions:
>
> # Some compilers do not fail with a bad flag
> FAIL_REGEX "unrecognized .*option" # GNU
> FAIL_REGEX "unknown .*option" # Clang
> FAIL_REGEX "ignoring unknown option" # MSVC
> FAIL_REGEX "warning D9002" # MSVC, any lang
> FAIL_REGEX "[Uu]nknown option" # HP
> FAIL_REGEX "[Ww]arning: [Oo]ption" # SunPro
> FAIL_REGEX "command option .* is not recognized" # XL
> FAIL_REGEX "not supported in this configuration; ignored" # AIX
> FAIL_REGEX "File with unknown suffix passed to linker" # PGI
>
> None of these regex tests will catch the Clang warning above.
>
> My first inclination was to see if I could set a Clang flag (like "-Werror")
> to cause unused arguments to produce an error. But I can't tell how to do
> that with CMake. If somebody knows how to do this from within the GNU Radio
> sources, that would be ideal. Instead, I patched CMake as follows:
>
> --- /opt/local/share/cmake-2.8/Modules/CheckCXXCompilerFlag.cmake.orig
> 2012-05-04 23:41:16.0 -0700
> +++ /opt/local/share/cmake-2.8/Modules/CheckCXXCompilerFlag.cmake
> 2012-05-04 23:43:19.0 -0700
> @@ -29,6 +29,7 @@
> # Some compilers do not fail with a bad flag
> FAIL_REGEX "unrecognized .*option" # GNU
> FAIL_REGEX "unknown .*option" # Clang
> + FAIL_REGEX "argument unused during compilation" # Clang
> FAIL_REGEX "ignoring unknown option" # MSVC
> FAIL_REGEX "warning D9002" # MSVC, any lang
> FAIL_REGEX "[Uu]nknown option" # HP
>
> This results in more sensible flag detection for ORC during cmake:
>
> -- Performing Test have_maltivec
> -- Performing Test have_maltivec - Failed
> -- Performing Test have_mfpu_neon
> -- Performing Test have_mfpu_neon - Failed
> -- Performing Test have_mfloat_abi_softfp
> -- Performing Test have_mfloat_abi_softfp - Failed
> -- Performing Test have_funsafe_math_optimizations
> -- Performing Test have_funsafe_math_optimizations - Failed
> ...
> -- Performing Test have_mpopcnt
> -- Performing Test have_mpopcnt - Failed
> ...
> -- GCC missing xgetbv, Overruled arch avx
> -- Check size of void*[8]
> -- Check size of void*[8] - done
> -- CPU width is 64 bits, Overruled arch 32
> -- Available architectures:
Re: [Discuss-gnuradio] Questions
On Sat, May 5, 2012 at 12:00 PM, Amr Youssef wrote: > Hi , i have some questions : > > 1- In the following .cc file : ./gr-digital/lib/digital_crc32.cc > > Regarding CRC-32 , why the generated polynomial is of length 36 Bits > instead of 32 Bits (as expected) ! " it is written as : > // Automatically generated CRC function > // polynomial: 0x104C11DB7 > the above two lines exist in the code . " Amr, That code is old and I'm not sure where it's from, but I'll respond like I know what I'm talking about, anyways (mostly from experience with these kinds of registers). That's not 36 bits, actually, it's 33 bits, and the 33rd bit is a 1. It's typical to have always have a 1 in the last place for shift registers like this. The algorithm itself is likely created using a 32-bit value. > 2- In the following .py file : ./gr-digital/python/ofdm_packet_utils.py > > How "random_mask_tuple" is generated through the 15-bit Linear Feedback > Shift Register (LFSR) . > Are they random ? if yes , why they are of length 8 bits (maximum number > 255 ) instead of 15 bits ?! > > Thanks in-advance > Amr, I'd have to let the person who wrote that code answer. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 802.11b Transmitter
On Mon, May 7, 2012 at 2:56 PM, frankist wrote: > > Hi, > > I was trying to use the BBN 802.11b code in the CGRAN website however I > can't download it using svn. It seems that the url is wrong or doesn't exist > anymore. > > I noticed there is, however, a 802.11b receiver implemented (SPAN 802.11b > Receiver). > > But what I really needed is a transmitter. Do you know how to get it? I love CGRAN, but abandoned projects and bit rot are a problem (as with any open source project, really). Unfortunately, I don't keep tabs on this stuff and so can't help you. Anyone else have a link for accessing the 802.11 code? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fwd: OsmoSDR developer beta
Hi all, I think this is of interest for this mailing list. Quick intro -- OsmoSDR [1] is a project to create an extremely low-cost SDR receiver similar to FunCube dongle but with higher bandwidth. Aim is to use it as a receiver for GSM/TETRA/GMR and other Osmocom projects. But it's just an SDR, you know. There are plans to later extend OsmoSDR to a full transceiver. And at last but not at least, OsmoSDR is actively developed and is progressing very quickly. It's developed by the same community which recently hacked RTL-SDR [2]. 1. http://sdr.osmocom.org 2. http://sdr.osmocom.org/trac/blog/rtl-sdr-introduction -- Forwarded message -- From: Harald Welte Date: Tue, May 8, 2012 at 11:11 PM Subject: OsmoSDR developer beta To: osmocom-...@lists.osmocom.org Hi all! There are something like 16 units of OsmoSDR that we are able to sell in something like one week. Sale will happen via the https://shop.sysmocom.de/ webshop. However, as there are only 16 units right now, and as the firmware and host software is in an incomplete state, we would like to make sure that those 16 units get sold to people who actually have an interest (and time!) to fix and improve the current shortcomings. So if you want to be among the first 16, I suggest you reply to this message and give us a short description of who you are (if you are not a Osmocom regular) as well as some committment that you are actually going to work on improving the code. If you already know an area that you'd like to work on, please state that, too. The price will be 180 EUR incl. VAT (that's 151.26 EUR without), i.e. the same price as for the units that will later be sold openly. I have put together a wiki page with the current status at http://sdr.osmocom.org/trac/wiki/OsmoSDR/Status to make you aware where we are and what is missing. Thanks in advance for your willingness to be early users and help us to improve the codebase. Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] regarding segmentation fault
Please post a question on the list in a way that we understand your problem. We don't have a magic window to look into your brain and figure out what your problem is. Give us details so that we can help. One more thing, do not post the same question twice and expect a different response. On Sun, May 6, 2012 at 11:19 PM, Sravya Reddy wrote: > my code was working fine...then i have done some changes..it was showing > segmentaion fault..i undo the modifications and when im trying to run it > its whowing segmentation fault...but the same code was working fine before > occuring segmenttaion fault. anyone got the problem. > > thanks in advance. > > ___ > 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] MacOS, AVX, GCC, and LLVM
> > Note that I'm compiling on a Sandy Bridge Intel processor, so Altivec > (PPC), NEON (ARM), and float-ABI (ARM?) aren't available. Also, LLVM > 3.0 doesn't support -mpopcnt, and apparently doesn't support > -munsafe_math_optimizations. And yet, the detections are showing > "Success". Sure enough, when I "make", volk bombs out with: > > cc1: error: unrecognized command line option "-mfpu=neon" cc1: error: > unrecognized command line option "-mfloat-abi=softfp" > OK so, thats a pretty thorough analysis of the issue. I guess there there is question of how to fix/who to blame: 1) cmake is at fault, and that patch needs to be in there 2) clang is at fault and should error/not warn. Is there a clang flag to force unknown flags to become errors? I think you can just pass another flag to CHECK_CXX_COMPILER_FLAG along with the one being check. And if thats not possible we could switch to CHECK_CXX_SOURCE_COMPILES to help with the flag tests. 3) volk has a way to specify compiler specific flags. But its probably wrong to use this if clang is using GCC flags and reporting as GNU. http://gnuradio.org/cgit/gnuradio.git/tree/volk/gen/archs.xml -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] possibility of processing data in FPGA
hi, i have started working on SDR board a couple of weeks back. According to my knowledge, FPGA on the USRP board will do DDC(receive) and transfer the data sample to PC through USB port. now, my question is can we do signal processing tasks on FPGA??? suppose after down conversion i want to do some basic processing on FPGA..is there any possibility to do that? If yes , how to do the same. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM_TX_RX_OVER_TCP
Hi all, I tried to develop an OFDM transmitter and Recevier Using the OFDM Modulator and Demodulator blocks available in GnuRadio.v3.4.2 Since I haven't received my USRP, I decided to test it using the TCP. My PC Configuration: Intel Core2Duo E8500 @3.16GHz 4GB RAM, Fedora 16 , 64Bit. The OFDM configuration: BPSK,128FFT, 96Tones, sampling freq=2Mhz The problem that I face is that the transmitted file gets corrupted only for certain file sizes. I have attached a test result(pdf) of transmission of files with different sizes. I'm unable to figure out the issue. The attached images shows the flowgraphs of Transmitter and Reciever. I have also attached the python files. I http://old.nabble.com/file/p33763599/OFDM_TCP_TX.png ... http://old.nabble.com/file/p33763599/OFDM_TCP_RX.png http://old.nabble.com/file/p33763599/OFDM_TX.py OFDM_TX.py .. http://old.nabble.com/file/p33763599/OFDM_RX.py OFDM_RX.py http://old.nabble.com/file/p33763599/OFDM_Block_test_MAY_2012%2B-%2BBPSK128_2M.pdf OFDM_Block_test_MAY_2012+-+BPSK128_2M.pdf -- View this message in context: http://old.nabble.com/OFDM_TX_RX_OVER_TCP-tp33763599p33763599.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] Uninstall GNU Radio 3.5.3 (installed with building-gnuradio script)
I have found the answer of my last question by myself: I configured OpenBTS new, changed the OpenBTS.sql and smqueue.sql files, did sqlite3 -init ./apps/OpenBTS.example.sql /etc/OpenBTS/OpenBTS.db sqlite3 -init smqueue/smqueue.example.sql /etc/OpenBTS/smqueue.db But now there is a new error: > Starting the system... > ALERT 3078318960 USRPDevice.cpp:545:setRxFreq: set RX: 1.7832e+09failed > baseband freq: 1.78e+09 > DDC freq: -3.2e+06 > residual freq: 0.00298023 > ALERT 3078318960 Transceiver.cpp:540:driveControl: RX failed to tune > ALERT 3074639568 TRXManager.cpp:342:tune: RXTUNE failed with status 1 > ALERT 3074639568 TRXManager.cpp:395:powerOn: POWERON failed with status 1 > ALERT 3074639568 TRXManager.cpp:409:setPower: SETPOWER failed with status > 1 > ALERT 3074639568 TRXManager.cpp:409:setPower: SETPOWER failed with status > 1 > 1336484679.264657 3074639568: > Welcome to OpenBTS. Type "help" to see available commands. > OpenBTS> ALERT 3041119088 TRXManager.cpp:409:setPower: SETPOWER failed > with status 1 > ALERT 3065535344 TRXManager.cpp:86:clockHandler: TRX clock interface > timed out, assuming TRX is dead. > Aborted > I am not sure if there is still a problem with gnu radio or it is just an error from OpenBTS. (The configuration in OpenBTS.config are right and the correct softlink is set so this shouldn't be the problem.) *lsusrp: * > > *Traceback (most recent call last): > File "/usr/bin/lsusrp", line 25, in > from gnuradio import usrp > ImportError: cannot import name usrp* > so it seems that there are still problems with gnuradio but i don't know how to locate them because I followed these guide: > > http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSBuildingAndRunning#Building-and-Installing ls -lR /dev/bus/usb | grep usrp: > crw-rw 1 root usrp 189, 3 2012-05-09 08:38 004 > so the USRP seems to be recognized. So should I install gnuradio for a third time or is the error another? Thanks in advance. Regards Ellen 2012/5/4 Ellen Apolinar > > Thanks a lot for your answers! > > > Now there is still sn error when I want to start OpenBTS. Perhaps you know it. First I describe what I did: > > > I deleted all components from gnuradio 3.5.3 and followed this for installing libusrp: > http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSBuildingAndRunning#Building-dependencies > > I installed GNU Radio 3.3 from here: http://gnuradio.org/releases/gnuradio/ > > Before I continued: >> >> apt-get -y install libfontconfig1-dev libxrender-dev libpulse-dev swig g++ automake autoconf python-dev libfftw3-dev libcppunit-dev libboost-all-dev libusb-dev fort77 sdcc sdcc-libraries libsdl1.2-dev python-wxgtk2.8 git-core guile-1.8-dev libqt4-dev python-numpy ccache python-opengl libgsl0-dev python-cheetah python-lxml doxygen qt4-dev-tools libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools python-qwt5-qt4 > > (I know that is a little bit too much but I wanted to be sure that everything is alright.:) > > Then: >> >> ./configure --disable-all-components --enable-usrp --enable-gruel >> # make softlinks for boost and usrp-files > > > Perhaps a stupid question but should I do these steps again before starting OpenBTS? >> >> ./bootstrap >> ./configure >> make >> make install > > > When without them I start OpenBTS: >> >> Starting the system... >> OpenBTS: GSMCommon.cpp:140: unsigned int GSM::uplinkFreqKHz(GSM::GSMBand, unsigned int): Assertion `(ARFCN>511)&&(ARFCN<886)' failed. >> Aborted > > But this is not the first time that this alert comes when I want to start OpenBTS and the USRP1 is on (with the correct clock). > > > Thanks a lot for your answers and your help. > > Regards > Ellen > > 2012/5/4 Martin Braun >> >> On Fri, May 04, 2012 at 09:36:02AM +0200, Ellen Apolinar wrote: >> > 1) Unfortunatelly I installed a version which is too new for working with >> > OpenBTS so I want to uninstall it. >> > >> > didn't work so I think I have to remove it manually. (Locate >> > gnuradio and them remove all files.) >> > >> > But i'm not sure if that is the right way so it would be great if you can say >> > me if I'm right or not. >> >> Hi Ellen, >> >> that's fine--just dive through /usr/local (or whatever your prefix is) >> and kill anything gnuradio-related. >> >> >> 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 > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
