Detecting "EOF" in stream-in-message-out block

GNU Radio
1

Hi,

I’m having hard time using GNU Radio to replace Simulink :slight_smile:

I’d like to build a QA flowgraph (think of evaluating a BER vs. SNR
curve) to assess the performance of my signal processing chain. The
problem is that the signal processing chain starts with blocks passing
messages around, then there are ordinary stream blocks, but at the
receiving side, I again have a block with stream input and message
output.

Propagating PMT_EOF tags on the transmitter side takes care of shutting
down the flowgraph whenever I want it to, and as the input for the
stream blocks dry up, they die nicely as well. However, I’m unable to
detect the end of the “input” in my receiver block, which takes stream
and produces message. The flowgraph simply hangs indefinitely as
expected (?), because I don’t propagate EOF PMTs downstream, and hence
set_done() doesn’t get called down the path.

I’d like to avoid passing stream tags through the stream blocks from the
transmitter to the receiver, for multiple reasons (not only because I’m
lazy but it’d also require changing a lot of stuff in the intermediate
message-passing blocks. Also EOF should be able to come after the last
piece of data, independently, not somehow glued to it.)

Is there a better way to detect this?
Thanks,
Peter

2

On Mon, Aug 12, 2013 at 5:35 PM, Peter H. [email protected]
wrote:

Propagating PMT_EOF tags on the transmitter side takes care of shutting down
message-passing blocks. Also EOF should be able to come after the last piece
of data, independently, not somehow glued to it.)

Is there a better way to detect this?
Thanks,
Peter

Peter,

Stopping conditions like you’re asking aren’t well defined. There’s no
one solution to this, partly because GNU Radio is meant to function as
a continuously streaming system.

You’ll want to use the stream tags for this in some way, though. But I
agree that you don’t want to pass them from the transmitter to
receiver. From my perspective, that’s kind of cheating since in any
real scenario, the two sides won’t be connected together and you would
be able to receive a tag at the receiver.

What you want is something in the receiver that recognizes the end of
the data stream and generates a tag from that. Then your
stream-to-message block will have to wait until it receives that tag
before shutting down. But a tag has to be associated with the data
stream, so you might have just send 0’s to make sure you get that last
tag.

–
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13