The way I'm doing it is the following (please correct me if there is a
fundamental error in assumptions): I am actually using an RSSI circuit that
is receiving the power from the USRPs/antennas, and I'm determining whether
the phase offset is the same based on that RSSI value. For example, I run
the flowgraph once, and I get an RSSI value on the other side of 2.5 mW,
but when I run the flowgraph again, it produces an RSSI value of 9.5 mW. In
my mind, if that offset was constant, then it would have produced something
around 2.5 mW again. I know this adds another variable to the mix, but I
have confirmed the accurate functioning of the RSSI circuit/receiver as
well as the static nature of the channel, so its reading is very reliable.
On Tue, Jul 5, 2016 at 4:19 PM, Marcus D. Leech <mle...@ripnet.com> wrote:
> 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> 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
>
> How are you measuring the phase-offset between the two sinks?
>
>
>
--
Pavan
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
