On Tue, Mar 10, 2009 at 01:51:15PM -0600, Pham, Thanh wrote:
> Hello,
>
> I got complex samples from the usrp2 from usrp2.source32fc. Is there a
> gnu radio class to extract the time stamp from the data coming in from
> the usrp2? I read on archive that the timestamp is included in the
> Ethernet frame but I don't see any help on how to extract it. Has anyone
> attempted to extract timestamp from the usrp2 data frame ? I would
> appreciate if someone has an example or something I can look at.
>
> Thanks!
> Thanh
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.
The details on all of this still need to be flushed out, but this is
the basic idea.
To all:
* Do you think that this would allow you to easily build MACs or other
packet based things in GNU Radio? Assume the USRP and USRP2 blocks
are doing something sensible about the new attributes.
* Do you think you could build what you desire on top of these extensions?
* Any other comments, questions, yeah-but's...
Eric
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
