Trying to figure out time of packet arrival in USRP

Hello,

I am running usrp_transmit_path.py for transmission on one USRP
and usrp_receive_path.py for reception of signals on another USRP.
I want to determine the exact arrival time of a packet on the USRP.

I get the message stream which is received from packetutils.
The code in PacketUtils.py gets a packet from the USRP.
This is populated from copy_from_usrp_buffer in usrp_source_base.cc.
I am assuming there is some polling mechanism to invoke
usrp_basic_rx::read
for this.
I want to track the point where this buffer is populated. The time stamp
of
the packet when it is detected by USRP without any modifications by
higher
layers.
Can this be done without any changes in Firmware? Any pointers on how to
proceed will be appreciated.

Thanks.

Thanks for your input Tom. I’ll look at UHD and stream tags.

Regards,
Sapna

On Mon, Mar 7, 2011 at 2:26 PM, Sapna Dasarath
[email protected]wrote:

for this.
I want to track the point where this buffer is populated. The time stamp of
the packet when it is detected by USRP without any modifications by higher
layers.
Can this be done without any changes in Firmware? Any pointers on how to
proceed will be appreciated.

Thanks.

It sounds like you don’t want to go this route, but the best thing to do
is
start using the UHD and stream tags. There is an interface in the UHD
source
block to send stream tags of the sample times. The UHD tags frames with
a
time stamp based on the internal clock of the FPGA (which you can tell
to
reset). The tags are then passed downstream for you to collect later and
associate a time value with a particular sample.

The legacy USRP2 interface also allows you to collect the time out of
the
metadata, but you will have to dig into the libusrp2 library code to get
access to it.

If you want accurate time stamps for a USRP1, there really isn’t one.
You
would have to have a differential timer. Look at clock_gettime for
getting
clock information that you might use.

Tom

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs