[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Detecting "EOF" in stream-in-message-out block

From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Detecting "EOF" in stream-in-message-out block
Date: Wed, 14 Aug 2013 17:22:16 -0400

On Mon, Aug 12, 2013 at 5:35 PM, Peter Horvath <address@hidden> wrote:
> Hi,
> I'm having hard time using GNU Radio to replace Simulink :)
> 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


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

Visit us at GRCon13 Oct. 1 - 4

reply via email to

[Prev in Thread] Current Thread [Next in Thread]