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
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
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 K.
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 S.
“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 G.
-----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 G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
-----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-----
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
On Thu, Mar 12, 2009 at 09:51:18AM -0500, Douglas G. 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
On Fri, Mar 13, 2009 at 7:53 AM, Eric B. [email protected] 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
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
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 T.
— On Fri, 3/13/09, Eric B. [email protected] wrote:
From: Eric B. [email protected]
Subject: Re: [Discuss-gnuradio] extract timestamp data / “The Plan”
To: “Pham, Thanh” [email protected]
Cc: [email protected]
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
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
-----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 G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
-----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-----
On Fri, Mar 13, 2009 at 11:25:17AM -0500, Douglas G. 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
On Fri, Mar 13, 2009 at 07:53:26AM -0700, Eric B. 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
On Fri, Mar 13, 2009 at 11:41:22AM -0700, Dustin T. 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
On Sat, Mar 14, 2009 at 01:37:21PM +0100, Martin B. 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 forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs