Detecting EOF of previous block

GNU Radio
1

Dear list,

I have another question regarding stopping the flowgraph. This time it
is
about streaming blocks, no messages involved at all.

My flowgraph looks like this (block A) --byte–> (block B) --byte–>
…

Block A is a byte source that signals EOF at a certain point, lets
assume
after sending out 11 bytes.

Block B is a ratio 1:1 sync block which works on groups of input items,
say 5 bytes. If B’s work is provided with less than 5 samples it will
return 0 and wait to get more samples.

Unfortunatley the blocksize of block B is not fixed but based on a
state,
so I can’t call set_output_multiple to tell the scheduler to only
provide
me with multiples of 5 bytes because a few items later it might change
to
6 bytes.

As you can see from the example above B will process the first 10 bytes
like expected, but then there is still one byte left to be processed by
B.
The problem I have is to detect whether block B is asked to process only
one byte, because that’s all the scheduler has so far (but A will
produce
more), or if it is asked to process this one sample because that is the
last one available (A has already signaled EOF).

Is there any build in way to detect that the previous block in the
flowgraph has already signaled EOF? The only way I could think of is to
attach an EOF stream tag to the stream in the previous block A and
evaluate the tags in block B. Are there any other approaches/ideas?
Might
a general EOF tag be a good idea for gnuradio (so that file source and
head or even the scheduler itself attach the EOF tag)?

Martin

2

Hi Martin,

this won’t 100% answer your Q’s, but perhaps it’ll help:

On Thu, Feb 14, 2013 at 02:37:43PM +0100, “Martin Lülf” wrote:

Block B is a ratio 1:1 sync block which works on groups of input items,
say 5 bytes. If B’s work is provided with less than 5 samples it will
return 0 and wait to get more samples.

We do this a lot in the experimental OFDM branch; an easy example might
be the CRC block:
https://github.com/benreynwar/gnuradio/blob/ofdm/gr-digital/lib/digital_crc32_bb.cc

Unfortunatley the blocksize of block B is not fixed but based on a state,
so I can’t call set_output_multiple to tell the scheduler to only provide
me with multiples of 5 bytes because a few items later it might change to
6 bytes.

You can call set_output_multiple() from within work(). Remember to
re-set it.

evaluate the tags in block B. Are there any other approaches/ideas? Might
a general EOF tag be a good idea for gnuradio (so that file source and
head or even the scheduler itself attach the EOF tag)?

My guess is stream tags are the easiest solution. If you’re saving state
anyway in your downstream block, you might as well add another case for
the final block, i.e. a tag that says “here’s 3 items, and there won’t
be any more”.

In most cases, a dedicated EOF tag wouldn’t be useful, though. When a
file source hits EOF, it usually shuts down the flow graph by returning
-1, and the downstream blocks eventually stop, too.
This might even be enough in your case; if you use set_output_multiple()
in work, there is still something (but not enough) in the input buffer
for your block B, and you don’t really need to process that (because
it’s just a dangling byte), perhaps this is all you need.

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

Hi Martin,

your suggested solution of dynamically resetting multiple_output was
indeed a very good hint. With this I was able to terminate my block
without interrupting from the outside. Thank you!

However a problem that I still have is that the last pieces of data get
dropped if there are not enough to form a full output_multiple (as you
already suggested in your mail). As these last bits still contain
valuable information I somehow still need to process them. In order to
do so I would like to detect the upcoming end in my block so that I can
pad my input with enough zeros to retrieve a full output block instead
of cutting away the end.
Since a few additional outputs don’t hurt my application right now I add
a trailing zero sequence at my source, however this causes some problems
with unit testing as I can’t predict the number of trailing zero blocks
that might additionally be generated at the output.

So my question is: Can I make gnuradio to not drop the last bits if
there are less items left than necessary to create output_multiple items
but instead present this few items to my block together with the
information that these are not as much items as expected for a full
block?

Yours
Martin

4

On Mon, Feb 18, 2013 at 12:22:52AM +0100, Martin Lülf wrote:

So my question is: Can I make gnuradio to not drop the last bits if
there are less items left than necessary to create output_multiple
items but instead present this few items to my block together with
the information that these are not as much items as expected for a
full block?

Not out of the box, no. set_output_multiple kind of assumes the block
doesn’t know how to handle anything else, so what you’re asking for
doesn’t make sense to the scheduler.

I suggest:

  • Setting set_output_multiple() only when the input is invalid;
    otherwise, set_output_multiple(1)
  • Put a tag on the last set of items and check for that.

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