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
