From Eric’s message on 13.03.2009:

There currently isn’t a way to get at the timestamp (which is contained in the usrp::rx_metadata structure), using the gr-usrp2 interface.

Right now we’re in the midst of squashing bugs and sorting through the backlog of patches in order to get the 3.2 release out the door. As soon as that is done, we’re going to start on some enhancements to GNU Radio that I think will give you what you’re looking for.

There are two distinct but related features:

The first is designed to uniformly allow blocks to have a “packet based” or “message passing” interface, similar to what we attempted with the “message block” (m-block) code. We have found that although the m-block code makes certain classes of problems easy to solve, it was hard to interface to the existing data flow blocks. The new plan is to provide all blocks (including hier_blocks) with the ability to send and receive messages containing packetized data. The messages will use the PMT data types, similar to how it was done with m-blocks. All blocks will have a “message receiver” (aka “port”) (and there may be “message receivers” that are not associated with blocks), that by default discards anything sent to it. The organization will be much less rigidly structured than m-blocks are. It’ll be closer to Erlang’s model of the universe: if you’ve got access to a “message receiver” (aka port), you can send to it.

We will come up with some conventions on representing “payloads” and “metadata”, but all will be built from PMT types. We will most likely extend the PMT types to add a non-mutable tuple type, similar to Python and Erlang.

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.

The second feature will allow us to attach (key, value) attributes to a position (sample offset) in a stream. Schematically one could imagine something like (Key=Timestamp, Value=XXXX, Offset=YYYY) being used to indicate the position and FPGA timestamp associated with the sample that corresponds to the start of the underlying frame. By default, existing blocks would transparently propagate any attributes contained on their input streams to their output streams. Blocks that cared about the attributes could query their input streams to locate all (key, value, offset) tuples in the region of the stream that they are currently working on in their “work” method. Likewise, blocks could copy, add or delete attributes on their output streams.