Hello all
In order to simulate the Tx path in the FPGA we need to get a few things
clarified.
How is the interpolation rate chosen with a known Sample rate and
Transmission frequency.
I am using an N210 and i know how the Interpolations rates are used in "
%root/host/lib/usrp/cores/tx_dsp_core_20
Hello,
just realized that I forgot to insert the part after "bt"
last time...
So once again:
This is what GDB says:
-
Starting program: /usr/bin/python uhd_fft.py -a type=usrp2
-f 935M -s 2M
[Thread debugging us
Do you remember which parts you did not implement?
Apparently make the alamouti work is harder than I though...
Thanks
Vanessa
On Thu, Oct 27, 2011 at 9:33 AM, Vanessa Gardellin
wrote:
>> Dear all,
>>>
>>> I am trying to use the alamouti code implemented by trondeau.
>>> Studying the gr_ofdm_fr
Fedora 12, 32-bit:
[ 0%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter.cc.o
[ 0%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter_msgq.cc.o
[ 0%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_queue.cc.o
[ 0%] Building CXX objec
>
> Fedora 12, 32-bit:
>
> [ 0%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter.cc.o
> [ 0%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter_msgq.cc.o
> [ 0%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_queue.cc.o
> [ 0%]
I'm a starter in using the USRP, it's known that the bandwidth of USRP is 8M
beacause of the USB bandwidth ,my question is the 8M refers to the Nquist
Bandwith or the actual signal bandwidth?If it refers to the Nquist Bandwith, it
is mean that USRP can only process the signal with 4M bandwidth,
On 11/8/11 9:29 AM, 弓长张 wrote:
> I'm a starter in using the USRP, it's known that the bandwidth of USRP
> is 8M beacause of the USB bandwidth ,my question is the 8M refers to the
> Nquist Bandwith or the actual signal bandwidth?If it refers to the
> Nquist Bandwith, it is mean that USRP can only
On 08/11/2011 9:29 AM, 弓长张 wrote:
I'm a starter in using the USRP, it's known that the bandwidth of USRP
is 8M beacause of the USB bandwidth ,my question is the 8M refers to
the Nquist Bandwith or the actual signal bandwidth?If it refers to the
Nquist Bandwith, it is mean that USRP can only pro
On 11/08/2011 04:24 AM, Marcus D. Leech wrote:
> Fedora 12, 32-bit:
>
> [ 0%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter.cc.o
> [ 0%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter_msgq.cc.o
> [ 0%] Building CXX object
> gruel/src/lib/
On 11/07/2011 02:15 PM, Nowlan, Sean wrote:
> Hi all -
>
> I'm getting limited by the slow ARM processor in the E100 and I want
> to modify parts of gr-digital and gnuradio-core to support complex
> short/INT16 types in the modulation schemes. I suspect that it won't
> be as trivial as defining
Sean, with all the talk about optimization for ARM, the first thing I
would do is start to integrate Volk with existing floating-point
blocks. Stock GCC is very, very bad at vectorizing for the NEON SIMD
unit -- even when hardware floating point is used in GCC, most float
instructions end up alloca
I use the old method
(./bootstrap, ./configure, make)
on Fedora 16 64b
and get the following errors:
/bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall
-Woverloaded-virtual -pthread -o gnuradio-config-info
gnuradio-config-info.o libgnuradio-core.la -L/usr/lib64
-lboost_program_op
On 11/08/2011 10:35 AM, Achilleas Anastasopoulos wrote:
> I use the old method
> (./bootstrap, ./configure, make)
> on Fedora 16 64b
> and get the following errors:
>
> /bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall
> -Woverloaded-virtual -pthread -o gnuradio-config-info
>
So, what needs to be done? I noticed that there are already hooks for NEON in
the volk library but no implementation (or very little... don't remember
exactly).
My understanding of Orc is that it generates architecture-dependent vector
processor instructions from an Orc abstraction language. I
I make the recent trunk with cmake and I get everything configured/compiled,
but make test fails at 83/93 qa_volk_test_all
on a Fedora 15 64.
Is there anyone who can duplicate this error?
Achilleas
PS: cmake gives the following for volk:
-- Configuring volk support...
-- Enabling volk support
On Tue, Nov 8, 2011 at 2:00 PM, Achilleas Anastasopoulos
wrote:
> I make the recent trunk with cmake and I get everything configured/compiled,
> but make test fails at 83/93 qa_volk_test_all
> on a Fedora 15 64.
>
> Is there anyone who can duplicate this error?
Yes, it's annoying and expected. Th
Hey list,
I have been itching to make some new gnuradio blocks that make use of
volk. So to avoid disturbing the delicate balance of code in
gnuradio-core, I have produced a new component called gr-basic.
The goal of gr-basic is to replace many of the blocks in gnuradio-core
with vector optimized
On 08/11/11 09:08 PM, Josh Blum wrote:
> Hey list,
>
> I have been itching to make some new gnuradio blocks that make use of
> volk. So to avoid disturbing the delicate balance of code in
> gnuradio-core, I have produced a new component called gr-basic.
>
> The goal of gr-basic is to replace many o
Hi list,
I need to use halfband filter in my grc project. but I can not find
halfband filter implement in gnuradio.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Tue, Nov 1, 2011 at 6:50 PM, Arturo Rinaldi wrote:
> Nella citazione in data mar 01 nov 2011 22:22:06 CET, Ben Hilburn ha
> scritto:
>
>> Svante -
>>
>> You say "see below", but I'm not seeing any error messages or attached
>> files in your e-mail. Tell me if they are there and I'm just not s
On Tue, Nov 8, 2011 at 9:28 PM, James Jordan wrote:
> Hi list,
> I need to use halfband filter in my grc project. but I can not find
> halfband filter implement in gnuradio.
>
Halfband filters aren't anything special. You can find more about their
implementations in any DSP text book that's worth
On Tue, Nov 8, 2011 at 9:08 PM, Josh Blum wrote:
> Hey list,
>
> I have been itching to make some new gnuradio blocks that make use of
> volk. So to avoid disturbing the delicate balance of code in
> gnuradio-core, I have produced a new component called gr-basic.
>
> The goal of gr-basic is to re
On Tue, Nov 8, 2011 at 4:51 AM, Vanessa Gardellin <
vanessa.gardel...@iit.cnr.it> wrote:
> Do you remember which parts you did not implement?
>
> Apparently make the alamouti work is harder than I though...
>
> Thanks
> Vanessa
I know that we got the 2x1 (2 TX and 1 RX) working, and we did 1x2 w
3 quick questions - first, does the cmake setup automatically turn on gcc
optimizations, i.e, with "-O3"? Second, is there anything to be gained (or
lost) by turning on "-ftree-vectorize" and "-funsafe-math-optimizations"?
Finally, is the gcc on E100 really CodeSourcery's arm-none-eabi-gcc (or
On 11/08/2011 07:40 PM, Nowlan, Sean wrote:
> 3 quick questions - first, does the cmake setup automatically turn on
> gcc optimizations, i.e, with "-O3"? Second, is there anything to be
> gained (or lost) by turning on "-ftree-vectorize" and
> "-funsafe-math-optimizations"? Finally, is the gcc o
I'm getting the following error running "cmake
-CMAKE_TOOLCHAIN_DIR=../cmake/Toolchains/arm_cortex_a8_native.cmake
-DENABLE_GRC=OFF -DENABLE_GR_QTGUI=OFF ../" with a gnuradio git tree fetched
today:
CMake Error: The following variables are used in this project, but they are set
to NOTFOUND.
Pl
On Tue, Nov 8, 2011 at 6:58 PM, Tom Rondeau wrote:
> On Tue, Nov 8, 2011 at 9:08 PM, Josh Blum wrote:
>>
>> Hey list,
>>
>> I have been itching to make some new gnuradio blocks that make use of
>> volk. So to avoid disturbing the delicate balance of code in
>> gnuradio-core, I have produced a new
On Tue, Nov 8, 2011 at 6:16 PM, Marcus D. Leech wrote:
> On 08/11/11 09:08 PM, Josh Blum wrote:
>> Hey list,
>>
>> I have been itching to make some new gnuradio blocks that make use of
>> volk. So to avoid disturbing the delicate balance of code in
>> gnuradio-core, I have produced a new component
FYI, I got cmake to finish. Ugly hack that made it work:
cmake -DCMAKE_TOOLCHAIN_DIR=../cmake/Toolchains/arm_cortex_a8_native.cmake
-DENABLE_GRC=OFF -DENABLE_GR_QTGUI=OFF
-DQT_QTCORE_INCLUDE_DIR=/usr/include/qt4/QtCore
-DQT_QTGUI_INCLUDE_DIR=/usr/include/qt4/QtGui ../
Sean
From: Nowlan, Sean
Marcus D. Leech ripnet.com> writes:
> If you are using the UHD API on the host-side, and haven't upgraded the
> *firmware* on the USRP2 to
>the appropriate, matching, UHD firmware/FPGA image, then UHD-based
> things won't work.
>
> You need to upgrade your USRP2 to the UHD firmware:
>
>
h
Marcus D. Leech ripnet.com> writes:
> If you are using the UHD API on the host-side, and haven't upgraded the
> *firmware* on the USRP2 to
>the appropriate, matching, UHD firmware/FPGA image, then UHD-based
> things won't work.
>
> You need to upgrade your USRP2 to the UHD firmware:
>
>
h
31 matches
Mail list logo