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:mle...@ripnet.com>
*Sent:* Wednesday, October 25, 2017 1:20 PM
*To:* John Shields <mailto:john.shie...@xtra.co.nz>
*Cc:* usrp-users <mailto:usrp-users@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:* mle...@ripnet.com <mailto:mle...@ripnet.com>
*Sent:* Wednesday, October 25, 2017 7:45 AM
*To:* John Shields <mailto:john.shie...@xtra.co.nz>
*Cc:* usrp-users <mailto:usrp-users@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@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
