UHD transmission timing control is quite tricky yet

GNU Radio
1

I am trying to achieve two synchronized transmissions from two USRP2s.
Both USRPs are connected to each host PC and feed with 5PPS clocks,
without
10Mhz reference clock.
But I cannot make it happen yet.

  1. I have synchronized two USRP2s using clocks from GPS pps, and wait
    for 1
    sec
  • sdev->set_time_next_pps(uhd::time_spec_t(0.0));*
  • boost::this_thread::sleep(boost::posix_time::seconds(1));*

  1. Trigger the transmission of a stream of packets (10M samples = 500
    packets) for both usrps

    • with time delay 3 secs

    for (size_t i = 0; i < num_packets; i++){
    md.start_of_burst = true;
    md.end_of_burst = (i == num_packets-1);
    md.has_time_spec = (i == 0);

  •   md.time_spec = uhd::time_spec_t(uhd::time_spec_t(3.0));

  •   size_t samps_to_send = std::min(total_num_samps -

samps_per_packet*i, samps_per_packet);
size_t num_tx_samps = 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);

However, the two transmissions are not synchronized well. There is a
significant timing offset between the two transmissions, which
is hundreds of milliseconds.

I can hardly control the transmission timing, and the concept on the
timing
control is pretty obscure to me yet.

  • I used a shell scrip from another host to trigger the transmissions
    for 2
    usrps. Timing delay between the two executions is < 0.2-0.3 sec
2

The multi usrp wrapper has a method built in to synchronize a collection
of devices when the PPS edge event is unknown to the computer. You may
want to use the multi_usrp, and in any case, see the comments on
synchronization here:
http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a413014bf3aea4a8ea2d268b4a3b390e9

On 01/19/2011 09:29 PM, Sangho Oh wrote:

I am trying to achieve two synchronized transmissions from two USRP2s.
Both USRPs are connected to each host PC and feed with 5PPS clocks, without
10Mhz reference clock.
But I cannot make it happen yet.

no common reference means clock drift

However, the two transmissions are not synchronized well. There is a
significant timing offset between the two transmissions, which
is hundreds of milliseconds.

perhaps a multiple of 200 ms, which is the period of your pulses.

-josh