Clarification on using tx timed sample tx_metadata_t

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

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