Questions about gr_block

Good morning!

I started writing a small signal processing block (OFDM transmitter) and
ran
into some problems.

My starting point was the well written gr-how-to-write-a-block tutorial.

I have, let’s say, 1536 input samples and want to produce 1800 output
samples with my block. When I run my code with small values
(say fft size of 32) I get valid OFDM symbols but a lot of zeros in
between. When I uses higher values either the scheduler quits

(
sched: <gr_block ofdm_tx_vcc (0)> is
requesting more input data
than we can provide.
)

or even the buffer can’t be allocated. This makes me sure that there is
a programming mistake on my part, but I can’t seem to find it.
I would be thankful if somebody could point out my mistake? The main
files are attached, a modified gr-how-to-build-a-block can be found
here:
http://www.1c3.de/gr-dab.tar.bz2 .

Yet another question: Can blocks somehow interchange values? I would
like to write two blocks, one that estimates a frequency offset and
another one that compensates it (simple modulation). Or do I have to
do that in one block?

Jens

Ok, never mind, my error was based on a fundamental misunderstanding of
what “io_signature” defines: I found the answer in the mailing list.

It would be great to see just a few words about this in the
“how-to-write-a-block” tutorial.

Have a nice week-end,
Jens

On Thu, Jul 20, 2006 at 12:54:25PM +0200, Jens E. wrote:

between. When I uses higher values either the scheduler quits
files are attached, a modified gr-how-to-build-a-block can be found here:
http://www.1c3.de/gr-dab.tar.bz2 .

Yet another question: Can blocks somehow interchange values? I would
like to write two blocks, one that estimates a frequency offset and
another one that compensates it (simple modulation). Or do I have to
do that in one block?

Jens

#include
*/
GR_SWIG_BLOCK_MAGIC(ofdm,tx_cc);

ofdm_tx_cc_sptr ofdm_do_tx_cc (int ofdm_sym_len, int gi_len, int fft_len);

class ofdm_tx_cc : public gr_sync_block
{
private:
ofdm_tx_cc (int ofdm_sym_len, int gi_len, int fft_len);
};

#include <gr_io_signature.h>
{

  • only 1 input and 1 output.
    */
    set_output_multiple(d_ofdm_sym_len);
    ofdm_tx_cc::~ofdm_tx_cc ()
    {

         gr_vector_void_star &output_items)
    

    out += d_ofdm_sym_len;
    // Tell runtime system how many output items we produced.
    return out_count;
    }

#ifndef INCLUDED_OFDM_TX_CC_H

  • to gr_blocks (and many other data structures). The shared_ptr gets
    /*!
  • \ingroup block

// Where all the action really happens
#endif /* INCLUDED_OFDM_TX_H */

p2s = gr.parallel_to_serial (gr.sizeof_gr_complex, ofdm_sym_len)

self.fg.run()

if name == ‘main’:
gr_unittest.main ()

On Fri, Jul 21, 2006 at 08:01:29PM +0200, Jens E. wrote:

Ok, never mind, my error was based on a fundamental misunderstanding of
what “io_signature” defines: I found the answer in the mailing list.

It would be great to see just a few words about this in the
“how-to-write-a-block” tutorial.

Have a nice week-end,
Jens

Jens,

If you could say a bit more about what was missing, we could fix it :wink:

Or better yet send a patch for the document. It’s source is
stored in gr-howto-write-a-block

Thanks,
Eric

On Fri, Jul 21, 2006 at 09:14:12PM +0200, Jens E. wrote:

Hi Eric,

I just got confused by the explanation of the 1:1 relationship. It’s
of course perfectly clear if one thinks about it.

Jens

703,706c703
< requirements for each input stream. The size of the items is defined by
< gr_io_signatures in the constructor of
< gr_block. The sizes of the input and output items
< can of course differ, this still qualifies as a 1:1 relationship.

requirements for each input stream.

Thanks! I’ve updated the source and updated the copy on the web page.

Eric

On Fri, Jul 21, 2006 at 11:36:08AM -0700, Eric B. wrote:

Jens,

If you could say a bit more about what was missing, we could fix it :wink:

Or better yet send a patch for the document. It’s source is
stored in gr-howto-write-a-block

Hi Eric,

I just got confused by the explanation of the 1:1 relationship. It’s
of course perfectly clear if one thinks about it.

Jens