Forum: GNU Radio extract timestamp data

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
5807290886e8a06db8e9150980c85108?d=identicon&s=25 Pham, Thanh (Guest)
on 2009-03-10 20:53
(Received via mailing list)
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
F661cbda841d033b95cabec25f19e86b?d=identicon&s=25 Cocuzzo, Daniel C. (Guest)
on 2009-03-11 19:43
(Received via mailing list)
I'm also wondering about how to extract ethernet packet information,
such as timestamp. If anyone has any pointers to reference materials it
would be greatly appreciated.

Thanks,
Dan
287db267f16cb26430934ea36168e6b3?d=identicon&s=25 Mattias Kjellsson (Guest)
on 2009-03-12 09:44
(Received via mailing list)
Cocuzzo, Daniel C. wrote:
>
> I'm also wondering about how to extract ethernet packet information,
> such as timestamp. If anyone has any pointers to reference materials
> it would be greatly appreciated.
>
Hi,

As far as I know, there is a timestamp- field in the ethernet- packet
header. Look in "gnuradio/usrp2/firmware/include/usrp2_eth_packet.h" for
definitions of the ethernet- structures.
Have a close look at how the headers are combined, and also remember
that there is a "union u2_subpkt_t", which eased up the programming for
me a bit.

There is a timestamp- field in "u2_fixed_hdr_t", but I don't know
exactly how that comes out in the higher levels of the api. I have been
toled that the lower levels of the code should already be able to handle
this, but that it hasn't got it's way up all the way through the api
yet. But that was a month or two ago, maybe someone of the core-
developers can answer that more precisely.

Best Regards
//Mattias Kjellsson
D9b2772a9387f5dbe010dbc0c3a93f8d?d=identicon&s=25 Douglas Geiger (Guest)
on 2009-03-12 15:52
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cocuzzo, Daniel C. wrote:
> I'm also wondering about how to extract ethernet packet information,
> such as timestamp. If anyone has any pointers to reference materials it
> would be greatly appreciated.
>
> Thanks,
> Dan
>
>

 The easiest way (depending on what you are doing with the timestamps)
is probably by dealing with the low-level libusrp2, and writing a custom
copy handler (look at rx_streaming_samples.cc in usrp2/host/apps). The
metadata structure (in usrp2/metadata.h) provides the timestamp from the
fpga.
 I'm playing around right now with creating a custom source block that
has access to the timestamps (i.e. the copy handler passes it from the
low-level library into the source block - but not to the rest of the
flowgraph). I'm only interested in it as far as providing aligned
samples from two USRP2 (like usrp_multi does for the USRP1). Depending
on what you need the timestamps for, that may be the way to go.
 Doug

- --
Doug Geiger
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
douglas.geiger@okstate.edu
doug.geiger@ieee.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJuSFmgfOzzR5bXIgRAl9uAKCbn2HziekL8O+kUIyg9uG4qwjB/QCfXxQL
sGldNGn6AVsCnzkM8gVFPqM=
=GDET
-----END PGP SIGNATURE-----
C0ba64b9e5a62ed77295b79b63ab87c0?d=identicon&s=25 Dimitris Symeonidis (Guest)
on 2009-03-12 16:09
(Received via mailing list)
I was contemplating trying to use the timestamps and 4 antennas on the
same usrp{1,2} to try and create a smart antenna array for DOA...

Dimitris Symeonidis
"If you think you're too small to make a difference, try sleeping with
a mosquito!" - Amnesty International



On Thu, Mar 12, 2009 at 15:51, Douglas Geiger
F661cbda841d033b95cabec25f19e86b?d=identicon&s=25 Cocuzzo, Daniel C. (Guest)
on 2009-03-12 23:00
(Received via mailing list)
Thanks for the guidance here. I'd actually like to save timestamps to a
file, along with data - it sounds like this would require not only a
custom copy handler but also a custom source block to pass the timestamp
up to the flow graph. Am I on the right track here?

I'm not sure I totally understand the interactions of the low-level
code, is there any further documentation for that?

Thanks,
Dan
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-03-13 15:02
(Received via mailing list)
On Thu, Mar 12, 2009 at 09:51:18AM -0500, Douglas Geiger wrote:
>  The easiest way (depending on what you are doing with the timestamps)
> is probably by dealing with the low-level libusrp2, and writing a custom
> copy handler (look at rx_streaming_samples.cc in usrp2/host/apps). The
> metadata structure (in usrp2/metadata.h) provides the timestamp from the
> fpga.

Yes, this the best way to currently get at the timestamp.

>  I'm playing around right now with creating a custom source block that
> has access to the timestamps (i.e. the copy handler passes it from the
> low-level library into the source block - but not to the rest of the
> flowgraph). I'm only interested in it as far as providing aligned
> samples from two USRP2 (like usrp_multi does for the USRP1). Depending
> on what you need the timestamps for, that may be the way to go.
>  Doug

I'll explain in another message what our intermediate range plans are
for dealing with this.

Eric
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-03-13 16:20
(Received via mailing list)
On Tue, Mar 10, 2009 at 01:51:15PM -0600, Pham, Thanh wrote:
> 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
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-03-13 17:20
(Received via mailing list)
On Fri, Mar 13, 2009 at 7:53 AM, Eric Blossom <eb@comsec.com> 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
D9b2772a9387f5dbe010dbc0c3a93f8d?d=identicon&s=25 Douglas Geiger (Guest)
on 2009-03-13 17:40
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>
>   * Any other comments, questions, yeah-but's...
>
> Eric
>

 I'm not working on MAC's at the moment (or more accurately, my work
right is only concerned with receiving packets, not sending), but
certainly being able to pass along the metadata would be a nice feature.
 For the moment, I'm able to do what I want with my afore-mentioned
custom source block (where only the source block has access to the
timestamps), but I can see situations (in the future) in which I'd like
to have that info passed along through the flowgraph.
 I recall some discussion with the m-block's being concerned with the
performance of the PMT data types - can you address that? Has that been
resolved/can resolved via some technique/won't be an issue with next
year's CPU's/etc.?
 Thanks,
 Doug

- --
Doug Geiger
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
douglas.geiger@okstate.edu
doug.geiger@ieee.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJuojtgfOzzR5bXIgRAsyrAKCpFukM05kNMqwY2w178RVpeV45vgCfdRS7
H7cTgsWGJQbTN55LeQkiR6Y=
=B+CK
-----END PGP SIGNATURE-----
C8210904e6e24e60514dffd770634e4a?d=identicon&s=25 Dustin Torres (Guest)
on 2009-03-13 19:43
(Received via mailing list)
Eric,

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 <eb@comsec.com> wrote:
From: Eric Blossom <eb@comsec.com>
Subject: Re: [Discuss-gnuradio] extract timestamp data / "The Plan"
To: "Pham, Thanh" <thanh.pham@lmco.com>
Cc: Discuss-gnuradio@gnu.org
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
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
4252201ac30d6dd44d8090ce1070e35f?d=identicon&s=25 Josh Blum (Guest)
on 2009-03-13 20:32
(Received via mailing list)
Exciting! With a new message passing capability, we will have to rethink
the packet and ofdm mod stuff in blks2. It wouldnt be to hard to modify
GRC to have blocks with "message passing" inputs and outputs.

!!
-Josh
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-03-14 02:34
(Received via mailing list)
On Fri, Mar 13, 2009 at 11:25:17AM -0500, Douglas Geiger wrote:
> >
> timestamps), but I can see situations (in the future) in which I'd like
> to have that info passed along through the flowgraph.

Thanks for the data point.

>  I recall some discussion with the m-block's being concerned with the
> performance of the PMT data types - can you address that? Has that been
> resolved/can resolved via some technique/won't be an issue with next
> year's CPU's/etc.?

We've got some performance patches to apply and beyond that will do
what it takes to ensure good performance for the PMT types.

Eric
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-03-14 02:38
(Received via mailing list)
On Fri, Mar 13, 2009 at 11:41:22AM -0700, Dustin Torres wrote:
> Eric,

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

Thanks.

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

You're welcome!

Eric
B22e1b01ee2edc1bdd77eeb90fd4d5b4?d=identicon&s=25 Martin Braun (Guest)
on 2009-03-14 13:39
(Received via mailing list)
On Fri, Mar 13, 2009 at 07:53:26AM -0700, Eric Blossom wrote:
> 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

Will this make m-blocks obsolete? I frankly haven't delved into the
mblock code, but these new features are pretty much most of what was
ever
missing for me in GNU Radio, so I wonder if mblocks are still necessary?

Altogether, this sounds pretty amazing and I'm looking forward to see
some code!

Cheers
MB
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-03-14 14:44
(Received via mailing list)
On Sat, Mar 14, 2009 at 01:37:21PM +0100, Martin Braun wrote:
>
> Altogether, this sounds pretty amazing and I'm looking forward to see
> some code!
>
> Cheers
> MB

We'll be deprecating m-blocks, but will continue to distribute them.

Eric
This topic is locked and can not be replied to.