Hello,
What I am trying to implement is a synchronized packet transmission from
more than one USPRs.
I wonder if there is a way to control the transmission timing under a
microsecond level.
If there is a way to control the transmission timing using external
clock
signal, then it will be really easy. Like making USRPs transmit packets
triggered by the external clocks. This may request to change of code in
the
firmware.
I have tired to use UHD code to give backoff delays for each
USRP transmission, but this method is quite not precise and cannot find
a
way to use it for a synchronized transmission.
Any comments will be valuable to me.
Thanks.
On 01/02/2011 10:53 AM, Sangho Oh wrote:
firmware.
I have tired to use UHD code to give backoff delays for each
USRP transmission, but this method is quite not precise and cannot find a
way to use it for a synchronized transmission.
Any comments will be valuable to me.
Thanks.
With UHD (any USRP more recent than the USRP1 classic), you should be
able to precisely schedule transmit packets to the precision of a clock
cycle. Basically: send a packet with a timestamp that is less than the
time on the device (so that its not late).
You can use a GPSDO to set an absolute time into the USRP device, or you
can use the time found on received packets to schedule transmit packets.
So it all depends on how deal with the time.
I recommend looking at the timed tx example that comes with UHD. I think
to do this, you will need to code directly to the UHD api. To do this in
gnuradio will require tag-aware blocks that use the new gnuradio tagging
API. And we haven’t crossed that bridge yet. 
-josh
On 01/02/2011 12:59 PM, Sangho Oh wrote:
Hello Josh,
I have used this command
dev->send(&buff.front(), samps_to_send,
md, uhd::io_type_t::COMPLEX_FLOAT32,
uhd::device::SEND_MODE_FULL_BUFF, seconds_in_future + 0.1);
The reference time for seconds_in_future is not clear to me. When does the
timer starts?
that last parameter is a timeout. In the example, the samples are sent
several seconds in the future, so the timeout should wait at least that
long. See the docs for that call:
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
I guess there are large imprecise delay between gnuradio to USRP2 FPGA
(gnuradio → ethernet → FPGA).
on the order of 10s of microseconds if the CPU is keeping up.
If I synchronize two USRPs using sync_to_pps(), just wondering how to
control the transmit timing from the reference timing stamp, which is reset
every second?
The time will be set at the next pps to the desired value, and increment
forever after (its a 64 bit timer). So nothing is reset or rolls over
every second.
http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1single__usrp.html#a7fdb91ce9c7dd16a2c4cf210ebc8105f
-josh
Hello Josh,
I have used this command
dev->send(&buff.front(), samps_to_send,
md, uhd::io_type_t::COMPLEX_FLOAT32,
uhd::device::SEND_MODE_FULL_BUFF, seconds_in_future + 0.1);
The reference time for seconds_in_future is not clear to me. When does
the
timer starts?
I guess there are large imprecise delay between gnuradio to USRP2 FPGA
(gnuradio -> ethernet -> FPGA).
If I synchronize two USRPs using sync_to_pps(), just wondering how to
control the transmit timing from the reference timing stamp, which is
reset
every second?
If I synchronize two USRPs using pps clock
uhd::time_spec_t time_spec = uhd::time_spec_t(0.0);
sdev->set_time_next_pps(time_spec);
boost::this_thread::sleep(boost::posix_time::seconds(1));
and give the metadata for the frame as following
md.time_spec = uhd::time_spec_t(seconds_in_future);
When is the packet is being transmitted?
I believe md.time_spec specify the delay of transmission, which is not
an
absolute time of the transmission.
Hi All,
I started working with GNURadio a few months ago as a platform for use
with a Visual Light Communication front end. I’ve had some good
success with the basic benchmark testing and implementation of a few
basic tests with GRC, but I’m curious as to what datarates have been
achieved within the GNURadio community.
As of now, I’ve been able to reach rates of 4Mb/s with GMSK and BPSK
modulation and I’m pretty sure I’ve reached the limits of what my PC’s
can handle in real time (I seem to be getting errors occurring mostly
from system overruns). I haven’t gone into testing with the OFDM
blocks or higher order modulation schemes, but I wanted to see what
type of rates I should expect.
I’m using the system mostly as a testbed for the time being, so my
thought is to do the signal processing offline (to / from a file) and
have the transmission simply sending and receiving from a file. If
anyone has suggestions or examples of how to do this it would be
greatly appreciated.
Thanks in advance for any thoughts,
Michael R.
Graduate Research Assistant
Smart Lighting Engineering Research Center
Boston University
[email protected]
On 01/03/2011 12:15 PM, Sangho Oh wrote:
If I synchronize two USRPs using pps clock
uhd::time_spec_t time_spec = uhd::time_spec_t(0.0);
sdev->set_time_next_pps(time_spec);
boost::this_thread::sleep(boost::posix_time::seconds(1));
You may want to print out sdev->get_time_now().get_real_secs() to see
that it really got the PPS edge.
and give the metadata for the frame as following
md.time_spec = uhd::time_spec_t(seconds_in_future);
When is the packet is being transmitted?
I believe md.time_spec specify the delay of transmission, which is not an
absolute time of the transmission.
md.time_spec is an absolute time
there is a working example in uhd/host/examples/tx_timed_samples.cpp
-Josh
On Tue, Jan 4, 2011 at 6:48 PM, [email protected] wrote:
modulation and I’m pretty sure I’ve reached the limits of what my PC’s can
handle in real time (I seem to be getting errors occurring mostly from
system overruns). I haven’t gone into testing with the OFDM blocks or
higher order modulation schemes, but I wanted to see what type of rates I
should expect.
That sounds about right. The data rates are limited by the bandwidth
you can pull in from the front end (USRP in this case) and the speed
of your computer. So your computer’s hardware plays a big role if
you’re looking for comparisons.
As a note, as we start to integrate VOLK functions into GNU Radio
blocks, we should see an increase in performance and therefore an
increase in the possible datarates.
Tom