A few questions about subclassing gr_block

GNU Radio
1

Hello,

I am trying to create a block that detects sync patterns at baseband
tagging the first sample of the pattern using stream tags, then using
the
tags down stream as part of demodulation. I have made a few assumptions
about how gnuradio works that I would like to validate:

  • a sync pattern could span two blocks of samples passed to general_work
  • I need to keep SYNC_PATTERN_LENGTH - 1 samples to get around this, so
    I
    should be able to use a general block and not output all of the items
  • you can’t tag historic samples (i.e. samples obtained using
    set_history),
    so I can’t use that

are these all reasonable?

Currently I have an implementation of the block, but I am having trouble
understanding the relationship between ninput_items and noutput_items.
When I feed the block from a file source consisting of 720 samples, I
get
ninput_items[0] = 720 and noutput_items = 512. Does this value for
noutput_items mean I can only consume and copy 512 of the input samples?
And do I need to implement forecast if I want to output more?

Thanks in advance for any help,
Mark

–

This email, including any attachments, is only for the intended
recipient.
It is subject to copyright, is confidential and may be the subject of
legal
or other privilege, none of which is waived or lost by reason of this
transmission.
If you are not an intended recipient, you may not use, disseminate,
distribute or reproduce such email, any attachments, or any part
thereof.
If you have received a message in error, please notify the sender
immediately and erase all copies of the message and any attachments.
Unfortunately, we cannot warrant that the email has not been altered or
corrupted during transmission nor can we guarantee that any email or any
attachments are free from computer viruses or other conditions which may
damage or interfere with recipient data, hardware or software. The
recipient relies upon its own procedures and assumes all risk of use and
of
opening any attachments.

2

On Fri, May 03, 2013 at 11:04:40AM +1200, Mark Cottrell wrote:

I am trying to create a block that detects sync patterns at baseband tagging
the first sample of the pattern using stream tags, then using the tags down

That’s the correct way to do it, if you ask me.

Just to clarify: Before you get a sync pattern, are you producing
anything? Or are your copying all of the input to the output, plus the
tag? If the latter is the case, you should use a sync_block.

stream as part of demodulation. I have made a few assumptions about how
gnuradio works that I would like to validate:

  • a sync pattern could span two blocks of samples passed to general_work

It depends on your sync pattern. If it’s not too long, you can avoid
that.

  • I need to keep SYNC_PATTERN_LENGTH - 1 samples to get around this, so I
    should be able to use a general block and not output all of the items

  • you can’t tag historic samples (i.e. samples obtained using set_history), so
    I can’t use that

You can also use ‘future’ samples to do signal processing. An example
are the peak_detector blocks, which find the beginning of a peak.

Simply don’t consume them.

Currently I have an implementation of the block, but I am having trouble
understanding the relationship between ninput_items and noutput_items. When I
feed the block from a file source consisting of 720 samples, I get ninput_items
[0] = 720 and noutput_items = 512. Does this value for noutput_items mean I
can only consume and copy 512 of the input samples? And do I need to implement
forecast if I want to output more?

That depends. Do you really want to output more? How many? What if
your have 1440 items at the input?

Basically, this is telling you there’s space for 512 items in the output
buffer. If you can use a sync_block, you’ll never run into these
problems, because there’s only one value.

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

3

On Fri, May 03, 2013 at 09:08:34AM +0200, Martin B. (CEL) wrote:

Basically, this is telling you there’s space for 512 items in the output
buffer. If you can use a sync_block, you’ll never run into these
problems, because there’s only one value.

Also, there’s lots of other functions to control the output buffer size,
e.g. set_output_multiple(), set_min_output_items()…

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