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> 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
> 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>
> Cc: Discuss-gnuradio <discuss-gnuradio-bounces+mleech=ripnet....@gnu.org>,
> GNURadio Discussion List <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
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
--
Pavan
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
