[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
Wed Oct 25 10:56:23 EDT 2017


On 10/25/2017 03:16 AM, John Shields wrote:
> Thanks very much Marcus for the thorough explanations. I looked at the 
> phase change with frequency to see if there was a fixed delay and 
> there didn’t appear to be but, effectively, the MIMO cable induces a 
> frequency dependent uncorrected phase offset  which is eminently 
> understandable but would appear to make a mockery of ‘MIMO’ claims. I 
> realised that there will always be a phase offset but was disappointed 
> by the magnitude as measured by the complex conjugate of both signals, 
> a complex_to_arg block and decimating the result by 1K and plotting on 
> Qt GUI Time Sink.
In commercial MIMO applications, the implementation corrects for 
phase-offset error, because it is (reasonably) expected that there will 
always be
   some amount of phase offset.  It's inevitable for there to be 
*some*.   For example, the DRAO synthesis array uses hardware to measure the
   phase length of each of their cables, and corrects for 
thermal-expansion effects in real-time.  Since phase-offset error (and 
drift) extends outwards
   away from the USRP envelope, it's not realistic to expect that all 
such effects are accounted for in the hardware (at least, not without a much
   higher price-tag).

> It would appear that if I wanted to try to get as close to zero phase 
> offset (to correct for non-zero MIMO cable length at least), then I 
> need an Octoclock-G but I don’t have the nearly  $NZD 3000.00 it costs 
> so I wonder if there is a ‘cheap’ way to convert my existing GPSDO 
> board into an Octoclock-G? I only need to be able to buffer the signal 
> for 2 USRPs.
You could just try splitting the signal two ways.   Myself, I buffer 
such signals with 74HC04 inverters, but I'm handy with a soldering 
iron.  There are
   cheap GPSDOs out there now, so it's just a matter of buffering, and 
for only 2 units, you might be able to get away with just splitting them.


> Otherwise, I guess I could ‘calibrate’ the offset at various 
> frequencies and then, at run time, apply a phase correction to one leg 
> based on the fc? Seems a little inelegant.
That is *PRECISELY* what most MIMO applications do, and folks doing 
beam-forming, etc.  There will ALWAYS be some amount of phase offset--
   some of it fixed, some of it variable.   It is a *systemic* 
imperfection, which means that it has to be corrected for that account 
for all the systemic
   contributions, including hardware entirely outside of the USRP.


>             Kind Regards,
>                        John
> *From:* Marcus D. Leech <mailto:mleech at ripnet.com>
> *Sent:* Wednesday, October 25, 2017 1:20 PM
> *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
> 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/20171025/a9357884/attachment-0002.html>


More information about the USRP-users mailing list