Gnuradio block for boolean operations

GNU Radio
1

Hello all,

I want to perform some simple boolean operations on a stream of data.
For example invert the bits from the output of the demodulators or
convert
from NRZ to NRZI

I was thinking something like

  1. gr_xor_bb, gr_and_bb, gr_or_bb, br_not_bb …
    or
  2. maybe gr_boolean(“xor”) , gr_boolean(“and”) …

Is this something someone has started?

Is there another way I should go about this?

If this is something that should be done can someone give me an idea of
the
desired format (1 or 2 or something else)

Tim

2

On 2/14/08, Tim M. [email protected] wrote:

  1. gr_xor_bb, gr_and_bb, gr_or_bb, br_not_bb …

This would be the way to go. Alternatively, you could create these
blocks as _ss or _ii, and work on packed data. Depending on where in
your flowgraph you need this operation, this would be much faster.
See:

http://gnuradio.org/trac/browser/gnuradio/trunk/gr-gpio/src/lib/gpio_and_const_ss.cc

…for an example of a block that logically ANDs a stream of short
integers with a constant value.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

3

Johnathan,

I have attached a patch to gnuradio-core/src/lib/gengen that provides
gr_xor_bb, gr_xor_ii and gr_xor_ss. The patch also contains qa code
dumped
into gnuradio-core/src/python/gnuradio/gr

If this is the format you are looking for I will quickly gen up some
other
boolean functions. If you don’t think it is appropriate for
incorporation
into the code base that is OK to.

I think the gengen directory should have svn:ignore set on Makefile.gen
and
gengen_generated.i. These both show up in the svn diff but I removed
them
from the patch

The svn:ignore flag will need to be set for new generated c/h files i.e.
gr_xor_bb.c gr_xor_bb.h …

Tim

On Feb 16, 2008 8:09 AM, Johnathan C.
[email protected]
wrote:

On 2/14/08, Tim M. [email protected] wrote:

  1. gr_xor_bb, gr_and_bb, gr_or_bb, br_not_bb …

This would be the way to go. Alternatively, you could create these
blocks as _ss or _ii, and work on packed data.

Depending on where in

4

Thanks for the input Ed. Some comments below

Purely from the point of view of “cohesion” I would recommend
the “gr_xor_bb” form instead of passing in a selector that
determines the behavior. Although I must admit, I wrestled
for quite a while with writing so much infrastructure code
for something as simple an an “xor”.

[tim] I think the auto code generators in gengen is a good compromise

[tim] One note on your nrzi_to_nrz code below. I don’t know much about
compiler optimization but I suspect

nrz_bit = ! nrzi_bit ^ d_prev_nrzi_bit

might give you better performance than the if else. Then again I have
been
wrong more than I have been right
on this sort of thing :slight_smile:

5

Tim M. wrote:

  1. maybe gr_boolean(“xor”) , gr_boolean(“and”) …

Is this something someone has started?

I have written both xor_bb and nrzi_to_nrz_bb and used them
on 2 different projects.

Is there another way I should go about this?

If this is something that should be done can someone give me an idea of
the desired format (1 or 2 or something else)

Purely from the point of view of “cohesion” I would recommend
the “gr_xor_bb” form instead of passing in a selector that
determines the behavior. Although I must admit, I wrestled
for quite a while with writing so much infrastructure code
for something as simple an an “xor”.

Here’s the code for gr_nrzi_to_nrz_bb. The code for xor
is similar.

@(^.^)@ Ed

/* -- c++ -- /
/

  • Copyright 2006 Free Software Foundation, Inc.
  • This file is part of GNU Radio
  • GNU Radio is free software; you can redistribute it and/or modify
  • it under the terms of the GNU General Public License as published by
  • the Free Software Foundation; either version 2, or (at your option)
  • any later version.
  • GNU Radio is distributed in the hope that it will be useful,
  • but WITHOUT ANY WARRANTY; without even the implied warranty of
  • MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  • GNU General Public License for more details.
  • You should have received a copy of the GNU General Public License
  • along with GNU Radio; see the file COPYING. If not, write to
  • the Free Software Foundation, Inc., 51 Franklin Street,
  • Boston, MA 02110-1301, USA.
    */

#ifdef HAVE_CONFIG_H
#include “config.h”
#endif

#include <gr_nrzi_to_nrz_bb.h>
#include <gr_io_signature.h>
#include

gr_nrzi_to_nrz_bb_sptr
gr_make_nrzi_to_nrz_bb (bool preload)
{
return gr_nrzi_to_nrz_bb_sptr (new gr_nrzi_to_nrz_bb (preload));
}

gr_nrzi_to_nrz_bb::gr_nrzi_to_nrz_bb (bool preload)
: gr_sync_block (“nrzi_to_nrz_bb”,
gr_make_io_signature (1, 1, sizeof (unsigned char)),
gr_make_io_signature (1, 1, sizeof (unsigned char))),
d_prev_nrzi_bit(preload)
{
}

int
gr_nrzi_to_nrz_bb::work (int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const unsigned char* in = (const unsigned char ) input_items[0];
unsigned char out = (unsigned char *) output_items[0];
unsigned char nrzi_bit;
unsigned char nrz_bit;

for (int i = 0; i < noutput_items; i++)
{
nrzi_bit = in[i];
// Convert NRZI to NRZ.
if(nrzi_bit != d_prev_nrzi_bit)
{
nrz_bit = 0;
}
else
{
nrz_bit = 1;
}
out[i] = nrz_bit;
d_prev_nrzi_bit = nrzi_bit;
}
return noutput_items;
}

6

Tim M. wrote:

[tim] I think the auto code generators in gengen is a good compromise

Agreed.

[tim] One note on your nrzi_to_nrz code below. I don’t know much about
compiler optimization but I suspect

nrz_bit = ! nrzi_bit ^ d_prev_nrzi_bit

might give you better performance than the if else.

I long ago learned the mantra “Get it right first, then make
fast. Its always easier to make correct code perform faster than
it is to make fast code perform correctly.”

The code was written for easy comprehension. You must admit
that the binary operators, while more elegant, are a bit more
cryptic to a reader. Once the code was tested, it ran
fast enough for my needs, so I didn’t pursue optimizing it.

… Then again I have
been wrong more than I have been right
on this sort of thing :slight_smile:

Me too. I find that FAR more often than not (70-80% of the time),
profiling shows that the bottleneck is NOT where you would have
first thought. And today’s optimizing compilers are very VERY
good. That’s why we can do so much of GnuRadio in C++ instead
of assembler.

As for this case, I just don’t know. An inequality comparison,
a jump, and an assignment vs a complement, an xor, and
an assignment. My gut feel is that in either case, the total
time taken is probably insignificant compared to the
overhead/buffer processing done for any gr_sync_block.
But the only way to really know is to profile.

@(^.^)@ Ed