Hi All,
I wanted to use some of the communication related signal processing
functions in gnuradio. Has anyone done something on these lines before?
Please let me know.
Thank you!
Pradyumna
Pradyumna Desale wrote:
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
We have been planning to do this all the time but no progress yet 
Hey Per,
Thanks for replying! I wanted to start by incorporating channel models
(channel.h if you are familiar with IT++) and was wondering if just
writing
a wrapper function in swig would do the necessary work for us or we have
to
make some specific changes to incorporate those codes in gnuradio
framework.
Any thoughts?
For starters I am going to write a wrapping function for
set_channel_profile() in channel.h (line no. 676) and another wrapper
for
virtual void generate (int no_samples, cvec &output)=0
I was wondering if I should follow the guidelines of how to write a
signal
processing block or there is another method? I am not superbly confident
with swig and it will be awesome to have someone to bounce ideas off of.
Let
me know.
Cheers!
Pradyumna
On Fri, Mar 05, 2010 at 06:15:13PM -0500, Pradyumna Desale wrote:
Hey Per,
Thanks for replying! I wanted to start by incorporating channel models
(channel.h if you are familiar with IT++) and was wondering if just writing a
wrapper function in swig would do the necessary work for us or we have to make
some specific changes to incorporate those codes in gnuradio framework. Any
thoughts?
I’ve been wanting to use the channel coders from IT++ in GNU Radio, and
found writing wrappers is not difficult. I never finished packaging any
code
(though I’ve got some code somewhere, if I find it I’ll send it to you),
but here’s some of the knowledge I gathered:
- The data types of GNU Radio and IT++ are in theory compatible, but in
practice I found you either need to subclass IT++’ “Vec”-class to
directly access the memory, or you need to copy everything by hand
from your input data to the IT++ vector. - In any case, IT++’ structure is pretty coherent, so writing a wrapper
for pretty much anything is fairly straightforward:- Include an object to your channel model (or whatever) in your
block, e.g. a d_rayleigh_channel attribute - In your work function, you need to shift your data from input_data
to your Vec - Load that into d_rayleigh_channel or whatever
- Take the results and copy them to the output_data
- Include an object to your channel model (or whatever) in your
- What’s really simple about it all is that these steps are virtually
the same no matter what you include, be it channels, encoders etc. - Perhaps slightly more difficult would be to adapt the build system
(check for libs etc).
Perhaps this was of any help to you…
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-3790
Fax: +49 721 608-6071
www.cel.kit.edu
KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
On Mon, Mar 8, 2010 at 02:06, Martin B. [email protected] wrote:
I’ve been wanting to use the channel coders from IT++ in GNU Radio, and
found writing wrappers is not difficult. I never finished packaging any code
(though I’ve got some code somewhere, if I find it I’ll send it to you),
The license on IT++ appears to be GPLv2.
If wrapping IT++ code with GNU Radio blocks is as straightforward as
you say, it may be worth it to create a new, optional top-level
component in gnuradio, say “gr-itpp”, that provides wrappers for some
of the more useful bits. This wouldn’t include any IT++ code itself;
the component would just require having IT++ already installed as a
build/runtime dependency. (For people not interested, it just
wouldn’t get configured for build at configure time.)
I would encourage those on the list here to discuss the idea further,
with an aim to figuring out what the “low-hanging fruit” would be.
If there is enough interest, I can create a skeleton top-level
component as a basis for patch submission.
Johnathan
On Mon, Mar 08, 2010 at 08:42:03AM -0800, Johnathan C. wrote:
If wrapping IT++ code with GNU Radio blocks is as straightforward as
you say, it may be worth it to create a new, optional top-level
component in gnuradio, say “gr-itpp”, that provides wrappers for some
of the more useful bits. This wouldn’t include any IT++ code itself;
the component would just require having IT++ already installed as a
build/runtime dependency. (For people not interested, it just
wouldn’t get configured for build at configure time.)I would encourage those on the list here to discuss the idea further,
with an aim to figuring out what the “low-hanging fruit” would be.
IT++ has some nice stuff, it’s well documented and tested. Judging by
the web site, development seems to have stalled at the moment, but from
what I can tell, it seems to be at a pretty mature stage. I guess adding
wrappers would be an easy way to enhance GNU Radio.
Two things I’d like to add:
- Performance might be an issue; it doesn’t seem to have been a design
criterion. This could become a problem when doing, e.g., Turbo
decoding when processor time is already limited by other blocks. - I can’t see a way (read: my C++ skills aren’t that advanced) to create
a generic wrapper which could take any IT++ block in a consistent
manner. As far as I can tell, it would be necessary to create one GR
block by hand for every IT++ function.
The last point is not a big problem in my opinion, since there’s not
that much stuff in IT++ which is really interesting in GR (basically the
channel models and the FECs).
As I said, I already had a look at this and seeing there’s some
interest, I’d give it a hack.
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-3790
Fax: +49 721 608-6071
www.cel.kit.edu
KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
On Tue, Mar 09, 2010 at 11:38:48AM +0100, Martin B. wrote:
The last point is not a big problem in my opinion, since there’s not
that much stuff in IT++ which is really interesting in GR (basically the
channel models and the FECs).
As I said, I already had a look at this and seeing there’s some
interest, I’d give it a hack.
I had a bash at this, and uploaded the result on CGRAN. The result is
not the most beautiful code ever written, and not tested outside my box,
so be careful.
Just grab https://www.cgran.org/svn/projects/itplusplus/trunk/gr-itpp
Included stuff:
- Some block codes (Hamming, RS and extd. Golay). Adding these was
pretty simple. - Bessel functions (not something you need everyday, but it was there).
Adding these was even simpler. - Access to TDL_channel. This was a bit of a challenge and will probably
not do what most people want it to. The problem is, the itpp-class
was not really designed for continuous streaming. Now, it takes
vectors of signals and applies a channel to these. The next vector
will create new channel coefficients. It might be possible to extend
this to continuous streaming, but I will not be attempting this
anytime soon.
Some caveats:
- IT++ is not designed to be thread-safe, this must be taken care of at
GR-level. - Input arguments aren’t always checked thoroughly when initializing
classes, so sometimes checks are necessary in the GR blocks. - Wrapping the encoders was easy, because the data types were
bit-compatible. The channel was more difficult, because IT++ uses
complex internally. For the moment, a lot of copying-by-hand
is done.
And, erm, the build system, ahem, was not adapted. So, if you don’t have
IT++ installed, configure will not complain. I simply added a command
for the linker in lib/Makefile.am and prayed.
By Sod’s law, this will not work if you try it at home, but since there
was some interest on the list I didn’t want to keep my code lying around
on some hard drive. If someone wants to try it, I’d appreciate some
feedback.
Martin
–
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-3790
Fax: +49 721 608-6071
www.cel.kit.edu
KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association