How to integrate a specific number of vectors element-wise in gnuradio?

Dear Gnuradio enthusiasts,

Short version:
Does someone have a good approach to average a specific (but large)
number
of vectors together element-wise with the exactly same relative weight?
Say
I want the two vectors [1,2,3,3] and [1,2,3,4] coming one after another
giving the output [1,2,3,3.5] - is there any block available that does
this
and if so: how? (In reality I will have many more vectors and elements
though).

Long version:
I’m building an application for radio astronomy using Gnuradio and the
USRP. I think I have hit a point where I have to write my own custom
blocks
for gnuradio to accomplish what I want, but before I dive into that I
want
to ask you as well if you have already solved this current problem of
mine.
I have tried to google this extensively and gotten closer and closer but
without finding exactly what I need. I have played with the
Gnuradio-companion and find it very helpful. I have some python
experience
but not much C++, hence my hesitation to dive into the custom block
writing
before I made sure no-one has already solved this.

The grand plan is as follows:

  1. Use an USRP to recieve a signal, I know how.
  2. Divide the stream of samples into vectors, I know how.
  3. Take the FFT of the vectors one by one, I know how.
  4. Average the vectors coming from the FFT together element-wise. I
    don’t
    know how.
  5. Save the averaged vector to a file, I know how.

What I cannot solve is step 4: I need to take the N vectors (each of
size
M) coming from the FFT-block and sum them together element-wise to
produce
one vector of size M.

I found Jonathan Corgans interesting reply to a similar question on “How
to
integrate a vector signal” at
http://lists.gnu.org/archive/html/discuss-gnuradio/2007-04/msg00146.htmlwhere
Jonathan advises to use the gr.single_pole_iir_filter_xx block with a
parameter 0<alpha <1. It seems to me that such an approach works well if
one wants to average “a couple” of vectors, and also if you want to
apply
weights to the averaging. But, if I want to average Exactly say 1027
vectors together with Exactly the same weight to all of them, it seems
to
me that I cannot use the single_pole_iir_filter. Am I mistaken? At least
I
have not managed to make it do what I want. Perhaps this is the solution
and I’m just confused by the signal processing language which I’m not
used
to yet (I have a more theoretical physics/math background).

I found Jonathan Corgans entries from 2006 on vector addition in
Gnuradio,
http://lists.gnu.org/archive/html/patch-gnuradio/2006-06/msg00002.html
and
I can use the adder in Gnuradio companion. So, in principle I could
split
my vectors in N streams, convert each stream to a vector again, feed
them
to a vector adder with N inputs and then get the output I want. But it
seems suboptimal to have to deal with this splitting step to N inputs. I
just want to add the vectors element-wise.

I found the simple_ra package which claims to do things for radio
astronomy
very similar to what I want to do (
https://www.cgran.org/wiki/simple_ra#ProjectDescription). But, the
unfortunately I have not found any extensive documentation of the code
and
I have not yet managed to understand if I can extract a solution to my
problem from there. To use part of the simple_ra package functionality
as a
black-box is unfortunately no option since I have similar projects in
mind
if I solve this one, but they would not be related to radio astronomy.

Hence my question: Does someone have a good approach to average a
specific
(but large) number of vectors together element-wise with the exactly
same
relative weight? Say I want the two vectors [1,2,3,3] and [1,2,3,4]
coming
one after another giving the output [1,2,3,3.5] - is there any block
available that does this and if so: how?

Best regards,
Eskil Varenius

On Mon, Jun 24, 2013 at 02:09:51PM +0200, Eskil Varenius wrote:

vector of size M.
The spectral estimation toolbox (gr-specest) has a block to do this
(moving_average_vff). You can get it through PyBOMBS, it is not yet
3.7-compatible, though.

MB


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
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

Long version:

to produce one vector of size M.
Am I mistaken? At least I have not managed to make it do what I want.
output I want. But it seems suboptimal to have to deal with this
related to radio astronomy.


Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
I’m curious as to why, in radio astronomy, you need to be able to
control the number of FFTs you average together. Since nature isn’t
nearly so
exacting as, for example, telecommunications, in that regard.

The “code” in simple_ra is produced by a .grc flow-graph. The .grc
flow-graph is shipped with the code, and such flow-graphs are
very-nearly
self-documenting. There’s also a README that comes with it. Since
I maintain simple_ra as a very-much part-time time, and I have a handful
of other applications I support/maintain, and I’m the
maintainer/author of build-gnuradio, I haven’t had time to write more
extensive documentation.

Hi everyone,
After a long break since June I am now back learning about Gnuradio. I
asked in June for a way to average vectors elementwise and Martin B.
suggested the moving_average_Vff block in the gr-specest. He also said
it
would be available PyBOMBS. Now update:

Since I had installed Gnuradio using the build-script I wanted to
re-install it using pybombs. I uninstalled the old gnuradio by doing a
“sudo make uninstall” in each build directory for the old release. Seems
to
work. Now I installed gnuradio 3.6 (since gr-specest is still only
verified
for 3.6, although I’m happy to see people working towards a 3.7
release). I
did the install using the instructions on the pybombs quickstart page:

git clone git://github.com/pybombs/pybombs
cd pybombs
git checkout gr-3.6
./pybombs install gnuradio

Gnuradio seemed to install without problems but: I realised I had
path-problems since I could not start anything (gnuradio companion,
import
gnuradio etc. fails). Perhaps this was related to me using a custom
target
directory (/opt/gnuradio_pybombs). I looked around and found path
instructions for custom directory installs at "
http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installing-in-a-custom-directory",
i.e. put the following in my .bashrc:

GNU Radio installation

export PATH=$PATH:/opt/gnuradio_pybombs/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gnuradio_pybombs/lib
export
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/gnuradio_pybombs/lib/pkgconfig
export
PYTHONPATH=$PYTHONPATH:/opt/gnuradio_pybombs/lib/python2.6/site-packages

However, that didn’t work completely - I still could not find the
gnuradio
python module. I realised two things: the 2.6 should probably be 2.7 for
me, and also the pythonpath should end in dist-packages, not
site-packages,
since the site-packages folder was empty. After modifying the pythonpath
with 2.7 and dist-packages everything runs, I can import gnuradio and
also
use gnuradio companion. So far so good!

Now for gr-specest. I tried to install it using app store (cool stuff,
you
guys are amazing!) and also just command line which is equivalent, i.e.
I
run using “sudo ./pybombs install gr-specest” I get a lot of output, but
the perhaps most interesting one before it ends abruptly is:
– checking for module ‘gruel’
– package ‘gruel’ not found
– Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS)
– checking for module ‘gnuradio-core’
– package ‘gnuradio-core’ not found
– Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:100 (message):
Gruel required to compile specest

I am lost here. Any ideas? I can give the rest of the output as well,
but
this is the showstopper as far as I can see. I have tried googling this,
but it seems to me that the solution used is to use the build-gnuradio
script instead of PyBOMBS. I could do that, but then I would not be able
to
enjoy installing gr-specest through the app-store ;). Grateful for any
advice.

Cheers,
Eskil

2013/6/24 Martin B. (CEL) [email protected]

I updated gr-specest so it would compile with 3.7, see my repo on
dfxx · GitHub if you want to try that route. The changes were
almost
all namespace stuff and cmake stuff, i.e. I don’t think I broke
anything.

Jared

Thanks for the link, sounds interesting. I will wait a few days to see
if
someone has ideas on the PyBOMBS issues I experience. Else I will try gr
3.7 and your specest version.
Best regards,
Eskil

2013/10/4 Jared C. [email protected]

I’ve been poking around in other GRC files to find examples. The ones
in
specest are a little tough around the edges, but I’ve found the ones in
GNURadio/gr-fft and other sub blocks of GNURadio to be decent examples.
Rgrep has been helpful…

Jared

Hi again,
I uninstalled what I had installed through PyBOMBS and installed
Gnuradio
3.7 through the build_gnuradio script. Then I tried Jareds repo for
specest
with 3.7 (dfxx · GitHub) and it seems to compile just fine,
well done! I can also import specest in python without problems.

Now: I would very much like to use the block moving_average_vff in
Gnuradio
Companion. Unfortunately it seems there are no xml files for that block,
hence invisible to the GRC. I got a hint from Martin B. that I could
use
the “gr_modtool makexml” command to generate this. Unfortunately it
seems
that I don’t understand how to use it:

gr_specest_jared$ ls
apps AUTHORS build cmake CMakeLists.txt COPYING docs examples
grc
include lib python README swig
gr_specest_jared$ gr_modtool makexml moving_average_vff
GNU Radio module name identified: specest
Warning: This is an experimental feature. Don’t expect any magic.
Searching for matching files in lib/:
None found.

There is a file called moving_average_vff.cc in the lib directory, so I
guess something more is needed here which I don’t know about.

I tried looking at the page
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules?version=16#Making-your-blocks-available-in-GRCwhere
there are links to example xml blocks to understand a bit more, but
it seems these links are broken. Also the link to the gr_block
documentation in the next section (There’s more:…) is broken.

I’m grateful for any hints on how to make the block moving_average_vff
visible in the GRC.

Best regards,
Eskil

2013/10/4 Jared C. [email protected]

Thanks for the ideas, I could do that and Rgrep seems useful indeed.
However, I’m new to coding Gnuradio and would like to use the tools
provided as far as possible, i.e. I would very much like to use the
gr_modtool to help me with creating the xml files. But, after some
investigations it seems the gr_modtool cannot be used in this case since
there is no “_impl” file for the moving_average_vff.cc. This raises a
few
basic questions which I’ve tried to answer reading e.g. the coding guide
at
http://gnuradio.org/redmine/projects/gnuradio/wiki/Coding_guide_impl and
http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide#Implementation-Source-File.
But these instructions are I feel a bit over my head at the moment since
I’m new to the block coding, so instead I have three more basic
questions
which I hope someone could help me with:

  1. What is the relation between cc files in the lib directory with and
    without the _impl suffix?
  2. Does the file moving_average_vff.cc need to be converted into a
    _impl.cc
    file before I can use this block with gnuradio companion, or can I go
    ahead
    and write an XML file for the current block files?
  3. Where should I start reading if I want to learn how to convert the
    block
    moving_average_vff to something that can be recognized by the gr_modtool
    makexml?

I’m sorry if these questions are stupid or the wrong forum, but I’m very
grateful for all ideas and pointers to get me on the right track. If
there’s a better place to ask these things, please let me know.

Best regards,
Eskil

2013/10/8 Jared C. [email protected]