Hi, 
Guest
Pic
Sign In

usrp-users@lists.ettus.com

Discussion and technical support related to USRP, UHD, RFNoC

View all threads

Phase difference with synchronized boards

ZM
Zohair M. Abu Shaban
Fri, May 10, 2013 8:24 AM

Dear All,

My setup has three USRP N200 boards with DBSRX2 synchronized a GPS receiver REF/PPS, split and fed to the boards. The boards are connected directly to a PC using three 1Gb Ethernet ports belonging to three different subnets.

Using the UHD, I wrote a c++ code (MSVC/Windows) setting all the paramters to the USRPs and syncing them, reading time-aligned samples from the boards and storing them in three separate files. To test the sync, I splid a sinusiodal signal (-20dBm) and fed it to the RF boards input. Then, I execute the UHD command: usrp->get_time_synchronized () and it returns true. I expected to see three sinusoids at the top of each other but when I import the samples into MATLAB and plot them there is a phase shift that is different from a run to another. To investigate more, I used usrp->get_time_now(x)  (where x=0,1,2) and the time is quite the same:
Time at board0 is: 0.433092
Time at board1 is: 0.433467
Time at board2 is: 0.433874

which means the PPS and REF sync signals are really latched.

A colleague raised an argument that even though the boards' clock are synch the
daughter boards may introduce phase shift. Is this argument
valid here?

Do you have any insights?

Thanks,
Zohair

Dear All, My setup has three USRP N200 boards with DBSRX2 synchronized a GPS receiver REF/PPS, split and fed to the boards. The boards are connected directly to a PC using three 1Gb Ethernet ports belonging to three different subnets. Using the UHD, I wrote a c++ code (MSVC/Windows) setting all the paramters to the USRPs and syncing them, reading time-aligned samples from the boards and storing them in three separate files. To test the sync, I splid a sinusiodal signal (-20dBm) and fed it to the RF boards input. Then, I execute the UHD command: usrp->get_time_synchronized () and it returns true. I expected to see three sinusoids at the top of each other but when I import the samples into MATLAB and plot them there is a phase shift that is different from a run to another. To investigate more, I used usrp->get_time_now(x) (where x=0,1,2) and the time is quite the same: Time at board0 is: 0.433092 Time at board1 is: 0.433467 Time at board2 is: 0.433874 which means the PPS and REF sync signals are really latched. A colleague raised an argument that even though the boards' clock are synch the daughter boards may introduce phase shift. Is this argument valid here? Do you have any insights? Thanks, Zohair
MD
Marcus D. Leech
Fri, May 10, 2013 1:10 PM

Dear All,

My setup has three USRP N200 boards with DBSRX2 synchronized a GPS
receiver REF/PPS, split and fed to the boards. The boards are
connected directly to a PC using three 1Gb Ethernet ports belonging to
three different subnets.

Using the UHD, I wrote a c++ code (MSVC/Windows) setting all the
paramters to the USRPs and syncing them, reading time-aligned samples
from the boards and storing them in three separate files. To test the
sync, I splid a sinusiodal signal (-20dBm) and fed it to the RF boards
input. Then, I execute the UHD command: usrp->get_time_synchronized ()
and it returns true. I expected to see three sinusoids at the top of
each other but when I import the samples into MATLAB and plot them
there is a phase shift that is different from a run to another. To
investigate more, I used usrp->get_time_now(x)  (where x=0,1,2) and
the time is quite the same:
Time at board0 is: 0.433092
Time at board1 is: 0.433467
Time at board2 is: 0.433874

which means the PPS and REF sync signals are really latched.

A colleague raised an argument that even though the boards' clock are
synch the daughter boards may introduce phase shift. Is this argument
valid here?

Do you have any insights?

Thanks,
Zohair

USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

The phase will be coherent, but with an unknown phase offset between all
the "players".

This is due to the way PLL synthesizers work using fractional-N
synthesis.  There will always be some random phase offset between the
synthesizers
involved.  If they all have a common reference, they'll all "march
together", but will have an offset.  You'll need to calibrate that out
every time
you start a "run" or retune your boards.

The SBX board has a special feature that allows you to use "timed
commands" to get all the synthesizers to be phase-aligned when tuned
together
at the same time.  The DBSRX synthesizer doesn't have the necessary
hardware support for that.

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

> Dear All, > > My setup has three USRP N200 boards with DBSRX2 synchronized a GPS > receiver REF/PPS, split and fed to the boards. The boards are > connected directly to a PC using three 1Gb Ethernet ports belonging to > three different subnets. > > Using the UHD, I wrote a c++ code (MSVC/Windows) setting all the > paramters to the USRPs and syncing them, reading time-aligned samples > from the boards and storing them in three separate files. To test the > sync, I splid a sinusiodal signal (-20dBm) and fed it to the RF boards > input. Then, I execute the UHD command: usrp->get_time_synchronized () > and it returns true. I expected to see three sinusoids at the top of > each other but when I import the samples into MATLAB and plot them > there is a phase shift that is different from a run to another. To > investigate more, I used usrp->get_time_now(x) (where x=0,1,2) and > the time is quite the same: > Time at board0 is: 0.433092 > Time at board1 is: 0.433467 > Time at board2 is: 0.433874 > > which means the PPS and REF sync signals are really latched. > > > A colleague raised an argument that even though the boards' clock are > synch the daughter boards may introduce phase shift. Is this argument > valid here? > > > Do you have any insights? > > Thanks, > Zohair > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com The phase will be coherent, but with an unknown phase offset between all the "players". This is due to the way PLL synthesizers work using fractional-N synthesis. There will always be some random phase offset between the synthesizers involved. If they all have a common reference, they'll all "march together", but will have an offset. You'll need to calibrate that out every time you start a "run" or retune your boards. The SBX board has a special feature that allows you to use "timed commands" to get all the synthesizers to be phase-aligned when tuned together at the same time. The DBSRX synthesizer doesn't have the necessary hardware support for that. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
ZM
Zohair M. Abu Shaban
Fri, May 10, 2013 1:53 PM

OK... now I understand it.

Thanks a lot,
Zohair

Date: Fri, 10 May 2013 09:10:52 -0400
From: mleech@ripnet.com
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Phase difference with synchronized boards

  Dear All,

    

    My setup has three USRP N200 boards with DBSRX2 synchronized a
    GPS receiver REF/PPS, split and fed to the boards. The boards
    are connected directly to a PC using three 1Gb Ethernet ports
    belonging to three different subnets.

    

    Using the UHD, I wrote a c++ code (MSVC/Windows) setting all the
    paramters to the USRPs and syncing them, reading time-aligned
    samples from the boards and storing them in three separate
    files. To test the sync, I splid a sinusiodal signal (-20dBm)
    and fed it to the RF boards input. Then, I execute the UHD
    command: usrp->get_time_synchronized () and it returns true.
    I expected to see three sinusoids at the top of each other but
    when I import the samples into MATLAB and plot them there is a
    phase shift that is different from a run to another. To
    investigate more, I used usrp->get_time_now(x)  (where
    x=0,1,2) and the time is quite the same:

    Time at board0 is: 0.433092

    Time at board1 is: 0.433467

    Time at board2 is: 0.433874

    

    which means the PPS and REF sync signals are really latched.

    

    

    A colleague raised an argument that even though the boards'
    clock are synch the daughter boards may introduce phase shift.
    Is this argument valid here?

    

    

    Do you have any insights?

    

    Thanks,

    Zohair

USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

The phase will be coherent, but with an unknown phase offset between
all the "players".



This is due to the way PLL synthesizers work using fractional-N
synthesis.  There will always be some random phase offset between
the synthesizers

  involved.   If they all have a common reference, they'll all
"march together", but will have an offset.   You'll need to
calibrate that out every time

  you start a "run" or retune your boards.



The SBX board has a special feature that allows you to use "timed
commands" to get all the synthesizers to be phase-aligned when tuned
together

  at the same time.  The DBSRX synthesizer doesn't have the
necessary hardware support for that.







--

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

USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

OK... now I understand it. Thanks a lot, Zohair Date: Fri, 10 May 2013 09:10:52 -0400 From: mleech@ripnet.com To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Phase difference with synchronized boards Dear All, My setup has three USRP N200 boards with DBSRX2 synchronized a GPS receiver REF/PPS, split and fed to the boards. The boards are connected directly to a PC using three 1Gb Ethernet ports belonging to three different subnets. Using the UHD, I wrote a c++ code (MSVC/Windows) setting all the paramters to the USRPs and syncing them, reading time-aligned samples from the boards and storing them in three separate files. To test the sync, I splid a sinusiodal signal (-20dBm) and fed it to the RF boards input. Then, I execute the UHD command: usrp->get_time_synchronized () and it returns true. I expected to see three sinusoids at the top of each other but when I import the samples into MATLAB and plot them there is a phase shift that is different from a run to another. To investigate more, I used usrp->get_time_now(x) (where x=0,1,2) and the time is quite the same: Time at board0 is: 0.433092 Time at board1 is: 0.433467 Time at board2 is: 0.433874 which means the PPS and REF sync signals are really latched. A colleague raised an argument that even though the boards' clock are synch the daughter boards may introduce phase shift. Is this argument valid here? Do you have any insights? Thanks, Zohair _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com The phase will be coherent, but with an unknown phase offset between all the "players". This is due to the way PLL synthesizers work using fractional-N synthesis. There will always be some random phase offset between the synthesizers involved. If they all have a common reference, they'll all "march together", but will have an offset. You'll need to calibrate that out every time you start a "run" or retune your boards. The SBX board has a special feature that allows you to use "timed commands" to get all the synthesizers to be phase-aligned when tuned together at the same time. The DBSRX synthesizer doesn't have the necessary hardware support for that. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
ZM
Zohair M. Abu Shaban
Thu, Jun 27, 2013 12:08 PM

Dear Marcus and all,

Following up with the discussion below, we have purchased three SBX  boards. I used the following commands as per the application notes:

std::cout << boost::format("Setting RX Freq: %f MHz...") % (freq/1e6) << std::endl;
uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1);
usrp->set_command_time(cmd_time);
usrp->set_rx_freq(freq,0);
usrp->set_rx_freq(freq,1);
usrp->set_rx_freq(freq,2);
usrp->clear_command_time();
std::cout << boost::format("Actual RX Freq: %f MHz...") % (usrp->get_rx_freq(0)/1e6) << std::endl;
std::cout << boost::format("Actual RX Freq: %f MHz...") % (usrp->get_rx_freq(1)/1e6) << std::endl;
std::cout << boost::format("Actual RX Freq: %f MHz...") % (usrp->get_rx_freq(2)/1e6) << std::endl << std::endl;

These commands were used after synchronizing the boards using:
usrp->set_time_source("external");
usrp->set_time_next_pps(uhd::time_spec_t(0.0), uhd::usrp::multi_usrp::ALL_MBOARDS);
boost::this_thread::sleep(boost::posix_time::seconds(1)); //wait for pps sync pulse

Again, the three boards are time-synchronized  (usrp->get_time_synchronized () returns true) but the phase misalignment issue is still unresolved. If I understand it correctly, whatever comes between set_command_time() and clear_command_time() will be executed in the three boards at cmd_time.

Any advice or hint?

Best regards,
Zohair
From: zohair_ms@hotmail.com
To: mleech@ripnet.com
Date: Fri, 10 May 2013 13:53:31 +0000
CC: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Phase difference with synchronized boards

OK... now I understand it.

Thanks a lot,
Zohair

Date: Fri, 10 May 2013 09:10:52 -0400
From: mleech@ripnet.com
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Phase difference with synchronized boards

  Dear All,

    

    My setup has three USRP N200 boards with DBSRX2 synchronized a
    GPS receiver REF/PPS, split and fed to the boards. The boards
    are connected directly to a PC using three 1Gb Ethernet ports
    belonging to three different subnets.

    

    Using the UHD, I wrote a c++ code (MSVC/Windows) setting all the parameters to the USRPs and syncing them, reading time-aligned
    samples from the boards and storing them in three separate
    files. To test the sync, I splid a sinusoidal signal (-20dBm)
    and fed it to the RF boards input. Then, I execute the UHD
    command: usrp->get_time_synchronized () and it returns true.
    I expected to see three sinusoids at the top of each other but
    when I import the samples into MATLAB and plot them, there is a
    phase shift that is different from a run to another. To
    investigate more, I used usrp->get_time_now(x)  (where
    x=0,1,2) and the time is quite the same:

    Time at board0 is: 0.433092

    Time at board1 is: 0.433467

    Time at board2 is: 0.433874

    

    which means the PPS and REF sync signals are really latched.

    

    

    A colleague raised an argument that even though the boards'
    clock are synch the daughter boards may introduce phase shift.
    Is this argument valid here?

    

    

    Do you have any insights?

    

    Thanks,

    Zohair

USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

The phase will be coherent, but with an unknown phase offset between
all the "players".



This is due to the way PLL synthesizers work using fractional-N
synthesis.  There will always be some random phase offset between
the synthesizers

  involved.   If they all have a common reference, they'll all
"march together", but will have an offset.   You'll need to
calibrate that out every time

  you start a "run" or retune your boards.



The SBX board has a special feature that allows you to use "timed
commands" to get all the synthesizers to be phase-aligned when tuned
together

  at the same time.  The DBSRX synthesizer doesn't have the
necessary hardware support for that.







--

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

USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Dear Marcus and all, Following up with the discussion below, we have purchased three SBX boards. I used the following commands as per the application notes: std::cout << boost::format("Setting RX Freq: %f MHz...") % (freq/1e6) << std::endl; uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1); usrp->set_command_time(cmd_time); usrp->set_rx_freq(freq,0); usrp->set_rx_freq(freq,1); usrp->set_rx_freq(freq,2); usrp->clear_command_time(); std::cout << boost::format("Actual RX Freq: %f MHz...") % (usrp->get_rx_freq(0)/1e6) << std::endl; std::cout << boost::format("Actual RX Freq: %f MHz...") % (usrp->get_rx_freq(1)/1e6) << std::endl; std::cout << boost::format("Actual RX Freq: %f MHz...") % (usrp->get_rx_freq(2)/1e6) << std::endl << std::endl; These commands were used after synchronizing the boards using: usrp->set_time_source("external"); usrp->set_time_next_pps(uhd::time_spec_t(0.0), uhd::usrp::multi_usrp::ALL_MBOARDS); boost::this_thread::sleep(boost::posix_time::seconds(1)); //wait for pps sync pulse Again, the three boards are time-synchronized (usrp->get_time_synchronized () returns true) but the phase misalignment issue is still unresolved. If I understand it correctly, whatever comes between set_command_time() and clear_command_time() will be executed in the three boards at cmd_time. Any advice or hint? Best regards, Zohair From: zohair_ms@hotmail.com To: mleech@ripnet.com Date: Fri, 10 May 2013 13:53:31 +0000 CC: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Phase difference with synchronized boards OK... now I understand it. Thanks a lot, Zohair Date: Fri, 10 May 2013 09:10:52 -0400 From: mleech@ripnet.com To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Phase difference with synchronized boards Dear All, My setup has three USRP N200 boards with DBSRX2 synchronized a GPS receiver REF/PPS, split and fed to the boards. The boards are connected directly to a PC using three 1Gb Ethernet ports belonging to three different subnets. Using the UHD, I wrote a c++ code (MSVC/Windows) setting all the parameters to the USRPs and syncing them, reading time-aligned samples from the boards and storing them in three separate files. To test the sync, I splid a sinusoidal signal (-20dBm) and fed it to the RF boards input. Then, I execute the UHD command: usrp->get_time_synchronized () and it returns true. I expected to see three sinusoids at the top of each other but when I import the samples into MATLAB and plot them, there is a phase shift that is different from a run to another. To investigate more, I used usrp->get_time_now(x) (where x=0,1,2) and the time is quite the same: Time at board0 is: 0.433092 Time at board1 is: 0.433467 Time at board2 is: 0.433874 which means the PPS and REF sync signals are really latched. A colleague raised an argument that even though the boards' clock are synch the daughter boards may introduce phase shift. Is this argument valid here? Do you have any insights? Thanks, Zohair _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com The phase will be coherent, but with an unknown phase offset between all the "players". This is due to the way PLL synthesizers work using fractional-N synthesis. There will always be some random phase offset between the synthesizers involved. If they all have a common reference, they'll all "march together", but will have an offset. You'll need to calibrate that out every time you start a "run" or retune your boards. The SBX board has a special feature that allows you to use "timed commands" to get all the synthesizers to be phase-aligned when tuned together at the same time. The DBSRX synthesizer doesn't have the necessary hardware support for that. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
JB
Josh Blum
Thu, Jun 27, 2013 5:55 PM

On 06/27/2013 08:08 AM, Zohair M. Abu Shaban wrote:

Dear Marcus and all,

Following up with the discussion below, we have purchased three SBX
boards. I used the following commands as per the application notes:

std::cout << boost::format("Setting RX Freq: %f MHz...") % (freq/1e6)
<< std::endl; uhd::time_spec_t cmd_time = usrp->get_time_now() +
uhd::time_spec_t(0.1); usrp->set_command_time(cmd_time);
usrp->set_rx_freq(freq,0); usrp->set_rx_freq(freq,1);
usrp->set_rx_freq(freq,2); usrp->clear_command_time(); std::cout <<
boost::format("Actual RX Freq: %f MHz...") %
(usrp->get_rx_freq(0)/1e6) << std::endl; std::cout <<
boost::format("Actual RX Freq: %f MHz...") %
(usrp->get_rx_freq(1)/1e6) << std::endl; std::cout <<
boost::format("Actual RX Freq: %f MHz...") %
(usrp->get_rx_freq(2)/1e6) << std::endl << std::endl;

These commands were used after synchronizing the boards using:
usrp->set_time_source("external");
usrp->set_time_next_pps(uhd::time_spec_t(0.0),
uhd::usrp::multi_usrp::ALL_MBOARDS);
boost::this_thread::sleep(boost::posix_time::seconds(1)); //wait for
pps sync pulse

Again, the three boards are time-synchronized
(usrp->get_time_synchronized () returns true) but the phase
misalignment issue is still unresolved. If I understand it correctly,
whatever comes between set_command_time() and clear_command_time()
will be executed in the three boards at cmd_time.

Any advice or hint?

I used this python script to test the phase stability over time after a
single tune operation: http://pastebin.com/3D35YuM6

And this one to test the repeatability of achieving the same phase
offset after repeated retuning: http://pastebin.com/wqace6xp

The scripts use numpy and gnuradio's gr-uhd module. The API calls are
equivalent to the C++ ones of UHD. Both scripts can act as a reference
to for synchronization, capture, and calculating the phase offset.

I hope that helps,
-josh

Best regards, Zohair From: zohair_ms@hotmail.com To:
mleech@ripnet.com Date: Fri, 10 May 2013 13:53:31 +0000 CC:
usrp-users@lists.ettus.com Subject: Re: [USRP-users] Phase difference
with synchronized boards

OK... now I understand it.

Thanks a lot, Zohair

Date: Fri, 10 May 2013 09:10:52 -0400 From: mleech@ripnet.com To:
usrp-users@lists.ettus.com Subject: Re: [USRP-users] Phase difference
with synchronized boards

Dear All,

My setup has three USRP N200 boards with DBSRX2 synchronized a GPS
receiver REF/PPS, split and fed to the boards. The boards are
connected directly to a PC using three 1Gb Ethernet ports belonging
to three different subnets.

Using the UHD, I wrote a c++ code (MSVC/Windows) setting all the
parameters to the USRPs and syncing them, reading time-aligned
samples from the boards and storing them in three separate files. To
test the sync, I splid a sinusoidal signal (-20dBm) and fed it to the
RF boards input. Then, I execute the UHD command:
usrp->get_time_synchronized () and it returns true. I expected to see
three sinusoids at the top of each other but when I import the
samples into MATLAB and plot them, there is a phase shift that is
different from a run to another. To investigate more, I used
usrp->get_time_now(x)  (where x=0,1,2) and the time is quite the
same:

Time at board0 is: 0.433092

Time at board1 is: 0.433467

Time at board2 is: 0.433874

which means the PPS and REF sync signals are really latched.

A colleague raised an argument that even though the boards' clock are
synch the daughter boards may introduce phase shift. Is this argument
valid here?

Do you have any insights?

Thanks,

Zohair

_______________________________________________ USRP-users mailing
list USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

The phase will be coherent, but with an unknown phase offset between
all the "players".

This is due to the way PLL synthesizers work using fractional-N
synthesis.  There will always be some random phase offset between the
synthesizers

involved.  If they all have a common reference, they'll all "march
together", but will have an offset.  You'll need to calibrate that
out every time

you start a "run" or retune your boards.

The SBX board has a special feature that allows you to use "timed
commands" to get all the synthesizers to be phase-aligned when tuned
together

at the same time.  The DBSRX synthesizer doesn't have the necessary
hardware support for that.

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

_______________________________________________ USRP-users mailing
list USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

_______________________________________________ USRP-users mailing
list USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

_______________________________________________ USRP-users mailing
list USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

On 06/27/2013 08:08 AM, Zohair M. Abu Shaban wrote: > > Dear Marcus and all, > > Following up with the discussion below, we have purchased three SBX > boards. I used the following commands as per the application notes: > > std::cout << boost::format("Setting RX Freq: %f MHz...") % (freq/1e6) > << std::endl; uhd::time_spec_t cmd_time = usrp->get_time_now() + > uhd::time_spec_t(0.1); usrp->set_command_time(cmd_time); > usrp->set_rx_freq(freq,0); usrp->set_rx_freq(freq,1); > usrp->set_rx_freq(freq,2); usrp->clear_command_time(); std::cout << > boost::format("Actual RX Freq: %f MHz...") % > (usrp->get_rx_freq(0)/1e6) << std::endl; std::cout << > boost::format("Actual RX Freq: %f MHz...") % > (usrp->get_rx_freq(1)/1e6) << std::endl; std::cout << > boost::format("Actual RX Freq: %f MHz...") % > (usrp->get_rx_freq(2)/1e6) << std::endl << std::endl; > > These commands were used after synchronizing the boards using: > usrp->set_time_source("external"); > usrp->set_time_next_pps(uhd::time_spec_t(0.0), > uhd::usrp::multi_usrp::ALL_MBOARDS); > boost::this_thread::sleep(boost::posix_time::seconds(1)); //wait for > pps sync pulse > > Again, the three boards are time-synchronized > (usrp->get_time_synchronized () returns true) but the phase > misalignment issue is still unresolved. If I understand it correctly, > whatever comes between set_command_time() and clear_command_time() > will be executed in the three boards at cmd_time. > > Any advice or hint? > I used this python script to test the phase stability over time after a single tune operation: http://pastebin.com/3D35YuM6 And this one to test the repeatability of achieving the same phase offset after repeated retuning: http://pastebin.com/wqace6xp The scripts use numpy and gnuradio's gr-uhd module. The API calls are equivalent to the C++ ones of UHD. Both scripts can act as a reference to for synchronization, capture, and calculating the phase offset. I hope that helps, -josh > Best regards, Zohair From: zohair_ms@hotmail.com To: > mleech@ripnet.com Date: Fri, 10 May 2013 13:53:31 +0000 CC: > usrp-users@lists.ettus.com Subject: Re: [USRP-users] Phase difference > with synchronized boards > > > > > > > > > > OK... now I understand it. > > Thanks a lot, Zohair > > Date: Fri, 10 May 2013 09:10:52 -0400 From: mleech@ripnet.com To: > usrp-users@lists.ettus.com Subject: Re: [USRP-users] Phase difference > with synchronized boards > > > > > > > > > > Dear All, > > > > My setup has three USRP N200 boards with DBSRX2 synchronized a GPS > receiver REF/PPS, split and fed to the boards. The boards are > connected directly to a PC using three 1Gb Ethernet ports belonging > to three different subnets. > > > > Using the UHD, I wrote a c++ code (MSVC/Windows) setting all the > parameters to the USRPs and syncing them, reading time-aligned > samples from the boards and storing them in three separate files. To > test the sync, I splid a sinusoidal signal (-20dBm) and fed it to the > RF boards input. Then, I execute the UHD command: > usrp->get_time_synchronized () and it returns true. I expected to see > three sinusoids at the top of each other but when I import the > samples into MATLAB and plot them, there is a phase shift that is > different from a run to another. To investigate more, I used > usrp->get_time_now(x) (where x=0,1,2) and the time is quite the > same: > > Time at board0 is: 0.433092 > > Time at board1 is: 0.433467 > > Time at board2 is: 0.433874 > > > > which means the PPS and REF sync signals are really latched. > > > > > > A colleague raised an argument that even though the boards' clock are > synch the daughter boards may introduce phase shift. Is this argument > valid here? > > > > > > Do you have any insights? > > > > Thanks, > > Zohair > > _______________________________________________ USRP-users mailing > list USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > The phase will be coherent, but with an unknown phase offset between > all the "players". > > > > This is due to the way PLL synthesizers work using fractional-N > synthesis. There will always be some random phase offset between the > synthesizers > > involved. If they all have a common reference, they'll all "march > together", but will have an offset. You'll need to calibrate that > out every time > > you start a "run" or retune your boards. > > > > The SBX board has a special feature that allows you to use "timed > commands" to get all the synthesizers to be phase-aligned when tuned > together > > at the same time. The DBSRX synthesizer doesn't have the necessary > hardware support for that. > > > > > > > > -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy > Consortium http://www.sbrac.org > > > > > _______________________________________________ USRP-users mailing > list USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > _______________________________________________ USRP-users mailing > list USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > > _______________________________________________ USRP-users mailing > list USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
ZM
Zohair M. Abu Shaban
Thu, Jul 4, 2013 1:04 PM

Dear Josh,

Sorry for the late response but I work on this stuff on Thursdays.

I am working in Windows environment but I have Linux/GNURadio on the machine too and tried your scripts but I encoutered an error with importing autotest. Therefore I wasn't able to verify the phase stability. However, I noticed that the phase difference (~0.4 usec) is  constant for all runs and I was able to estimate it in MATLAB (using recorded signals), but aren't they supposed to be aligned? Where does this difference come from?

Thanks,
Zohair

Date: Thu, 27 Jun 2013 13:55:54 -0400
From: josh@ettus.com
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Phase difference with synchronized boards

I used this python script to test the phase stability over time after a
single tune operation: http://pastebin.com/3D35YuM6

And this one to test the repeatability of achieving the same phase
offset after repeated retuning: http://pastebin.com/wqace6xp

The scripts use numpy and gnuradio's gr-uhd module. The API calls are
equivalent to the C++ ones of UHD. Both scripts can act as a reference
to for synchronization, capture, and calculating the phase offset.

I hope that helps,
-josh

Dear Josh, Sorry for the late response but I work on this stuff on Thursdays. I am working in Windows environment but I have Linux/GNURadio on the machine too and tried your scripts but I encoutered an error with importing autotest. Therefore I wasn't able to verify the phase stability. However, I noticed that the phase difference (~0.4 usec) is constant for all runs and I was able to estimate it in MATLAB (using recorded signals), but aren't they supposed to be aligned? Where does this difference come from? Thanks, Zohair > Date: Thu, 27 Jun 2013 13:55:54 -0400 > From: josh@ettus.com > To: usrp-users@lists.ettus.com > Subject: Re: [USRP-users] Phase difference with synchronized boards > > I used this python script to test the phase stability over time after a > single tune operation: http://pastebin.com/3D35YuM6 > > And this one to test the repeatability of achieving the same phase > offset after repeated retuning: http://pastebin.com/wqace6xp > > The scripts use numpy and gnuradio's gr-uhd module. The API calls are > equivalent to the C++ ones of UHD. Both scripts can act as a reference > to for synchronization, capture, and calculating the phase offset. > > I hope that helps, > -josh
JB
Josh Blum
Fri, Jul 5, 2013 12:11 AM

I am working in Windows environment but I have Linux/GNURadio on the
machine too and tried your scripts but I encoutered an error with
importing autotest. Therefore I wasn't able to verify the phase

Well, thats a custom python module I wrote for a siggen in my lab. You
would have to have to change that part. Chances you that you dont have
my siggen :-)

stability. However, I noticed that the phase difference (~0.4 usec)
is  constant for all runs and I was able to estimate it in MATLAB
(using recorded signals), but aren't they supposed to be aligned?
Where does this difference come from?

The point of the timed synchronization is to reset the counters in the
SBX's synthesizers at a precise time so the state of the synthesizers
dividers will not contribute to random phase offset.

Aside from that, why have offset at all? I dont think thats possible to
have 0 phase offset. No two synthesizers, filters, cables, etc.. are the
same. The combined variability means that there will be some relative
offset between units.

The key here is that the offset is constant over time and over retunes.
That means relative phase offsets can be measured once and compensated
for -- depending upon the application's needs.

-josh

Thanks, Zohair

Date: Thu, 27 Jun 2013 13:55:54 -0400 From: josh@ettus.com To:
usrp-users@lists.ettus.com Subject: Re: [USRP-users] Phase
difference with synchronized boards

I used this python script to test the phase stability over time
after a single tune operation: http://pastebin.com/3D35YuM6

And this one to test the repeatability of achieving the same phase
offset after repeated retuning: http://pastebin.com/wqace6xp

The scripts use numpy and gnuradio's gr-uhd module. The API calls
are equivalent to the C++ ones of UHD. Both scripts can act as a
reference to for synchronization, capture, and calculating the
phase offset.

I hope that helps, -josh

> I am working in Windows environment but I have Linux/GNURadio on the > machine too and tried your scripts but I encoutered an error with > importing autotest. Therefore I wasn't able to verify the phase Well, thats a custom python module I wrote for a siggen in my lab. You would have to have to change that part. Chances you that you dont have my siggen :-) > stability. However, I noticed that the phase difference (~0.4 usec) > is constant for all runs and I was able to estimate it in MATLAB > (using recorded signals), but aren't they supposed to be aligned? > Where does this difference come from? > The point of the timed synchronization is to reset the counters in the SBX's synthesizers at a precise time so the state of the synthesizers dividers will not contribute to random phase offset. Aside from that, why have offset at all? I dont think thats possible to have 0 phase offset. No two synthesizers, filters, cables, etc.. are the same. The combined variability means that there will be some relative offset between units. The key here is that the offset is constant over time and over retunes. That means relative phase offsets can be measured once and compensated for -- depending upon the application's needs. -josh > Thanks, Zohair > >> Date: Thu, 27 Jun 2013 13:55:54 -0400 From: josh@ettus.com To: >> usrp-users@lists.ettus.com Subject: Re: [USRP-users] Phase >> difference with synchronized boards >> >> I used this python script to test the phase stability over time >> after a single tune operation: http://pastebin.com/3D35YuM6 >> >> And this one to test the repeatability of achieving the same phase >> offset after repeated retuning: http://pastebin.com/wqace6xp >> >> The scripts use numpy and gnuradio's gr-uhd module. The API calls >> are equivalent to the C++ ones of UHD. Both scripts can act as a >> reference to for synchronization, capture, and calculating the >> phase offset. >> >> I hope that helps, -josh > > >
Next page
Empathy v1.0   2026 ©emwd.com
Documentation