Hello list,
my question is about the time stamp in rx_metadata->timestamp. I’ve got
the
rx_streaming_samples running and now I wondering what the time value is
about.
In the code I’ve found this:
uint32_t timestamp; // time of rx or tx (100 MHz)
Can you tell me what the timestamp exactly refers to. Is it just a
counter?
When/How is it started/reseted?
Or to be more precisely: How do I calculate an absolute time like the
extended
unix time stamp with uSec and nSec?
Thanks for reading 
kind regards
Michael
On Mon, May 11, 2009 at 08:12:08PM +0200, Michael Sprauer wrote:
Hello list,
my question is about the time stamp in rx_metadata->timestamp. I’ve got the
rx_streaming_samples running and now I wondering what the time value is about.
In the code I’ve found this:
uint32_t timestamp; // time of rx or tx (100 MHz)
Can you tell me what the timestamp exactly refers to. Is it just a counter?
It’s a counter clocked by the 100 MHz s.ample clock.
When/How is it started/reseted?
If you don’t do anything, it’s initialized to 0 at power up.
You can arrange so that it’s reset to zero on the next pulse on the
pulse-per-second input using usrp2::sync_to_pps.
Or to be more precisely: How do I calculate an absolute time like the extended
unix time stamp with uSec and nSec?
At this point you don’t. We’ll be moving to a 64-bit format when we
convert the USRP2 to use the VRT on-the-wire format
Thanks for reading 
You’re welcome
Eric
my question is about the time stamp in rx_metadata->timestamp. I’ve got the
rx_streaming_samples running and now I wondering what the time value is about.
In the code I’ve found this:
uint32_t timestamp; // time of rx or tx (100 MHz)
Can you tell me what the timestamp exactly refers to. Is it just a counter?
It is a 32-bit counter (I remember somebody saying that this will soon
be a 64-bit counter) that just counts 100 MHz samples, so it will
overflow quite often. In normal operation this isn’t tied to any
absolute clock.
When/How is it started/reseted?
If you call sync_to_pps() and provide a PPS input (one second digital
pulse), the system will start streaming samples at the next PPS pulse.
This resets the timestamp to zero, which makes it possible to attach
an absolute time to your samples. I’m not sure exactly how accurate
this is, as I haven’t properly tested this yet. If your sample clock
is locked to a good GPS syncronized reference clock, I’d guess the
accuracy could be better than 1e-8 s. I guess some of the “big guys”
might know more about this.
Or to be more precisely: How do I calculate an absolute time like the extended
unix time stamp with uSec and nSec?
The remaing us and ns are 0 if you are locked to a reference. You can
calculate the absolute time by counting the number of samples
received, assuming no buffer overflows have occured (which you can
detect from timestamp difference anomalies or missing frame sequence
numbers).
When streaming the data, you will have to throw away a small amount of
samples in the beginning, but you can quite easily determine where the
real first sample is located by looking at the time stamps of the
incoming frames.
If you are interested, I have a modified rx_streaming_samples.cc that
configures the sync_to_pps and determines where the true beginning of
samples is located at.
juha
