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
