discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] clarification on using tx timed sample tx_metadata_t


From: Bastien Auneau
Subject: [Discuss-gnuradio] clarification on using tx timed sample tx_metadata_t
Date: Fri, 20 May 2011 17:00:12 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10

Hi

I am confused regarding the use of the metadata for the send function
virtual size_t uhd::device::send(...)
http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#a1d302f283c89b0823c9745dc395ae679

It is described as a time stamp at which the burst should be sent
According to these posts :
___________________________________
http://lists.gnu.org/archive/html/discuss-gnuradio/2011-01/msg00056.html

"
md.time_spec is an absolute time

there is a working example in uhd/host/examples/tx_timed_samples.cpp
"

Looking at the example (uhd/host/examples/tx_timed_samples.cpp line 84)
, it says :
"
md.time_spec = uhd::time_spec_t(seconds_in_future);

    //the first call to send() will block this many seconds before sending:
    double timeout = seconds_in_future + 0.1; //timeout (delay before
transmit + padding)
"
It clearly mention *seconds_in_future*, then in the comment *delay
before transmit*


___________________________________

http://lists.gnu.org/archive/html/discuss-gnuradio/2011-01/msg00033.html

It says that :
"http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#a11cea7a2131f2764e9afa4eab34bd8d5

The metadata specifies the timestamp of the packet:

http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tx__metadata__t.html
"
___________________________________


So what is this example setting as metadata seconds_in_future ? It looks
like a delay.
_ is there some flag to set timestamp as delay or absolute time ?
(haven't found that in doc)
_ if it is an absolute time, the timestamp represents a time at which
burst tagged with timestamp should be sent. Then how is the USRP
internal clock working ? Is it a counter wrapping ? starting from 0 at
startup ? Is it lock to UTC if use set_time_next_pps ?

I need to rely on USRP clock to send my burst on time, as my PC is not
precise enough (not real-time). Is this possible to use timestamp
mechanism, with a GPSDO (for stability) to send my burst accurately time
wise ?

Bastien



reply via email to

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