Thanks Marcus,
                         I take your advice re: ‘calibration’ and DRAO.

                         I had hoped, however, that I would not be dealing with 
> 100 degree offset in an ideal environment i.e. same signal through a good 
quality splitter positioned right at the input to the SBXs. While it was 
immediately obvious when you mentioned that the MIMO implementation makes no 
correction for the delay (not even the roughest based on the length and 
velocity factor which would not cover eveerything), it does mean (to me at 
least) that I am dealing with a larger offset than I thought from the Ettus 
documentation with all the talk about synching SBX LO etc. and, while 
mentioning there are component factors which mean that the offset was not zero, 
not highlighting there is a deliberate frequency sensitive offset built in to 
the design of the ‘'MIMO cable”.

                        Will ponder my next move.

                                  Kind Regards,

                                             John

From: Marcus D. Leech
Sent: Thursday, October 26, 2017 3:56 AM
To: John Shields
Cc: usrp-users
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/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
  Sent: Wednesday, October 25, 2017 1:20 PM
  To: John Shields
  Cc: usrp-users
  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
    Sent: Wednesday, October 25, 2017 7:45 AM
    To: John Shields
    Cc: usrp-users
    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

           Virus-free. www.avast.com



      _______________________________________________
      USRP-users mailing list
      USRP-users@lists.ettus.com
      http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com





---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to