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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
