[Top][All Lists]

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

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

From: Dustin Torres
Subject: Re: [Discuss-gnuradio] extract timestamp data / "The Plan"
Date: Fri, 13 Mar 2009 11:41:22 -0700 (PDT)


Yes I believe this would tremendously facilitate MAC development within GNU Radio. I have recently begun working on integrating a configurable MAC layer to be used with GNU Radio and a USRP board.

I am using this for underwater acoustics where the propagation delay is very high and speed is not much of an issue. So my MAC layer is outside of GNU Radio. However with these enhancements that would no longer be necessary, and I imagine it would be much easier to do within GNU Radio.

Thanks for all the great work!
Dustin Torres

--- On Fri, 3/13/09, Eric Blossom <address@hidden> wrote:
From: Eric Blossom <address@hidden>
Subject: Re: [Discuss-gnuradio] extract timestamp data / "The Plan"
To: "Pham, Thanh" <address@hidden>
Cc: address@hidden
Date: Friday, March 13, 2009, 7:53 AM

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
> 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

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
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
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
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...


Discuss-gnuradio mailing list

reply via email to

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