[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
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
> 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,
> *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,
> 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
> 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
> 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:
>>> 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,
>>> Virus-free. www.avast.com
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users