[Discuss-gnuradio] Simulation of TX_path

2011-11-08 Thread Paul M. Bendixen 
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_200.cpp"
Where the filters are enabled, but where does it get the interpolation
value from, and what about the interpolation value of the DAC, this is set
to 1 or 4 depending on (freq/tickrate) .

When i select a sample rate and carrier frequency  in GNU radio, what is
the corresponding tick rate, Interpolation rate and DAC settings.
What are the formulas for this, or where precisely can i get this
information?

Futhermore i want to know if the tickrate mentioned in the code is the CLK
signal for the  FPGA  running at 100MHz. This is not clear to me because
this is somehow connected to "master clock rate". And this is only
documented as avalible if Hardware changes have been made, see
"root/host/include/uhd/usrp/multi_usrp.hpp"

We are getting lost in the massive amount of undocumented and uncommented
Verilog and C++ code.

Best
Paul M. B.

-- 
* - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *-
*/- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -//
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] uhd_fft.py returns Segmentation fault

2011-11-08 Thread sdoering 

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 using libthread_db enabled]
linux; GNU C++ version 4.5.2; Boost_104200; 
UHD_003.001.000-a7927ae


[New Thread 0xb227cb70 (LWP 27190)]
[New Thread 0xb18ffb70 (LWP 27191)]
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- mboard0 is MIMO master

Program received signal SIGSEGV, Segmentation fault.
0xb6fdf26f in boost::thread::start_thread() () from 
/usr/lib/libboost_thread.so.1.46.1

(gdb) bt
#0  0xb6fdf26f in boost::thread::start_thread() () from 
/usr/lib/libboost_thread.so.1.46.1
#1  0xb63c80a0 in usrp2_impl::io_init() () from 
/usr/local/lib/libuhd.so.003
#2  0xb63ee5c5 in 
usrp2_impl::usrp2_impl(uhd::device_addr_t const&) () from 
/usr/local/lib/libuhd.so.003
#3  0xb63ef09a in usrp2_make(uhd::device_addr_t const&) () 
from /usr/local/lib/libuhd.so.003
#4  0xb63ef249 in 
boost::detail::function::function_invoker1 
(*)(uhd::device_addr_t const&), 
boost::shared_ptr, uhd::device_addr_t 
const&>::invoke(boost::detail::function::function_buffer&, 
uhd::device_addr_t const&) () from 
/usr/local/lib/libuhd.so.003
#5  0xb6416f73 in uhd::device::make(uhd::device_addr_t 
const&, unsigned int) ()

   from /usr/local/lib/libuhd.so.003
#6  0xb6316012 in 
uhd::usrp::multi_usrp::make(uhd::device_addr_t const&) ()

   from /usr/local/lib/libuhd.so.003
#7  0xb64a451a in 
uhd_usrp_source_impl::uhd_usrp_source_impl 
(this=0x93769e8, device_addr=...,
stream_args=..., __in_chrg=, 
__vtt_parm=) at gr_uhd_usrp_source.cc:68
#8  0xb649eac8 in uhd_make_usrp_source (device_addr=..., 
stream_args=...) at gr_uhd_usrp_source.cc:454
#9  0xb6521477 in _wrap_usrp_source__SWIG_1 
(args=) at python/uhd_swig.cc:29228
#10 _wrap_usrp_source (self=0x0, args=0x936e8a8) at 
python/uhd_swig.cc:29263

#11 0x080fade1 in PyEval_EvalFrameEx ()
#12 0x080fd804 in PyEval_EvalCodeEx ()
#13 0x0808c512 in ?? ()
#14 0x0805dc31 in PyObject_Call ()
#15 0x080f938c in PyEval_EvalFrameEx ()
#16 0x080fdcd1 in PyEval_EvalCodeEx ()
#17 0x080f7cdf in PyEval_EvalFrameEx ()
#18 0x080fd804 in PyEval_EvalCodeEx ()
#19 0x0808c512 in ?? ()
#20 0x0805dc31 in PyObject_Call ()
#21 0x080738bd in ?? ()
#22 0x0805dc31 in PyObject_Call ()
#23 0x080c30fa in ?? ()
#24 0x080be6fb in ?? ()
#25 0x0805dc31 in PyObject_Call ()
#26 0x080f81c1 in PyEval_EvalFrameEx ()
#27 0x080fd804 in PyEval_EvalCodeEx ()
#28 0x0808c512 in ?? ()
#29 0x0805dc31 in PyObject_Call ()
#30 0x080738bd in ?? ()
#31 0x0805dc31 in PyObject_Call ()
#32 0x080c30fa in ?? ()
#33 0x080be6fb in ?? ()
#34 0x0805dc31 in PyObject_Call ()
#35 0x080f81c1 in PyEval_EvalFrameEx ()
#36 0x080fd804 in PyEval_EvalCodeEx ()
#37 0x0808c512 in ?? ()
#38 0x0805dc31 in PyObject_Call ()
#39 0x080738bd in ?? ()
#40 0x0805dc31 in PyObject_Call ()
#41 0x080c30fa in ?? ()
#42 0x080be6fb in ?? ()
#43 0x0805dc31 in PyObject_Call ()
#44 0x080f81c1 in PyEval_EvalFrameEx ()
#45 0x080fd804 in PyEval_EvalCodeEx ()
#46 0x0808c512 in ?? ()
#47 0x0805dc31 in PyObject_Call ()
#48 0x080738bd in ?? ()
#49 0x0805dc31 in PyObject_Call ()
#50 0x080f704e in PyEval_CallObjectWithKeywords ()
#51 0xb3ef71ff in wxPyApp::_BootstrapApp() ()
   from 
/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core_.so
#52 0xb3f80ecd in ?? () from 
/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core_.so

#53 0x080fade1 in PyEval_EvalFrameEx ()
#54 0x080fd804 in PyEval_EvalCodeEx ()
#55 0x080f7cdf in PyEval_EvalFrameEx ()
#56 0x080fd804 in PyEval_EvalCodeEx ()
#57 0x0808c724 in ?? ()
#58 0x0805dc31 in PyObject_Call ()
#59 0x080738bd in ?? ()
#60 0x0805dc31 in PyObject_Call ()
#61 0x080f81c1 in PyEval_EvalFrameEx ()
#62 0x080fd804 in PyEval_EvalCodeEx ()
#63 0x0808c724 in ?? ()
#64 0x0805dc31 in PyObject_Call ()
#65 0x080738bd in ?? ()
#66 0x0805dc31 in PyObject_Call ()
#67 0x080c30fa in ?? ()
#68 0x080be6fb in ?? ()
#69 0x0805dc31 in PyObject_Call ()
#70 0x080f81c1 in PyEval_EvalFrameEx ()
#71 0x080f7e20 in PyEval_EvalFrameEx ()
#72 0x080fd804 in PyEval_EvalCodeEx ()
#73 0x080fe177 in PyEval_EvalCode ()
#74 0x0811acd0 in ?? ()
#75 0x0811b8e9 in PyRun_FileExFlags ()
#76 0x0811c4cc in PyRun_SimpleFileExFlags ()
#77 0x0812c7c6 in Py_Main ()
#78 0x0805da0b in main ()
-

I definitely have the latest GNURadio release installed.

uhd_find_devices and uhd_usrp-probe both work fine.

Regards
Sebastian




On Fri, 28 Oct 2011 07:41:17 -0700
 Josh Blum  wrote:



On 10/28/2011 04:03 AM, doering@googlemail.com 
wrote:

Hello list,

I tried to launch the "uhd_fft.py" script with the 
following command line:


"uhd_fft.py -a type=usrp2 -f 935M -s 2M"


My problem is that my terminal always returns this 
output:


linux; GN

Re: [Discuss-gnuradio] Coarse Frequency and related stuff

2011-11-08 Thread Vanessa Gardellin 
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_frame_acquisition I found several concepts that
>>> are not clear to me:
>>
>>
>> Wow, this code is pretty old, and we never did finish it. I hope you get it
>> working! I'd love to see the results.
>
> Yes I know... I am trying to implement alamouti and this is the only
> thing that I have found... do you know about newer code? and/or
> working one?
>
>>
>>>
>>> 1)  d_phase_count: what does it mean?
>>
>> We have a look up table for various phase rotations to use in the
>> calculations instead of recalculating them every time. This is the index
>> into the LUT.
>
> In the code you never used "d_phase_lut"... so this explain a lot of things...
>
>>
>>>
>>> 2) coarse_freq_comp(int freq_delta, int count): which is the meaning
>>> of this function?
>>
>> If the frequency offset is larger than a subcarrier spacing, we want to
>> correct for that. Once the number of subcarrier offset is found, we use this
>> function to recenter it. The fine frequency correct has already been taken
>> care of to center the signals to the center of a subcarrier.
>>
>>>
>>> 3) what "-M_TWOPI*freq_delta*d_cplen/d_fft_length" represents?
>>
>> This is the integer number of subarriers (freq_delta) and the phase
>> correction per subcarrier.
>>
>>>
>>> Thank you
>>>
>>> Vanessa
>>
>> Tom
>>
>
> Thanks
>
> Vanessa
>
> --
> Vanessa GARDELLIN, Ph.D.
> Researcher
> Institute for Informatics and Telematics (IIT),
> Italian National Research Council (CNR)
> Via G. Moruzzi 1
> 56124 Pisa - ITALY
> Phone: +390503153267
> Room: B65/c
> E-mail: vanessa.gardel...@iit.cnr.it
> WWW: http://www.iit.cnr.it/staff/vanessa.gardellin/
> Skype: gardellin.vanessa
>



-- 
Vanessa GARDELLIN, Ph.D.
Researcher
Institute for Informatics and Telematics (IIT),
Italian National Research Council (CNR)
Via G. Moruzzi 1
56124 Pisa - ITALY
Phone: +390503153267
Room: B65/c
E-mail: vanessa.gardel...@iit.cnr.it
WWW: http://www.iit.cnr.it/staff/vanessa.gardellin/
Skype: gardellin.vanessa

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] cmake build of Gnu Radio failing this morning

2011-11-08 Thread Marcus D. Leech 
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 object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_unv.cc.o
[  0%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt.cc.o
[  1%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_io.cc.o
[  1%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_pool.cc.o
[  1%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_serialize.cc.o
[  1%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/realtime.cc.o
[  1%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/sys_pri.cc.o
[  1%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_body_wrapper.cc.o
[  2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_group.cc.o
Linking CXX shared library libgruel.so
make[2]: *** [gruel/src/lib/libgruel.so.0.0.0] Error 1
make[1]: *** [gruel/src/lib/CMakeFiles/gruel.dir/all] Error 2

This is from a clean source tree, with -DENABLE_VOLK=NO on the cmake


-- 
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

Re: [Discuss-gnuradio] cmake build of Gnu Radio failing this morning

2011-11-08 Thread Marcus D. Leech 
>
> 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 object
> gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_unv.cc.o
> [  0%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt.cc.o
> [  1%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_io.cc.o
> [  1%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_pool.cc.o
> [  1%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_serialize.cc.o
> [  1%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/realtime.cc.o
> [  1%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/sys_pri.cc.o
> [  1%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/thread_body_wrapper.cc.o
> [  2%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/thread_group.cc.o
> Linking CXX shared library libgruel.so
> make[2]: *** [gruel/src/lib/libgruel.so.0.0.0] Error 1
> make[1]: *** [gruel/src/lib/CMakeFiles/gruel.dir/all] Error 2
>
> This is from a clean source tree, with -DENABLE_VOLK=NO on the cmake
>
>
>   
And another piece of data--an autotools build worked just fine (with
-disable-volk)


-- 
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

[Discuss-gnuradio] About USRP's Bandwidth

2011-11-08 Thread 弓长张 
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,so if a signal 
larger than 4M, how can USRP deals with it ?___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] About USRP's Bandwidth

2011-11-08 Thread Ed Criscuolo 
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 process the signal with 
> 4M bandwidth,so if a signal larger than 4M, how can USRP deals with it ?

Because the USRP does complex samples, an 8 megasample/sec rate
is enough to resolve up to 8 MHz.  This is in contrast  to magnitude-only
real samples, where an 8 megasample/sec rate would only resolve up to
4 MHz.

A qualitative way to think about it is that complex samples provide
twice the data as magnitude-only real samples, providing that
"factor of 2".

Nyquist will not be cheated!

@(^.^)@  Ed


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] About USRP's Bandwidth

2011-11-08 Thread Marcus D. Leech 

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 process the signal with 
4M bandwidth,so if a signal larger than 4M, how can USRP deals with it ?


USRP use complex-baseband sampling, which allows you to "cheat" Nyquist. 
With complex sampling, the sample-rate == bandwidth.


With the very-latest UHD updates from Josh last night, 8-bit "wire 
format" samples are supported, which doubles the effective
bandwidth-to-the-host for all the USRP platforms, meaning that USRP1 and 
B100 can support 16Msps maximum, and USRP2/N2XX
can support 50Msps maximum. I'd like to see someone be able to "do 
something" with 50Msps into their host :-)





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cmake build of Gnu Radio failing this morning

2011-11-08 Thread Josh Blum 


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/CMakeFiles/gruel.dir/msg/msg_queue.cc.o
> [  0%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_unv.cc.o
> [  0%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt.cc.o
> [  1%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_io.cc.o
> [  1%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_pool.cc.o
> [  1%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_serialize.cc.o
> [  1%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/realtime.cc.o
> [  1%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/sys_pri.cc.o
> [  1%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/thread_body_wrapper.cc.o
> [  2%] Building CXX object
> gruel/src/lib/CMakeFiles/gruel.dir/thread_group.cc.o
> Linking CXX shared library libgruel.so
> make[2]: *** [gruel/src/lib/libgruel.so.0.0.0] Error 1
> make[1]: *** [gruel/src/lib/CMakeFiles/gruel.dir/all] Error 2
> 
> This is from a clean source tree, with -DENABLE_VOLK=NO on the cmake
> 
> 

I dont see an error. Why do you think its volk?

-Josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Complex Short/INT16 type

2011-11-08 Thread Josh Blum 


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 "typedef std::complex gr_complexs;"
> in gnuradio-core/src/lib/runtime/gr_complex.h and doing a
> find-and-replace in the relevant source files. There are probably

It may be that simple for some blocks. Like the symbol table in BPSK.

> issues with dynamic range that I'll have to deal with in addition to
> having to implement filters using fixed-point math.
> 

Often blocks will need to have scale factors. Fortunatly, with a FIR
filter, you get a free scale factor in the "filter taps"

> Questions:
> 
> 1)  Do you think I'd save anything by doing all the modulation &
> filtering in complex float32 and then converting at the very end?

Its good to make the conversion part of an operation that does something
useful rather than doing it for the sake of converting. Like a filter
that takes in floats and spits out shorts.

> This will reduce the bandwidth requirement to the FPGA by two, but
> I'm afraid the float math is the true limitation.
> 

The format going into the FPGA is always integer. If you pass floats
into the UHD, they are copy-converted from host buffer to memory mapped
buffers.

> 2)  Why is there a gr_complex_to_interleaved_short block but not
> a gr_complex_to_complex_short block? Would it be better if I rolled
> my own or just hooked up a gr_complex_to_interleaved_short block and
> then a deinterleave block? Or alternatively, split the complex float
> vector into two streams and feed them to a USRP sink block using
> COMPLEX.INT16?
> 
The interleaved short block is a strange hold-over from ancient times. I
would ignore it. I think a block such as "gr_complex_to_complex_short"
is a good idea.

> 3)  What specific parts of the modulation examples or
> gnuradio-core do you think I need to change to support complex short
> ints?
> 

Probably some new sc16 filter blocks for the matched filters. I have
mentioned the importance of volk before.

The constellation stuff relies on this new constellation library in
gr-digital. Perhaps Ben can lean in here and offer some advice on how to
modify this for alternative data types.

The recovery stuff in the BPSK is using Tom's new gri-control-loop to
simplify writing things like FLLs, PLLs. Thats a place too look, see how
the timing recovery blocks make use of it.

-Josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Complex Short/INT16 type

2011-11-08 Thread Nick Foster 
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 allocated to the VFP rather than the NEON unit.
You might find an easy 2x-3x improvement just by doing the heavy
lifting in Volk rather than in C++. All of the Orc functions in Volk
will work for NEON. There's no FIR filter in Orc right now (need to
get accumulators working properly in Orc), but Philip Balister already
wrote NEON FIR filter cores for the _fff and _ccf FIR filters.

This isn't to say that short complex wouldn't be a useful addition to
GR. Just that it's likely going to be more work than making use of the
existing floating-point hardware the E100 already has.

This is work that needs to be done anyway to make ARM platforms as
useful as possible, and we (Josh, Phil, and I) are happy to help you
optimize your application for E100 if you give us details on how your
application works. We're putting together a "motivating example" using
Volk to show users how to Volkify their own blocks.

--n

On Tue, Nov 8, 2011 at 9:13 AM, Josh Blum  wrote:
>
>
> 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 "typedef std::complex gr_complexs;"
>> in gnuradio-core/src/lib/runtime/gr_complex.h and doing a
> find-and-replace in the relevant source files. There are probably
>
> It may be that simple for some blocks. Like the symbol table in BPSK.
>
>> issues with dynamic range that I'll have to deal with in addition to
>> having to implement filters using fixed-point math.
>>
>
> Often blocks will need to have scale factors. Fortunatly, with a FIR
> filter, you get a free scale factor in the "filter taps"
>
>> Questions:
>>
>> 1)      Do you think I'd save anything by doing all the modulation &
>> filtering in complex float32 and then converting at the very end?
>
> Its good to make the conversion part of an operation that does something
> useful rather than doing it for the sake of converting. Like a filter
> that takes in floats and spits out shorts.
>
>> This will reduce the bandwidth requirement to the FPGA by two, but
>> I'm afraid the float math is the true limitation.
>>
>
> The format going into the FPGA is always integer. If you pass floats
> into the UHD, they are copy-converted from host buffer to memory mapped
> buffers.
>
>> 2)      Why is there a gr_complex_to_interleaved_short block but not
>> a gr_complex_to_complex_short block? Would it be better if I rolled
>> my own or just hooked up a gr_complex_to_interleaved_short block and
>> then a deinterleave block? Or alternatively, split the complex float
>> vector into two streams and feed them to a USRP sink block using
>> COMPLEX.INT16?
>>
> The interleaved short block is a strange hold-over from ancient times. I
> would ignore it. I think a block such as "gr_complex_to_complex_short"
> is a good idea.
>
>> 3)      What specific parts of the modulation examples or
>> gnuradio-core do you think I need to change to support complex short
>> ints?
>>
>
> Probably some new sc16 filter blocks for the matched filters. I have
> mentioned the importance of volk before.
>
> The constellation stuff relies on this new constellation library in
> gr-digital. Perhaps Ben can lean in here and offer some advice on how to
> modify this for alternative data types.
>
> The recovery stuff in the BPSK is using Tom's new gri-control-loop to
> simplify writing things like FLLs, PLLs. Thats a place too look, see how
> the timing recovery blocks make use of it.
>
> -Josh
>
> ___
> 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] problem "making" latest trunk

2011-11-08 Thread Achilleas Anastasopoulos 
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_options-mt -lboost_filesystem-mt
libtool: link: g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o
.libs/gnuradio-config-info gnuradio-config-info.o
./.libs/libgnuradio-core.so -L/usr/lib64 -lrt
/n/harrisville/x/anastas/gnuradio_trunk/gruel/src/lib/.libs/libgruel.so
-lboost_system-mt -lboost_thread-mt -lfftw3f -lgsl -lgslcblas
-lboost_program_options-mt -lboost_filesystem-mt -pthread -Wl,-rpath
-Wl,/usr/local/lib64
make[8]: Leaving directory
`/net/harrisville/x/anastas/gnuradio_trunk/gnuradio-core/src/lib'
Making all in swig
make[8]: Entering directory
`/net/harrisville/x/anastas/gnuradio_trunk/gnuradio-core/src/lib/swig'
make[8]: *** No rule to make target
`/n/harrisville/x/anastas/gnuradio_trunk/gnuradio-core/src/lib/general/gr_mpsk_receiver_cc.i',
needed by `gnuradio_core_general.py'.  Stop.
make[8]: Leaving directory
`/net/harrisville/x/anastas/gnuradio_trunk/gnuradio-core/src/lib/swig'
make[7]: *** [all-recursive] Error 1
make[7]: Leaving directory
`/net/harrisville/x/anastas/gnuradio_trunk/gnuradio-core/src/lib'
make[6]: *** [all] Error 2
make[6]: Leaving directory
`/net/harrisville/x/anastas/gnuradio_trunk/gnuradio-core/src/lib'
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory
`/net/harrisville/x/anastas/gnuradio_trunk/gnuradio-core/src'
make[4]: *** [all] Error 2
make[4]: Leaving directory
`/net/harrisville/x/anastas/gnuradio_trunk/gnuradio-core/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/net/harrisville/x/anastas/gnuradio_trunk/gnuradio-core'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/net/harrisville/x/anastas/gnuradio_trunk/gnuradio-core'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/net/harrisville/x/anastas/gnuradio_trunk'
make: *** [all] Error 2

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem "making" latest trunk

2011-11-08 Thread Josh Blum 


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
> gnuradio-config-info.o libgnuradio-core.la -L/usr/lib64
> -lboost_program_options-mt -lboost_filesystem-mt
> libtool: link: g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o
> .libs/gnuradio-config-info gnuradio-config-info.o
> ./.libs/libgnuradio-core.so -L/usr/lib64 -lrt
> /n/harrisville/x/anastas/gnuradio_trunk/gruel/src/lib/.libs/libgruel.so
> -lboost_system-mt -lboost_thread-mt -lfftw3f -lgsl -lgslcblas
> -lboost_program_options-mt -lboost_filesystem-mt -pthread -Wl,-rpath
> -Wl,/usr/local/lib64
> make[8]: Leaving directory
> `/net/harrisville/x/anastas/gnuradio_trunk/gnuradio-core/src/lib'
> Making all in swig
> make[8]: Entering directory
> `/net/harrisville/x/anastas/gnuradio_trunk/gnuradio-core/src/lib/swig'
> make[8]: *** No rule to make target
> `/n/harrisville/x/anastas/gnuradio_trunk/gnuradio-core/src/lib/general/gr_mpsk_receiver_cc.i',
> needed by `gnuradio_core_general.py'.  Stop.
> make[8]: Leaving directory

I think that file was removed. And I cant find any references to it in
the code. find -type f | xargs grep "gr_mpsk_receiver_cc" Try rebuilding
from a clean tree.

Or try to build with cmake (more testers can hurt):
http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork

-Josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Complex Short/INT16 type

2011-11-08 Thread Nowlan, Sean 
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. Is integrating Orc 
into Volk for NEON as simple as linking into liborc with a compile switch 
indicating that we want NEON output? Are the smarts already built into the 
cmake build process?

Can I drop Philip's _fff and _ccf filters into volk and hit "go?" (I know 
there's more nuance to it, but if the combination of integrating Orc code and 
NEON FIR filter code that's already written gets me 90% of the way there, I'd 
be VERY happy!

Thanks,
Sean

From: Nick Foster [n...@ettus.com]
Sent: Tuesday, November 08, 2011 1:27 PM
To: j...@ettus.com
Cc: discuss-gnuradio@gnu.org; Nowlan, Sean
Subject: Re: [Discuss-gnuradio] Complex Short/INT16 type

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 allocated to the VFP rather than the NEON unit.
You might find an easy 2x-3x improvement just by doing the heavy
lifting in Volk rather than in C++. All of the Orc functions in Volk
will work for NEON. There's no FIR filter in Orc right now (need to
get accumulators working properly in Orc), but Philip Balister already
wrote NEON FIR filter cores for the _fff and _ccf FIR filters.

This isn't to say that short complex wouldn't be a useful addition to
GR. Just that it's likely going to be more work than making use of the
existing floating-point hardware the E100 already has.

This is work that needs to be done anyway to make ARM platforms as
useful as possible, and we (Josh, Phil, and I) are happy to help you
optimize your application for E100 if you give us details on how your
application works. We're putting together a "motivating example" using
Volk to show users how to Volkify their own blocks.

--n

On Tue, Nov 8, 2011 at 9:13 AM, Josh Blum  wrote:
>
>
> 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 "typedef std::complex gr_complexs;"
>> in gnuradio-core/src/lib/runtime/gr_complex.h and doing a
> find-and-replace in the relevant source files. There are probably
>
> It may be that simple for some blocks. Like the symbol table in BPSK.
>
>> issues with dynamic range that I'll have to deal with in addition to
>> having to implement filters using fixed-point math.
>>
>
> Often blocks will need to have scale factors. Fortunatly, with a FIR
> filter, you get a free scale factor in the "filter taps"
>
>> Questions:
>>
>> 1)  Do you think I'd save anything by doing all the modulation &
>> filtering in complex float32 and then converting at the very end?
>
> Its good to make the conversion part of an operation that does something
> useful rather than doing it for the sake of converting. Like a filter
> that takes in floats and spits out shorts.
>
>> This will reduce the bandwidth requirement to the FPGA by two, but
>> I'm afraid the float math is the true limitation.
>>
>
> The format going into the FPGA is always integer. If you pass floats
> into the UHD, they are copy-converted from host buffer to memory mapped
> buffers.
>
>> 2)  Why is there a gr_complex_to_interleaved_short block but not
>> a gr_complex_to_complex_short block? Would it be better if I rolled
>> my own or just hooked up a gr_complex_to_interleaved_short block and
>> then a deinterleave block? Or alternatively, split the complex float
>> vector into two streams and feed them to a USRP sink block using
>> COMPLEX.INT16?
>>
> The interleaved short block is a strange hold-over from ancient times. I
> would ignore it. I think a block such as "gr_complex_to_complex_short"
> is a good idea.
>
>> 3)  What specific parts of the modulation examples or
>> gnuradio-core do you think I need to change to support complex short
>> ints?
>>
>
> Probably some new sc16 filter blocks for the matched filters. I have
> mentioned the importance of volk before.
>
> The constellation stuff relies on this new constellation library in
> gr-digital. Perhaps Ben can lean in here and offer some advice on how to
> modify this for alternative data types.
>
> The recovery stuff in the BPSK is using Tom's new gri-control-loop to
> simplify writing things like FLLs, PLLs. Thats a place too look, see how
> the timing recovery blocks make use of it.
>
> -Josh
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnur

[Discuss-gnuradio] "make test" fails on test # 83 (volk)

2011-11-08 Thread Achilleas Anastasopoulos 
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.
--   Override with -DENABLE_VOLK=ON/OFF
-- 32 overruled
-- Available arches:
generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx
-- Available machines:
generic;sse2_only;sse2_64;sse3_64;ssse3_64;sse4_a_64;sse4_1_64;sse4_2_64;avx_64
-- Using install prefix: /usr/local
--

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] "make test" fails on test # 83 (volk)

2011-11-08 Thread Nick Foster 
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. There are a couple of lingering Orc
implementations within Volk which have bugs in them, but which are in
the test framework. For the time being, I'll just disable them so they
aren't checked. Really, the implementations are fine, but the Orc
versions output different values for undefined results (in this case,
negative magnitudes).

You can work around this by not running "make test".

--n

>
> Achilleas
>
> PS: cmake gives the following for volk:
>
> -- Configuring volk support...
> --   Enabling volk support.
> --   Override with -DENABLE_VOLK=ON/OFF
> -- 32 overruled
> -- Available arches:
> generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx
> -- Available machines:
> generic;sse2_only;sse2_64;sse3_64;ssse3_64;sse4_a_64;sse4_1_64;sse4_2_64;avx_64
> -- Using install prefix: /usr/local
> --
>
> ___
> 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] performance improvements and using volk

2011-11-08 Thread Josh Blum 
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 blocks that call into volk; and to make it easy
for users to extend blocks to support new data types. You can see the
branch here: http://gnuradio.org/cgit/jblum.git/log/?h=gr_basic

So far, gr-basic has the familiar add, multiply, subtract and divide
block, but with 2 major differences:

1)
It is very easy to add new data types to these blocks. So it doesn't
suffer from the confusing code generation or naming convention issues
with the existing adder. So rather than generating gr_add_* for each
data type, there is one block add, which takes as a parameter, the data
type.

2)
Some of the adder implementations use volk routines. We happened to
already have a volk routine for adding floats, so rather than calling
into the generic implementation, we call into a work function that calls
the volk add routine, seen here:
http://gnuradio.org/cgit/jblum.git/tree/gr-basic/lib/gr_basic_add.cc?h=gr_basic#n45

Just as a rough benchmark, you can expect a 30% savings in overhead from
the adder (tested on a sse machine).

I hope that this gives users a good starting point for optimizing
gnuradio blocks with volk!

-Josh


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] performance improvements and using volk

2011-11-08 Thread Marcus D. Leech 
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 of the blocks in gnuradio-core
> with vector optimized blocks that call into volk; and to make it easy
> for users to extend blocks to support new data types. You can see the
> branch here: http://gnuradio.org/cgit/jblum.git/log/?h=gr_basic
>
> So far, gr-basic has the familiar add, multiply, subtract and divide
> block, but with 2 major differences:
>
> 1)
> It is very easy to add new data types to these blocks. So it doesn't
> suffer from the confusing code generation or naming convention issues
> with the existing adder. So rather than generating gr_add_* for each
> data type, there is one block add, which takes as a parameter, the data
> type.
>
> 2)
> Some of the adder implementations use volk routines. We happened to
> already have a volk routine for adding floats, so rather than calling
> into the generic implementation, we call into a work function that calls
> the volk add routine, seen here:
> http://gnuradio.org/cgit/jblum.git/tree/gr-basic/lib/gr_basic_add.cc?h=gr_basic#n45
>
> Just as a rough benchmark, you can expect a 30% savings in overhead from
> the adder (tested on a sse machine).
>
> I hope that this gives users a good starting point for optimizing
> gnuradio blocks with volk!
>
> -Josh
>
>   
Once again, Josh posts evidence that he's actually a consortium of
tightly-cooperating
  cerebella, rather than a single entity :-)

Cool stuff here, Josh.  I like numbers like "30% savings".  Those are
good numbers. 

One of my thoughts today about the VOLK thing is that GRC might easily
decide at generate-time
  whether to satisfy a basic block with "standard" or "volked"
routines.  Maybe even at runtime.

The performance envelope is going to get more and more interesting now
that 8-bit sampling has arrived
  with USRP hardware.  I should probably try an 8-bit 50Msps uhd_fft.py
at some point, on my 6-core AMD
  machine to see if it can do it at all.

-- 
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

[Discuss-gnuradio] Is there halfband filter implementation in gnuradio

2011-11-08 Thread James Jordan 
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

Re: [Discuss-gnuradio] GNU Radio release candidate 3.5.0rc0 available for download

2011-11-08 Thread Tom Rondeau 
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 seeing
>> them, as it might be my mail client.
>>
>> Regardless, yes, please join the USRP-Users list, and post your questions
>> there.  We will be happy to field any issues you may have while using UHD.
>>  I think we have de-railed Johnathan's 3.5.0 RC announcement enough at this
>> point ;)
>>
>> Cheers,
>> Ben
>>
>> On Tue, Nov 1, 2011 at 1:42 PM, Svante Signell > s...@kth.se>> wrote:
>>
>>On Tue, 2011-11-01 at 12:00 -0700, Ben Hilburn wrote:
>>> Svante -
>>>
>>>
>>> UHD is an entirely different project from GNURadio.  UHD
>>provides the
>>> firmware & API for Ettus Research SDRs.  GNURadio has support for
>>> UHD-compatible devices, through gr-uhd, but they are different
>>> projects.  You can, in fact, install GNURadio without UHD, and use
>>> GNURadio with SDRs that are not USRPs, or without any actual
>>hardware
>>> at all.
>>>
>>>
>>> If you have questions about using UHD with USRPs, you can get help
>>> from us on the USRP-Users
>>> list!
>>
>> http://lists.ettus.com/**mailman/listinfo/usrp-users_**lists.ettus.com
>>>
>>>
>>> If you want to build GNURadio with the gr-uhd component, you
>>will need
>>> to build and install UHD prior to building & installing
>>GNURadio.  You
>>> didn't say what was keeping you from building UHD in your last
>>e-mail,
>>> so I don't really have any information to help you yet.  If you
>>still
>>> need help, send your error messages to the USRP-Users list, linked
>>> above, and we will do what we can to help you =)
>>
>>I used git to download the uhd code and tried to build it. But I
>>did not
>>succeed with autotools or cmake, se below. Additionally there does not
>>seem to be any Debian packages available. So building from source
>>would
>>be the only option for now. I'll subscribe to USRP-Users mailing
>>list if
>>needed.
>>
>>Thanks!
>>
>>> Looking at the ettus webpage,
>>>
>>> 
>> http://code.ettus.com/redmine/**ettus/projects/uhd/wiki
>>>
>>> there seems to be a separate git directory for the driver:
>>>  git clone 
>> git://code.ettus.com/ettus/**uhd.git
>>
>> 
>> >
>>
>>...
>>> However, I did not manage to build the driver either with
>>> cmake or the autotools yet.
>>
>>
>>
>>
>>
>>
>> __**_
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio
>>
>
> i can't find the bug tracker to post the cmake -build-package errorcan
> you link me to it ?
>
> Regards, Arturo



To submit an issue (or ticket), go to http://gnuradio.org and login (you
can use the guest:gnuradio account) and click on "New Issue."

Thanks,
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Is there halfband filter implementation in gnuradio

2011-11-08 Thread Tom Rondeau 
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 a damn. You can easily
implement one as a FIR filter.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] performance improvements and using volk

2011-11-08 Thread Tom Rondeau 
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 replace many of the blocks in gnuradio-core
> with vector optimized blocks that call into volk; and to make it easy
> for users to extend blocks to support new data types. You can see the
> branch here: http://gnuradio.org/cgit/jblum.git/log/?h=gr_basic
>
> So far, gr-basic has the familiar add, multiply, subtract and divide
> block, but with 2 major differences:
>
> 1)
> It is very easy to add new data types to these blocks. So it doesn't
> suffer from the confusing code generation or naming convention issues
> with the existing adder. So rather than generating gr_add_* for each
> data type, there is one block add, which takes as a parameter, the data
> type.
>
> 2)
> Some of the adder implementations use volk routines. We happened to
> already have a volk routine for adding floats, so rather than calling
> into the generic implementation, we call into a work function that calls
> the volk add routine, seen here:
>
> http://gnuradio.org/cgit/jblum.git/tree/gr-basic/lib/gr_basic_add.cc?h=gr_basic#n45
>
> Just as a rough benchmark, you can expect a 30% savings in overhead from
> the adder (tested on a sse machine).
>
> I hope that this gives users a good starting point for optimizing
> gnuradio blocks with volk!
>
> -Josh
>

So I like everything about this but the name.  We could stuff all of this
under the "gnuradio.gr" namespace in Python, or we could name this
"gr-math."

Actually, while I was typing this, I'm thinking we rename the directory to
be "gr-blocks" but put them under the "gnuradio.gr" namespace. I'm
expecting that since you've used different names for the blocks because of
the data-type handling that they won't collide with what's in guradio-core
right now.

Thanks!
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Coarse Frequency and related stuff

2011-11-08 Thread Tom Rondeau 
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 with
maximum ratio and equal gain (obviously not Alamouti). I know we were close
with the 2x2 Alamouti, but we ran out of time and didn't manage to track
down one of the major bugs. Neither of use has had time since to finish it.

Tom




> 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_frame_acquisition I found several concepts that
> >>> are not clear to me:
> >>
> >>
> >> Wow, this code is pretty old, and we never did finish it. I hope you
> get it
> >> working! I'd love to see the results.
> >
> > Yes I know... I am trying to implement alamouti and this is the only
> > thing that I have found... do you know about newer code? and/or
> > working one?
> >
> >>
> >>>
> >>> 1)  d_phase_count: what does it mean?
> >>
> >> We have a look up table for various phase rotations to use in the
> >> calculations instead of recalculating them every time. This is the index
> >> into the LUT.
> >
> > In the code you never used "d_phase_lut"... so this explain a lot of
> things...
> >
> >>
> >>>
> >>> 2) coarse_freq_comp(int freq_delta, int count): which is the meaning
> >>> of this function?
> >>
> >> If the frequency offset is larger than a subcarrier spacing, we want to
> >> correct for that. Once the number of subcarrier offset is found, we use
> this
> >> function to recenter it. The fine frequency correct has already been
> taken
> >> care of to center the signals to the center of a subcarrier.
> >>
> >>>
> >>> 3) what "-M_TWOPI*freq_delta*d_cplen/d_fft_length" represents?
> >>
> >> This is the integer number of subarriers (freq_delta) and the phase
> >> correction per subcarrier.
> >>
> >>>
> >>> Thank you
> >>>
> >>> Vanessa
> >>
> >> Tom
> >>
> >
> > Thanks
> >
> > Vanessa
> >
> > --
> > Vanessa GARDELLIN, Ph.D.
> > Researcher
> > Institute for Informatics and Telematics (IIT),
> > Italian National Research Council (CNR)
> > Via G. Moruzzi 1
> > 56124 Pisa - ITALY
> > Phone: +390503153267
> > Room: B65/c
> > E-mail: vanessa.gardel...@iit.cnr.it
> > WWW: http://www.iit.cnr.it/staff/vanessa.gardellin/
> > Skype: gardellin.vanessa
> >
>
>
>
> --
> Vanessa GARDELLIN, Ph.D.
> Researcher
> Institute for Informatics and Telematics (IIT),
> Italian National Research Council (CNR)
> Via G. Moruzzi 1
> 56124 Pisa - ITALY
> Phone: +390503153267
> Room: B65/c
> E-mail: vanessa.gardel...@iit.cnr.it
> WWW: http://www.iit.cnr.it/staff/vanessa.gardellin/
> Skype: gardellin.vanessa
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Complex Short/INT16 type

2011-11-08 Thread Nowlan, Sean 
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 an 
upstream GNU version thereof)?

Thanks,
Sean

-Original Message-
From: Nick Foster [mailto:n...@ettus.com]
Sent: Tuesday, November 08, 2011 4:10 PM
To: Nowlan, Sean; j...@ettus.com
Subject: Re: [Discuss-gnuradio] Complex Short/INT16 type

On Tue, Nov 8, 2011 at 12:50 PM, Nowlan, Sean  
wrote:
> 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).

Josh is putting together a little example that uses Volk in Gnuradio's core 
blocks (add, subtract, etc.). This will eventually (hopefully) become the 
replacement for much of the functionality in gnuradio-core.
We've been talking about this for a long time, and it should provide a pretty 
major speedup on all platforms, but especially those for which the compiler 
sucks (ARM being the worst offender). Josh's example should provide a framework 
for you to work with while we get Volk fully integrated into Gnuradio "for 
real".

You can also always use Volk functions in your own custom dsp blocks to speed 
them up. You can also just use Volk outside of Gnuradio if you like.

>
> My understanding of Orc is that it generates architecture-dependent vector 
> processor instructions from an Orc abstraction language. Is integrating Orc 
> into Volk for NEON as simple as linking into liborc with a compile switch 
> indicating that we want NEON output? Are the smarts already built into the 
> cmake build process?

Orc is actually a little cooler than that -- it's a runtime-compiled 
architecture-independent vector assembly language. It's integrated as one 
alternative architecture for implementing Volk functions. Volk has been set up 
to automatically select the fastest implementation available for a given 
function at runtime, so for the user it's as simple as #include  
and then volk_32f_x2_add_32f_a16(...) to implement an adder. Volk will 
automatically choose the fastest implementation at runtime the first time the 
function is invoked, after figuring out what architecture it's running on and 
what implementations are available for that given function. If an Orc version 
of a function is available, it will be automatically selected and the Orc code 
will runtime-compile to vectorized NEON. You don't have to link against liborc 
at all, just against libvolk. We don't have any native NEON in Volk -- we use 
Orc to provide coverage on NEON platforms. We've found that Orc tends to be 
around 90% as fast as good, hand-tuned assembly most of the time, and sometimes 
faster. The reason we don't just use Orc for everything is that it's usually 
possible to do a little better with careful optimization and compiler 
intrinsics, and we were "gifted" a large library of well-optimized SSE DSP 
routines to use.

>
> Can I drop Philip's _fff and _ccf filters into volk and hit "go?" (I know 
> there's more nuance to it, but if the combination of integrating Orc code and 
> NEON FIR filter code that's already written gets me 90% of the way there, I'd 
> be VERY happy!

You can, but the _fff and _ccf filters are already implemented and working in 
NEON. They were done by Phil before Volk was integrated, so they're written in 
assembly in the filter core. They are also automatically selected at runtime, 
so they should be "just working"
for you already. Eventually we'll pull the assembly implementations out and put 
them into Volk.

If you send me your flowgraph, I'll take a look at it on an E100 and see if I 
can get some things optimized.

--n

>
> Thanks,
> Sean
> 
> From: Nick Foster [n...@ettus.com]
> Sent: Tuesday, November 08, 2011 1:27 PM
> To: j...@ettus.com
> Cc: discuss-gnuradio@gnu.org; Nowlan, Sean
> Subject: Re: [Discuss-gnuradio] Complex Short/INT16 type
>
> 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 allocated to the VFP rather than the NEON unit.
> You might find an easy 2x-3x improvement just by doing the heavy 
> lifting in Volk rather than in C++. All of the Orc functions in Volk 
> will work for NEON. There's no FIR filter in Orc right now (need to 
> get accumulators working properly in Orc), but Philip Balister already 
> wrote NEON FIR filter cores for the _fff and _ccf FIR filters.
>
> This isn't to say that short complex wouldn't be a useful addition to 
> GR. Just that it's likely going to be more work than making use of the 
> existing floating-poi

Re: [Discuss-gnuradio] Complex Short/INT16 type

2011-11-08 Thread Josh Blum 


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 on E100 really
> CodeSourcery's arm-none-eabi-gcc (or an upstream GNU version
> thereof)?
> 

CMake will automatically build in release mode, which gives you -03.
Other important flags need to be specified, you can do this in one fell
swoop with a toolchain file. Once is checked into the cmake/Toolchains
directory, see comments for usage

-josh

> Thanks, Sean
> 
> -Original Message- From: Nick Foster [mailto:n...@ettus.com] 
> Sent: Tuesday, November 08, 2011 4:10 PM To: Nowlan, Sean;
> j...@ettus.com Subject: Re: [Discuss-gnuradio] Complex Short/INT16
> type
> 
> On Tue, Nov 8, 2011 at 12:50 PM, Nowlan, Sean
>  wrote:
>> 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).
> 
> Josh is putting together a little example that uses Volk in
> Gnuradio's core blocks (add, subtract, etc.). This will eventually
> (hopefully) become the replacement for much of the functionality in
> gnuradio-core. We've been talking about this for a long time, and it
> should provide a pretty major speedup on all platforms, but
> especially those for which the compiler sucks (ARM being the worst
> offender). Josh's example should provide a framework for you to work
> with while we get Volk fully integrated into Gnuradio "for real".
> 
> You can also always use Volk functions in your own custom dsp blocks
> to speed them up. You can also just use Volk outside of Gnuradio if
> you like.
> 
>> 
>> My understanding of Orc is that it generates architecture-dependent
>> vector processor instructions from an Orc abstraction language. Is
>> integrating Orc into Volk for NEON as simple as linking into liborc
>> with a compile switch indicating that we want NEON output? Are the
>> smarts already built into the cmake build process?
> 
> Orc is actually a little cooler than that -- it's a runtime-compiled
> architecture-independent vector assembly language. It's integrated as
> one alternative architecture for implementing Volk functions. Volk
> has been set up to automatically select the fastest implementation
> available for a given function at runtime, so for the user it's as
> simple as #include  and then
> volk_32f_x2_add_32f_a16(...) to implement an adder. Volk will
> automatically choose the fastest implementation at runtime the first
> time the function is invoked, after figuring out what architecture
> it's running on and what implementations are available for that given
> function. If an Orc version of a function is available, it will be
> automatically selected and the Orc code will runtime-compile to
> vectorized NEON. You don't have to link against liborc at all, just
> against libvolk. We don't have any native NEON in Volk -- we use Orc
> to provide coverage on NEON platforms. We've found that Orc tends to
> be around 90% as fast as good, hand-tuned assembly most of the time,
> and sometimes faster. The reason we don't just use Orc for everything
> is that it's usually possible to do a little better with careful
> optimization and compiler intrinsics, and we were "gifted" a large
> library of well-optimized SSE DSP routines to use.
> 
>> 
>> Can I drop Philip's _fff and _ccf filters into volk and hit "go?"
>> (I know there's more nuance to it, but if the combination of
>> integrating Orc code and NEON FIR filter code that's already
>> written gets me 90% of the way there, I'd be VERY happy!
> 
> You can, but the _fff and _ccf filters are already implemented and
> working in NEON. They were done by Phil before Volk was integrated,
> so they're written in assembly in the filter core. They are also
> automatically selected at runtime, so they should be "just working" 
> for you already. Eventually we'll pull the assembly implementations
> out and put them into Volk.
> 
> If you send me your flowgraph, I'll take a look at it on an E100 and
> see if I can get some things optimized.
> 
> --n
> 
>> 
>> Thanks, Sean  From: Nick
>> Foster [n...@ettus.com] Sent: Tuesday, November 08, 2011 1:27 PM 
>> To: j...@ettus.com Cc: discuss-gnuradio@gnu.org; Nowlan, Sean 
>> Subject: Re: [Discuss-gnuradio] Complex Short/INT16 type
>> 
>> 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 allocated to the VFP rather than the NEON
>> unit. You might find an easy 2x-3x improvement just by doing the
>> heavy lifting in Volk rather than in C++. All o

[Discuss-gnuradio] cmake fails

2011-11-08 Thread Nowlan, Sean 
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.
Please set them or make sure they are set and tested correctly in the CMake 
files:
QT_QTCORE_INCLUDE_DIR (ADVANCED)
used as include directory in directory /home/root/gnuradio/gr-qtgui
QT_QTGUI_INCLUDE_DIR (ADVANCED)
   used as include directory in directory /home/root/gnuradio/gr-qtgui

This error first occurred without specifying -DENABLE_GR_QTGUI=OFF; gr-qtgui 
was disabled anyway due to a missing dependency for qt4. Even after explicitly 
specifying that flag, cmake is still using those variables for some reason.

Thanks,
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] performance improvements and using volk

2011-11-08 Thread Nick Foster 
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 component called gr-basic.
>>
>> The goal of gr-basic is to replace many of the blocks in gnuradio-core
>> with vector optimized blocks that call into volk; and to make it easy
>> for users to extend blocks to support new data types. You can see the
>> branch here: http://gnuradio.org/cgit/jblum.git/log/?h=gr_basic
>>
>> So far, gr-basic has the familiar add, multiply, subtract and divide
>> block, but with 2 major differences:
>>
>> 1)
>> It is very easy to add new data types to these blocks. So it doesn't
>> suffer from the confusing code generation or naming convention issues
>> with the existing adder. So rather than generating gr_add_* for each
>> data type, there is one block add, which takes as a parameter, the data
>> type.
>>
>> 2)
>> Some of the adder implementations use volk routines. We happened to
>> already have a volk routine for adding floats, so rather than calling
>> into the generic implementation, we call into a work function that calls
>> the volk add routine, seen here:
>>
>> http://gnuradio.org/cgit/jblum.git/tree/gr-basic/lib/gr_basic_add.cc?h=gr_basic#n45
>>
>> Just as a rough benchmark, you can expect a 30% savings in overhead from
>> the adder (tested on a sse machine).
>>
>> I hope that this gives users a good starting point for optimizing
>> gnuradio blocks with volk!
>>
>> -Josh
>
> So I like everything about this but the name.  We could stuff all of this
> under the "gnuradio.gr" namespace in Python, or we could name this
> "gr-math."
> Actually, while I was typing this, I'm thinking we rename the directory to
> be "gr-blocks" but put them under the "gnuradio.gr" namespace. I'm expecting
> that since you've used different names for the blocks because of the
> data-type handling that they won't collide with what's in guradio-core right
> now.
> Thanks!
> Tom

The best part is it took Josh and I longer to figure out what to call
it than it took Josh to code it up.

--n

>
>
> ___
> 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] performance improvements and using volk

2011-11-08 Thread Nick Foster 
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 called gr-basic.
>>
>> The goal of gr-basic is to replace many of the blocks in gnuradio-core
>> with vector optimized blocks that call into volk; and to make it easy
>> for users to extend blocks to support new data types. You can see the
>> branch here: http://gnuradio.org/cgit/jblum.git/log/?h=gr_basic
>>
>> So far, gr-basic has the familiar add, multiply, subtract and divide
>> block, but with 2 major differences:
>>
>> 1)
>> It is very easy to add new data types to these blocks. So it doesn't
>> suffer from the confusing code generation or naming convention issues
>> with the existing adder. So rather than generating gr_add_* for each
>> data type, there is one block add, which takes as a parameter, the data
>> type.
>>
>> 2)
>> Some of the adder implementations use volk routines. We happened to
>> already have a volk routine for adding floats, so rather than calling
>> into the generic implementation, we call into a work function that calls
>> the volk add routine, seen here:
>> http://gnuradio.org/cgit/jblum.git/tree/gr-basic/lib/gr_basic_add.cc?h=gr_basic#n45
>>
>> Just as a rough benchmark, you can expect a 30% savings in overhead from
>> the adder (tested on a sse machine).
>>
>> I hope that this gives users a good starting point for optimizing
>> gnuradio blocks with volk!
>>
>> -Josh
>>
>>
> Once again, Josh posts evidence that he's actually a consortium of
> tightly-cooperating
>  cerebella, rather than a single entity :-)
>
> Cool stuff here, Josh.  I like numbers like "30% savings".  Those are
> good numbers.
>
> One of my thoughts today about the VOLK thing is that GRC might easily
> decide at generate-time
>  whether to satisfy a basic block with "standard" or "volked"
> routines.  Maybe even at runtime.

That's kinda what Volk is for, actually. It decides at runtime which
implementation to use, depending on what architecture you're running
and what implementations are available. There's even a volk_profile
utility which profiles each implementation and writes a "hints" file
to select the fastest on your machine. In the absence of the
volk_prefs file Volk will make an educated guess. Since all Volk
blocks include a "generic" C++ fallback implementation, when you Volk
up a block it doesn't matter if there's an accelerated version for
your platform or not; it will fall back gracefully to the generic
implementation.

--n

>
> The performance envelope is going to get more and more interesting now
> that 8-bit sampling has arrived
>  with USRP hardware.  I should probably try an 8-bit 50Msps uhd_fft.py
> at some point, on my 6-core AMD
>  machine to see if it can do it at all.
>
> --
> 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
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cmake fails

2011-11-08 Thread Nowlan, Sean 
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
Sent: Tuesday, November 08, 2011 11:28 PM
To: discuss-gnuradio@gnu.org
Subject: cmake fails

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.
Please set them or make sure they are set and tested correctly in the CMake 
files:
QT_QTCORE_INCLUDE_DIR (ADVANCED)
used as include directory in directory /home/root/gnuradio/gr-qtgui
QT_QTGUI_INCLUDE_DIR (ADVANCED)
   used as include directory in directory /home/root/gnuradio/gr-qtgui

This error first occurred without specifying -DENABLE_GR_QTGUI=OFF; gr-qtgui 
was disabled anyway due to a missing dependency for qt4. Even after explicitly 
specifying that flag, cmake is still using those variables for some reason.

Thanks,
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem(s) while connecting USRP2 with GNURadio

2011-11-08 Thread Harsh Shah 
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:
> 
>
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#load-the-images-onto-the-sd-card-usrp2-only
> 
> If you ran my "build-gnuradio" script, it will have left the firmware 
> images in /usr/local/share/uhd/images
> 


ohk.. i will try the whole process and  discuss about it soon.
Thank you.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem(s) while connecting USRP2 with GNURadio

2011-11-08 Thread Harsh Shah 
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:
> 
>
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#load-the-images-onto-the-sd-card-usrp2-only
> 
> If you ran my "build-gnuradio" script, it will have left the firmware 
> images in /usr/local/share/uhd/images
> 

 i am using the method discuss in below file (UHD only) to load the image on the
sd card for usrp2.

www.csun.edu/~skatz/katzpage/sdr.../loading_sd_card_image.pdf



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio