On 07/05/2016 06:47 PM, Pavan Yedavalli wrote:
Hi Marcus,

Thanks for the background. That helps greatly. Having said that, I am unclear which commands specifically tune the radios, so I did the following around the frequency tuning (after all of the time source, gain, and antenna setting code):

        addr_string = "addr0=192.168.10.3,addr1=192.168.10.4"
        self.uhd_usrp_sink_0_0 = uhd.usrp_sink(
            ",".join((addr_string, "")),
            uhd.stream_args(
                cpu_format="fc32",
                channels=range(2),
            ),
        )


        self.uhd_usrp_sink_0_0.set_clock_source("external", 0)
        self.uhd_usrp_sink_0_0.set_time_source("external", 0)
        self.uhd_usrp_sink_0_0.set_clock_source("mimo", 1)
        self.uhd_usrp_sink_0_0.set_time_source("mimo", 1)
        self.uhd_usrp_sink_0_0.set_samp_rate(samp_rate)
        self.uhd_usrp_sink_0_0.set_gain(31.5, 0)
        self.uhd_usrp_sink_0_0.set_gain(31.5, 1)
        self.uhd_usrp_sink_0_0.set_antenna("TX/RX", 0)
        self.uhd_usrp_sink_0_0.set_antenna("TX/RX", 1)
self.analog_sig_source_x_0_1 = analog.sig_source_c(samp_rate, analog.GR_CONST_WAVE, 10000, 1, 0) self.analog_sig_source_x_0_0_0 = analog.sig_source_c(samp_rate, analog.GR_CONST_WAVE, 10000, 1, 0)


*self.uhd_usrp_sink_0_0.set_time_unknown_pps(uhd.time_spec())
        now = self.uhd_usrp_sink_0_0.get_time_now()
        start_time = now + uhd.time_spec(.5)
        self.uhd_usrp_sink_0_0.set_command_time(start_time)
        self.uhd_usrp_sink_0_0.set_center_freq(915000000, 0)
        self.uhd_usrp_sink_0_0.set_center_freq(915000000, 1)
        self.uhd_usrp_sink_0_0.clear_command_time()*


However, when running it, this does not appear to produce a constant offset either, but I'm not sure whether this is the correct code to wrap around. Please keep me posted. Thanks.

On Tue, Jul 5, 2016 at 12:49 PM, <mle...@ripnet.com <mailto:mle...@ripnet.com>> wrote:

    That is precisely what I'm saying, and precisely what
    timed-commands for tuning were invented.  On certain hardware,
    after the tune is complete, a phase-reset pulse is sent by the
    FPGA. The only way for THAT to have the desired effect is to make
    sure that the phase-reset pulse happens at the same instant.

    Modern synthesizers use a technique called fractional-N
    synthesis.  One of the side effects of this is that you can't
    predict where the LO will "lock" with respect to the reference
    clock. So, any two PLL synthesizers, even when feed an identical
    reference clock, will not have the same phase offset with respect
    to one another.  It's the "physics" of fractional-N PLL synthesis.

    SO, if you're using GRC to generate you flows, you'll have to
    modify the generated code, and wrap
    set_command_time()/clear_command_time() around the place in the
    code where it tunes the radios.

    Clearly, if this depends on TIME, then all radios involved need to
    agree on the current time, to high precision, hence the related
    requirement for set_time_unknown_pps(), which uses the 1PPS signal
    to trigger loading of the time-of-day clocks on each USRP in the
    multi_usrp object.

    On 2016-07-05 15:41, Pavan Srikrishna Yedavalli wrote:

    I am using USRP N210 with SBX daughterboards. All devices are
    connected to the octoclock ref and octoclock PPS. It would be
    nice to get phase alignment, but mere coherence-with-an-offset is
    sufficient if that offset stays constant across different runs of
    the file/flowgraph. Are you saying that that offset cannot be
    constant due to the randomness of the LO phase offset at each
    run? Thanks again.

    _____________________________
    From: mle...@ripnet.com <mailto:mle...@ripnet.com>
    Sent: Tuesday, July 5, 2016 12:35 PM
    Subject: Re: [Discuss-gnuradio] random phase offset constantly
    changing with octoclock setup
    To: Pavan Yedavalli <psy2...@columbia.edu
    <mailto:psy2...@columbia.edu>>
    Cc: Discuss-gnuradio
    <discuss-gnuradio-bounces+mleech=ripnet....@gnu.org
    <mailto:discuss-gnuradio-bounces+mleech=ripnet....@gnu.org>>,
    GNURadio Discussion List <discuss-gnuradio@gnu.org
    <mailto:discuss-gnuradio@gnu.org>>


    WHat specific hardware line-up do you have?

    You have to use set_time_unknown_pps(), but also, if you want
    phase alignment (as opposed to mere coherence-with-an-offset),
    you need to use timed tuning commands across your systems. This
    will result in zero relative phase offset between boards, if
    you're using SBX or UBX (on the X310).  Note that this is phase
    between the boards, there's no way to make certain the the LO
    phase has a predictable offset with respect to external received
    signals, only that the two LO phases agree.

    On 2016-07-05 15:26, Pavan Yedavalli wrote:

        Hi,
        Despite all of my boards being connected via the Octoclock
        (ref and pps), I am constantly getting different phase
        offsets every time I run a gnuradio flowgraph (or python file).
        I am not sure why this is happening, but I do know that I
        need to call one of the functions, set_time_now() and/or
        set_time_unknown_pps(), to make sure all of them are synced.
        Which one am I supposed to call? I have been calling
        set_time_unknown_pps(), but I am getting the above/below
        problem with that, so maybe set_time_now() could be correct?
        In general, I don't understand why I continually get a
        different random phase offset of all of the radios after
        every new flowgraph run. Shouldn't this offset be the same if
        I continue to transmit at the same frequency? Would one of
        the above functions fix that?
        Hopefully that is clear. Thank you so much for the help.
-- Pavan

        _______________________________________________
        Discuss-gnuradio mailing list
        Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
        https://lists.gnu.org/mailman/listinfo/discuss-gnuradio






--
Pavan
How are you measuring the phase-offset between the two sinks?


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to