[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Discuss-gnuradio] clarification on using tx timed sample tx_metadata_t,
Bastien Auneau <=