Re: [Discuss-gnuradio] SSDT question
On Fri, May 4, 2012 at 5:52 PM, frankist wrote: > > Hi, > > This question isn't necessarily about GNU Radio but about SDR in general. > > I am studying spectrum sensing algorithms and I was reading about > simultaneous sensing and data transmission or SSDT for out-band sensing. It > means that a radio is capable of transmitting data in one channel and > sensing at another different channel. > > However, using a USRP2, I can only select one center frequency at a time. > Considering I am applying sensing to signals which have a bandwidth of > 6MHz, > in order to transmit/receive data in one channel and sense other > (different) > channels at the same time I need crazy sampling rates that GNU Radio can't > support. A 25 MS/s isn't enough to make a scan for all the ISM Band as I > wanted. > You can tune the RX to one frequency and the TX to a different frequency. This is supported with all motherboards and all daughterboards except the XCVR2450. > > So there are several answers for my problem: > 1. SSDT implies additional hardware making a single USRP2 simply not enough > 2. There is a way to tune different channel frequencies at the same time > without any need to increase the sampling rate or use more than one USRP2 > Yes. Just tune your TX and RX frequencies separately. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MacOS, AVX, GCC, and LLVM
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:
generic;64;3dnow;abm;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2
-- Available machines:
generic_orc;sse2_64_orc;sse3_64_orc;ssse3_64_orc;sse4_1_64_orc
...and more importantly,
[Discuss-gnuradio] Questions
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 . " 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, ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [Final] Making sure of uboot version
Dear P. Balister, I needed to toggle gpio at the start and end of a function inside a software code to evaluate its performance. However, now I realize it is not accurate to do this from user space because extra delays will be introduced at kernel space. Therefore, I will change this approach and I'll use some software profiling technique. Thank you so much for your time ans speedy replies. Regards, S. Yassin HW Engineer DLECS From: Sameh Yassin To: Philip Balister Cc: GNURADIO Sent: Saturday, May 5, 2012 2:05 AM Subject: Re: Making sure of uboot version Hello dear, I followed the instruction and updated my sd card image. Now, inside /sys/class/gpio $root@usrp-e1xx:/sys/class/gpio# ls export gpio16@ gpio173@ gpiochip128@ gpiochip32@ unexport gpio114@ gpio164@ gpio175@ gpiochip160@ gpiochip64@ gpio15@ gpio168@ gpiochip0@ gpiochip192@ gpiochip96@ They changed from last version as us said. However, none of these are connected to the FPGA. Should I try $ echo 22 > /sys/class/gpio/export $ echo "high" > /sys/class/gpio/gpio72/direction or it is meaningless to create gpio "driver" in this way. Regards, S. Yassin HW Engineer DLECS From: Philip Balister To: Sameh Yassin Sent: Thursday, May 3, 2012 1:30 PM Subject: Re: Making sure of uboot version On 05/03/2012 07:14 AM, Sameh Yassin wrote: > Hello Dear, > > I've monitored the automatic boot and I think that is the latest version > > U-Boot 2011.06-00575-g6b73deb (Sep 07 2011 - 07:26:10) It is not. You need to make an sd card with the e1xx-003 image on it. See the link in the earlier email for instructions how to do this. Philip > > I also checked uname -a > > 3.0.0. > > > Regards, > S. Yassin > HW Engineer > DLECS > > > > From: Philip Balister > To: Sameh Yassin > Cc: GNURADIO > Sent: Wednesday, May 2, 2012 3:02 PM > Subject: Re: Using Sysfs to set a GPIO in Overo > > On 05/02/2012 08:16 AM, Sameh Yassin wrote: >> Dear P. Balister, >> I found that tutorial which explains very well how to create a GPIO folder >> and set its direction >> http://www.avrfreaks.net/wiki/index.php/Documentation:Linux/GPIO#gpio-sysfs >> >> >> I searched for the misc GPIOs to make sure they are free and I'm pretty sure >> that over_gpio0 and overo_gpio170 are free. the are not used at all inside >> the code. I connected them to debug led0 and debug_led1 and used echo 1> >> /sys/class/gpio/gpio0/value after setting the direction but nothing at all, >> the two debug leds are off. >> > > What version of the e100 image are you using. Can you start by making > sure you are using the latest? > > http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ#How-do-I-create-re-create-E1xx-SD-Card-Images > > I think earler images will not have access to gpio0 due to some pinmux > stuff in u-boot. I need to double check 170 pinmuxing also. there should > be some free gpios in the 20's with the current image. > >> Another question, what is the difference between gpio0 and gpiochip0 found >> at /sys/class/gpio > > I think the gpiochip entries represent the various banks of gpios. > > Philip > >> >> >> Regards, >> S. Yassin >> HW Engineer >> DLECS >> >> >> >> From: Philip Balister >> To: Sameh Yassin >> Cc: GNURADIO >> Sent: Wednesday, May 2, 2012 1:33 PM >> Subject: Re: [Discuss-gnuradio] E100 - Interface between OMAP3 and FPGA >> >> On 05/01/2012 04:28 AM, Sameh Yassin wrote: >>> Hello Dear , >>> >>> I used the first link to use overo GPIOs on the E100 to communicate with >>> the SPARTN3AN FPGA. >>> >>> I'm doing the following: >>> 1- I chose an empty GPIO input to the FPGA (for example overo_gpio22). >>> 2- I modified the FPGA image so that debug_led1 = over_gpio220 >>> 3- I'll set and clear overo GPIO using the bash shell as I read in the >>> first link that u recommended. >>> >>> The problem: >>> Although the following gpios are free on the FPGA. There are other >>>gpios valid on the overo. Srictly speaking >>> >>> The free GPIOs on the overo >>> $ root@usrp-e1xx:/sys/class/gpio# ls >>> >>> exportgpio16 gpio168 gpiochip128 gpiochip192 gpiochip64 unexport >>> gpio15gpio164 gpiochip0 gpiochip160 gpiochip32 gpiochip96 >> >> It looks like you are running an older version of uhd, which suggests an >> older kernel version. The older driver claimed a few extra gpio's for >> testing purposes. >> >> I see: >> >> root@usrp-e1xx:~# ls /sys/class/gpio/ >> export gpio16@ gpio173@ gpiochip128@ gpiochip32@ unexport >> gpio114@ gpio164@ gpio175@ gpiochip160@ gpiochip64@ >> gpio15@ gpio168@ gpiochip0@ gpiochip192@ gpiochip96@ >> >> Note the extra gpio's exposed to user space. These are used by uhd for >> signaling and configuring the clock generator. >> >> Philip >> >>> >>> >>> The free gpios at the FPGA found at u1e.v >>> input
