Re: [Discuss-gnuradio] extract timestamp data / "The Plan"

[Johnathan Corgan]

On Fri, Mar 13, 2009 at 7:53 AM, Eric Blossom <address@hidden> wrote:

> Thus we will have a common base class for all blocks, and blocks may
> have input and output streams (like they do now) or the ability to
> send and receive messages, or both.

Just to amplify on this, this "message passing" addition to gr-blocks
and hier_block's will generalize the idea of a signal processing block
to have both streaming and/or packetized input and output semantics.
Here are a few examples of what this will enable:

It will become possible to write a block that say, accepts a stream of
complex float baseband samples on a streaming input, does demodulation
and frame detection, and then posts packets with metadata to a
supplied message port.

It will become possible to write blocks that accept packetized data,
with metadata, perform modulation, and stream continuous samples to an
output port.

It will become possible to write blocks that work entirely in the
message passing domain, such that they accept data and metadata,
perform some operation on the data, modify/update the metadata, then
post the data to another block.

We will be able to add source and sink blocks to the USRPx interfaces
to allow posting incoming samples as timestamped blocks of data or
accept timestamped blocks of samples for transmission.

Blocks will have either a work() type streaming I/O function and/or a
handle_msg() function (or both).  In addition, the handle_msg function
will be possible to write in Python, affording a simple way to get
information out of the flowgraph and into other programming domains
such as GUIs.

There are a few other possibilities that having message handlers will
allow, such as thread-safe parameter updates and a simplified
"publish/subscribe" method of interacting with flowgraphs.

Alas, getting 3.2 "stable" out comes first :)

Johnathan