[USRP-users] 2 N200 MIMO system phase offset varies with frequency, have used timed_command with tune and also integer-N Tuning per Marcus M post of Feb 17, 2016

Marcus D. Leech mleech at ripnet.com
Tue Oct 24 20:20:52 EDT 2017


On 10/24/2017 07:45 PM, John Shields wrote:
> Thanks Marcus,
>                         So it appears that the synching of the SBX LOs 
> doesn’t work; or perhaps I should say, it doesn’t work during my 
> measurement period? The integer-N tuning doesn’t work either.
>                         I can say that, with some level of precision, 
> the phase is fairly constant with center-frequency but if, for 
> example, I had a 5 MHz spectrum how could I ‘correct for that’? I 
> be;ieve that there is the whole Hilbert transform issue when you wish 
> to translate the phase/frequency of a band of signals to a different 
> one –is that what I should use?
>                         From my point of view, there is quite a 
> misinterpretation of what ‘synchronistation’ means; in particular for 
> SBXs and their LOs which, as advertised, are supposed to be capable of 
> such operation with a few simple Python commands!.
>                         Realising that you would/should not express 
> some shortcoming in the SBX,N200,MIMO in an Ettus product , if there 
> is, I would dearly like to know from someone from Ettus!!!! Purely 
> from an outside point of view, I thought that the “ we’ll transfer the 
> Time Of Day contents to the Mate over MIMO cable ” doesn’t actually 
> mean that they are in ‘real time’ synch, from my old DMS-100 days bit 
> was willing to go along with the theory. Seriously, I have no issue 
> with that but just want to know how to get 2 N200r4 streams with OB 
> GPSDO & MIMO cable ‘synchronised’
>                        I would love (but be embarrassed) to be told, 
> that as a dummy, I made this mistake but in over a month of work I 
> have not been able to establish that.
>                       Kind Regards,
>                                    John
Set up a test transmitter in the far-field of your two antenna.

With everything synchronized the way you think it should be, plot the 
low-pass-filtered (and decimate to taste) result of a conjugate multiply of
   the two sides.   This should produce a straight line, with small 
amounts of noise.   If it just produces random walks all over the place, 
the two
   oscillators aren't locked to the same reference.

My point about component tolerances is that they'll have some 
group-delay that isn't perfectly matched on both sides, even if things 
like the
   LO are running in-phase, the analog pathways won't necessarily have 
precisely the same group delay on the two sides.  Just like two random
   pieces of coax that are cut to the same length won't, necessarily, 
have precisely the same phase length.   This effect gets worse with 
frequency.

Further, in radio astronomy applications, the coherence bandwidth is, 
technically speaking, infinitely small, due to the emission mechanisms.
   But in *practice* a significant fractional bandwidth is possible 
without having to channelize the input bandwidth.

The *other* issue, that seems to be causing consternation, is the 
ability to predict what the phase-offset between the two sides will be 
upon restart
   of the flow-graph in the presence of the various bits of hocus-pocus 
(timed commands, etc) to try for consistent phase offsets every time you
   start streaming.  It sounds like you have that, but the offset 
changes depending on tuned frequency.   I'd expect that.  Both due to 
analog-component
   group-delay variability, and because the MIMO cable is not of zero 
length.  I don't believe that there is *ANY* length compensation, so one 
N2XX will
   receive the reference clock at a "closer" phase distance than the 
other one, because the MIMO cable is of finite length.  That 
phase-length difference will
   have more effect at higher frequencies, because a PLL is a reference 
multiplier (which is why having exquisitely-low phase-noise on the 
reference is
   important, because that noise will get worse as the multiplier ratio 
of the PLL increases).




> *From:* mleech at ripnet.com <mailto:mleech at ripnet.com>
> *Sent:* Wednesday, October 25, 2017 7:45 AM
> *To:* John Shields <mailto:john.shields at xtra.co.nz>
> *Cc:* usrp-users <mailto:usrp-users at lists.ettus.com>
> *Subject:* Re: [USRP-users] 2 N200 MIMO system phase offset varies 
> with frequency, have used timed_command with tune and also integer-N 
> Tuning per Marcus M post of Feb 17, 2016
>
> I would expect component tolerance issues on the two sides to scale 
> with frequency.  That may be what you're seeing?
>
> On 2017-10-24 14:28, John Shields via USRP-users wrote:
>
>> Hi,
>>     Still struggling with the configuration – 2x N200 r4, master O/B 
>> GPSDO, slave MIMO cable. Have put in python code to use timed 
>> commands and that produced a constant phase offset even over rerun of 
>> FG or power cycling on N200 which was great news.
>>     However, the relative offset changes with frequency. The splitter 
>> is a Mini-circuits ZRFSC-123S+ which is spec-ed to has a typical of 
>> phase unbalance of 1/2 a degree over the frequency ranges used. The 
>> results are independent of source NWT 4000-1 or an SBX using 
>> uhd_siggen. When I have checked the ref_locked flags etc. they are 
>> good. the gpsdo is 'locked' as is MIMO.
>>     In addition to using the timed_commands to synch the SBX LOs, I 
>> also implement the integer-N-tuning and no improvement.
>>     The results are roughly    Freq (MHz) Phase offset (deg)
>> 450                    -7
>> 1450                -30
>> 1950                -65
>> 2450                -100
>>     When I switch the cables between the 2 N200, the phase offset 
>> doesn't change sign so I presume it is not cabling? What on earth, 
>> else, could it be?
>>           Kind Regards,
>>                    John
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>> 	Virus-free. www.avast.com 
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171024/a06ec4a7/attachment-0002.html>


More information about the USRP-users mailing list