[USRP-users] mimo sync and acceracy

Marcus Müller marcus.mueller at ettus.com
Fri Sep 5 05:13:22 EDT 2014


Hi Iftah,
answering your question really shortly, sorry:

>1.       What is the accuracy of this:
>tod = uhd::time_spec_t::get_system_time();
>usrp->set_time_now(tod);

The two USRPs should then be sample-synchronous. However, setting the
time without any trigger is not going to be very exact, give or take
10ms, because the USRP just sets its time when it receives the command.
If you want more accuracy, you need a pulse that will go up at the exact
time you want to set at the PPS input and use set_time_unknown_pps or
one of its sister methods. To be honest, though, when using the system
time, 10ms isn't that much, so "accuracy" is always relative.

>2.       What is the process or how those the time and clock are now
>transfer to the other usrp and what is the latency of that process?

The slave USRP gets a timestamp from the master via the mimo cable, and
transfers that timestamp into its own time register upon a
master-generated pulse. This answers 4., too.
Latency thus should effectively be eliminated.

>3.       Is there a time stamp that is passing from the master usrp to the
>slave usrp every clock or those this happen once and then we rely on the
>fact that the clock is the same?

Once. Doing something else would be unwise, unless we don't trust our
FPGA to count up.

>5.       About the sample clock, is it based on the same 10MHZ that is
>passing on the mimo cable? 

Exactly. That is the main purpose of the MIMO cable.

>How does this 10M get synthesized to the sample
>frequency at the A2D?

The other way around. This applies to any reference clock, no matter if
it comes from the MIMO cable, internal oscillator, GPSDO, or wherever:
The USRP has an on-board ADC clock generator, which takes the 10MHz
reference as reference and generates the ADC clock, which is then phase
locked.

> and what would be the latency between the 2 different
>A2D sample Signal?

Ideally, none. You have to account for analog circuitry though, which
implies that e.g. the phase of most (not all) the LOs used to mix down
the RF signal to complex baseband is random upon tuning. A phase shift
is a time delay, too...

Greetings,
Marcus


On 05.09.2014 09:06, iftah giladi via USRP-users wrote:
> Hi everyone,
>
>  
>
> I have 2 USRP N200, I wrote my own code using the help of the examples.
>
> I am connecting the 2 USRP's together using the MIMO cable.
>
> And The sync is done via this procedure:
>
> 1.       The slave program set's the time & clk to the mimo:
>
> usrp -> set_time_source("mimo",0);
>
> usrp -> set_clock_source("mimo",0);
>
> and then it is sets all the other channel parameter(freq,gain,etc) 
>
> 2.       The master program set's clock source to internal :
>
> usrp -> set_clock_source(ref);
>
> And then sets all the other channel parameter(freq,gain,etc)  
>
> 3.       Then the master program gets time from local machine and set the
> usrp time to it:
>
> tod = uhd::time_spec_t::get_system_time();
>
> usrp->set_time_now(tod);
>
> 4.       As I understand at that point both usrp has the same time and clk.
> Then the master program sets a rx_stream
>
> uhd::stream_args_t stream_args("sc16", wirefmt);
>
> uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
>
>  
>
> using this sequence of stream_cmd:
>
> uhd::stream_cmd_t stream_cmd((total_num_samps == 0)?
>
>         uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:
>
>         uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
>
>     );
>
>     stream_cmd.num_samps = total_num_samps;
>
>     stream_cmd.stream_now = false;
>
>        stream_cmd.time_spec = uhd::time_spec_t(tod + seconds_in_future );
>
>     rx_stream->issue_stream_cmd(stream_cmd);
>
>  
>
> 5.       Mean time the slave program wait to receive a time file from the
> master program with the stream_cmd.time_spec which is sent via TCP sockt to
> the slave program
>
> 6.       In the slave program the file is received and then a stream commend
> sequence using it is done:
>
> uhd::stream_args_t stream_args(cpu_format,wire_format);
>
> uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
>
>  
>
> uhd::stream_cmd_t stream_cmd((num_requested_samples == 0)?
>
>         uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:
>
>         uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
>
>     );
>
>     stream_cmd.num_samps = num_requested_samples;
>
>     stream_cmd.stream_now = false;
>
>  
>
>     stream_cmd.time_spec = uhd::time_spec_t(full_sec + frac_sec); // in the
> slave device this should be recived from the master host via lan
>
>     rx_stream->issue_stream_cmd(stream_cmd);
>
> 7.  Then they both wait for the time = tod + seconds_in_future, and then
> they both sample and create a file.
>
> 8.  Later on I get this file to the same computer to process with MATLAB.
>
>  
>
> I would really like to get answers to a few question:
>
>  
>
> 1.       What is the accuracy of this:
>
> tod = uhd::time_spec_t::get_system_time();
>
> usrp->set_time_now(tod);
>
> 2.       What is the process or how those the time and clock are now
> transfer to the other usrp and what is the latency of that process?
>
> 3.       Is there a time stamp that is passing from the master usrp to the
> slave usrp every clock or those this happen once and then we rely on the
> fact that the clock is the same?
>
> 4.       And if there is a time massage that is passing from one usrp to the
> other then what is the latency of that massage?
>
> 5.       About the sample clock, is it based on the same 10MHZ that is
> passing on the mimo cable? How does this 10M get synthesized to the sample
> frequency at the A2D? and what would be the latency between the 2 different
> A2D sample Signal?
>
> Any help would be very appreciated,
>
>  
>
> Thank's,
>
> iftah
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140905/d7bac39e/attachment-0002.html>


More information about the USRP-users mailing list