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
