On 09/04/2013 04:50 AM, Chi wrote:

Well, synchronization involves a few steps. Since you are using internal
GPSDOs, here is sort of a checklist of things to do:

1. The USRP will automatically set its time and clock source to GPSDO
   and set the time registers to be UTC time from the GPSDO. I think
   explicitly setting usrp->set_time/clock_source("gpsdo", unit) is still a
   good idea.

1.1) Add a sleep(1) after multi_usrp::make(args). This will allow extra
time for the time registers to trigger and sync from the PPS.

2. Is the reference clock locked? bool locked =
   usrp->get_mboard_sensor("ref_locked",unit).to_bool();

3. Is the GPSDO locked? bool locked =
   usrp->get_mboard_sensor("gps_locked",unit).to_bool();

4. Print the device time when you run the app. Its good to confirm that
   the time from the time registers is UTC from the GPSDO.
   usrp->get_time_now(unit).to_ticks(1.0).

5. You must ask each device to begin streaming at the same exact
   timestamp to ensure that the samples are time-aligned. Use the
   stream_command's time_spec and stream_now=false.

6. Phase offsets. Is it possible that you are just measuring phase
   offsets between channels. These can be random after each retune
   operation, with the exception of the SBX which can be sync'd with timed
   commands, see:
   http://files.ettus.com/uhd_docs/manual/html/sync.html#synchronizing-channel-phase

Just SBX, so you might just be measuring phase offset. However, make
sure to go through the checklist above. Its good to check some of the
sensors. However, your code above looks like the right idea.

-josh

Chi,

Are you measuring time difference by measuring the phase difference between
the two signals?  That is different than time alignment.  You can check for
time alignment by comparing the outputs of the two GPSDOs on an
oscilloscope.  They should be closer than 100ns RMS.

The DBSRX2 will have an arbitrary phase difference between 2 boards because
they have fractional-N synthesizers without phase alignment circuitry.  The
SBX includes phase alignment capability which works with the code you have
there for alignment.

Matt

On Wed, Sep 4, 2013 at 4:50 AM, Chi chengchibt@gmail.com wrote:

Hi josh,

{{{
stream_cmd.stream_now = false;
stream_cmd.time_spec = uhd::time_spec_t(time_to_receive);
usrp->issue_stream_cmd(stream_cmd);
}}}

In this code, the time_to_receive is a double value. So I am using this
function time_spec_t (double secs=0) to create the time_spec_t. Would it
provide better accuracy if I use time_spec_t (time_t full_secs, double
frac_secs=0) to specify frac_secs also?

So far, I haven't figured out how to use the time_t data type. Every time I
compile, there is error "expected initializer before time_t". I try to find
examples about how to use this time_t in uhd example directory, but can't
find any. Do you have any example which uses the time_t data type?

Best regards,
Cheng Chi

On Thu, Sep 5, 2013 at 6:40 AM, Josh Blum josh@ettus.com wrote:

Hi Matt,

The time difference is the TDOA we estimated by cross-correlating the two
signals. For our setup, we expected that the TDOA would be less than 100ns,
but constantly got a TDOA between +0.2 and -0.2 us.

So the code to align LOs in the frontend would have no effect for DBSRX2.
Do you have any suggestions on how to deal with this phase difference? We
use single tone signal to measure the phase difference between the two
signals, it seems that the phase difference is not constant.

Best regards,
Cheng Chi

On Thu, Sep 5, 2013 at 12:47 PM, Matt Ettus matt@ettus.com wrote:

On 09/05/2013 03:10 AM, Cheng Chi wrote:

The phase difference will be different every time the devices are tuned
or reset.  That's due to the nature of Frac-N synthesizers, even when they
have a common reference clock (or, in your case, a common-ish
reference clock since you're using two different GPSDO units).

The SBX card provides a phase-reset feature that can be used in
conjunction with timed commands to arrange for the synthesizer
phase-offset to be
common between two or more units.  But the DBSRX2 doesn't have this
feature.

The drift characteristics of your two GPSDO will be slightly different,
and they'll have different "fine structure" in their phase noise. The
only way to do
what you're trying to do in that situation is to take frequent
measurements and adjust accordingly.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

On 09/04/2013 11:53 PM, Cheng Chi wrote:

I guess you could say accuracy is a relative thing. Its really important
that the time to stream is exactly the same for all channels. But as far
as what that time is? I dont think it matters.

Basically, you just need to find a time that is "slightly in the
future". That means the time wont be late when the command is sent to
the USRP; and a time that isnt so far in the future you have to wait
forever. :-)

//this will make a time that is 100ms in the future
//but +/- some delta for communicating with the usrp
uhd::time_spec_t time_to_stream =
usrp->get_time_now() + uhd::time_spec_t(0.1);
stream_cmd.time_spec = time_to_stream;

Use this time exactly for all USRPs in your experiment,
as in, dont call usrp->get_time_now() on each device, because then you
would come up with different random times for each USRP.

time_t should just be a typedef for an integer, so you can use it the
same as int for example. Comes from #include <ctime>. uhd::time_spec_t
happens to use it for representing seconds because other posix calls
also use it to represent seconds.

-josh

Cheng,

How far apart are the two USRPs?  If they are close by, then you would be
better off sharing a reference rather than giving them separate GPSDOs.
Can you have them share a reference?

Matt

On Thu, Sep 5, 2013 at 12:10 AM, Cheng Chi ch0004hi@e.ntu.edu.sg wrote:

Hi Matt,

Thanks for your advice. We've taken several measurements accordingly, here
is the result:

1. Shared GPSDO:

equals 0, but the FDOA is about 5.9Hz. We are trying to figure out why
there's this small FDOA. We expected that the FDOA would also be 0.

2. Separate GPSDOs:
   We displayed two 10MHz signals from the two GPSDOs in an oscilloscope, and
   found that the two reference
   signals drift with respect to each other.

Then we tried increasing the sampling rate to 25Msps, the TDOA results
decreased. The TDOAs are [-88, -80, -64, -56, -48, -40, -32] in
nanoseconds. It varied in a roughly periodic pattern. Is it caused by the
drifting of the two reference signals we observed on the oscilloscope?

Best regards,
Cheng Chi

On Fri, Sep 6, 2013 at 2:49 PM, Matt Ettus matt@ettus.com wrote:

Cheng,

This is what I expected.  Separate GPSDOs will drift relative to each
other, by on the order of 100ns.  When used in close proximity, that 100ns
is significant, and so it is better to use a shared reference.  When used
very far apart (hundreds of meters or more), it is harder to use a shared
reference, but the 100ns error from drifting GPSDOs is less significant,
and so separate GPSDOs become useful.

So in short -- if you can use a shared reference, do that.  Only use
separate GPSDOs if it is impractical to use a shared reference because the
systems are too far apart.

Also keep in mind that GPSDOs take hours to settle down to a consistent
rate, so if you are using them, try to leave them on and with their GPS
antennas connected all the time.

Matt

On Sun, Sep 8, 2013 at 5:51 AM, Cheng Chi ch0004hi@e.ntu.edu.sg wrote: