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