<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I can confirm that the phase_accumulator that drives the CORDIC in the TX DSP is reset to 0 every time the TX_DSP goes idle, thus the "LO" generated digitally DUC will always restart at phase=0 as a new transmission commences.<div>One quick work around maybe to prevent UHD from using the CORDIC as part of the the tuning solution….if the CORDIC phase increment is zero then this should remove this source of phase ambiguity at the expense of a coarser minimum tuning quanta.</div><div>Alternatively you could transmit continuously with both USRP's but send digital silence when idle so that CORDIC phase remains locked between the units.</div><div>-Ian</div><div><br><div><div>On Dec 8, 2014, at 8:20 AM, Marcus Müller via USRP-users <<a href="mailto:usrp-users@lists.ettus.com">usrp-users@lists.ettus.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
  
    <meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
  
  <div text="#000000" bgcolor="#FFFFFF">
    Hi Jawad,<br>
    <br>
    you're raising an interesting point which I missed: yes, the
    oscillators should be running continously after they've been tuned,
    as far as I can remember; this changes the nature of the problem
    slightly, rendering it even more interesting!<br>
    <br>
    So, from a quick discussion with the others (thanks to Marcus
    Leech), I conclude that the digital pseudo-oscillator is seeing
    phase resets after transmissions, which would explain what you are
    seeing. Maybe your idea of the CORDIC only rotating when you're
    transmitting makes sense, too, so I propose a simple test:<br>
    <br>
    a) if you keep the length of burst "S" constant and just move it by
    a few samples in time, and the result (reception of P3/P4) stays the
    same, it's the rotation that only happens when you transmit, or<br>
    b) if you shorten burst "S" by n samples, but move the tx_time of
    "S" into the future by n samples, it's the reset that changes your
    phase.<br>
    <br>
    In case a) you can possibly solve the issue by sending zeros on USRP
    B as long as you transmit data on A, in case b) you can achieve the
    same effect only by having a burst that ends at the same point in
    time (containing zeros), but could be much shorter than burst "S".<br>
    <br>
    I know these are non-ideal solutions, and I wish I had the definite
    answer right now, but the matter at hand is really not that easy to
    solve if you can just look at verilog code; for reference: the
    verilog model duc [1] contains a cordic, which resets on a ddc
    reset. duc_chain [2] contains ddc, and is instantiated in the
    u2plus_core [3]. The reset signals in there just confuse me, and
    since I can't just chipscope into that design right now, it's very
    hard to guess when the dsp_rst signal is active.<br>
    <br>
    Greetings,<br>
    Marcus<br>
    <br>
    [1]
    <a class="moz-txt-link-freetext" href="https://github.com/EttusResearch/fpga/blob/master/usrp2/sdr_lib/duc.v">https://github.com/EttusResearch/fpga/blob/master/usrp2/sdr_lib/duc.v</a><br>
    [2]
<a class="moz-txt-link-freetext" href="https://github.com/EttusResearch/fpga/blob/master/usrp2/sdr_lib/duc_chain.v">https://github.com/EttusResearch/fpga/blob/master/usrp2/sdr_lib/duc_chain.v</a><br>
    [3]
<a class="moz-txt-link-freetext" href="https://github.com/EttusResearch/fpga/blob/master/usrp2/top/N2x0/u2plus_core.v#L727">https://github.com/EttusResearch/fpga/blob/master/usrp2/top/N2x0/u2plus_core.v#L727</a><br>
    <br>
    <div class="moz-cite-prefix">On 12/08/2014 04:09 PM, Jawad Seddar
      via USRP-users wrote:<br>
    </div>
    <blockquote cite="mid:CAE9WgF9rDzeBKAi+6-indDPYwEuPC+A3psO=p9U4AKp7BzsdVg@mail.gmail.com" type="cite">
      <pre wrap="">Thank you Marcus for taking the time to read and respond, much appreciated.

If I understand your first paragraph correctly and taking the attached
image as an example, if both A and B are tuned before P1 and we assume
phases are aligned at this time, then when sending P1 and P2, the RF
oscillators used to mix the RF signals from both A and B will have the same
phase. Then when A sends S, its RF oscillator phase will rotate, thus when
sending P3 its phase will be different than the RF oscillator used in B. Is
this somewhat correct?

I thought that the oscillator used to mix the RF signals would be always
running thus its phase would only be time dependent and not dependent on
the amount of samples going out of the radio.


Please find attached a more detailed representation of what I am actually
doing.
As you can see, packets with the same contents are sent from both A and B
at the same time.

A has an extra packet that it sends in between transmissions of common
packets.
All packets are time tagged and common packets leave both devices at the
same time instants.

Tuning only occurs once at the beginning of the execution.

Regards,
Jawad


2014-12-08 15:04 GMT+01:00 Marcus Müller <a class="moz-txt-link-rfc2396E" href="mailto:usrp-users@lists.ettus.com"><usrp-users@lists.ettus.com></a>:

</pre>
      <blockquote type="cite">
        <pre wrap=""> Hi Jawad,

thank you very much for this interesting mail!

The SBX has a special architecture based on a LO synthesizer that allows
to have a deterministic phase after tuning, ie. if you tune both
daughterboards at the same time, the oscillator used to mix the RF signals
will be at the same phase.
Starting packets at different points in time will, w.l.o.g., lead to
differing phases, which seems to be exactly what you are observing.

Since on USRPs the sample clock (which is the clock used when specifying
timestamps for tx_time) and the LO are generally coherent (being generated
from the same reference clock), you can try to only use tx_time offsets
that are integer multiples of LO (^1) oscillations, but I've never tried
that; it's possible that the phase-reconstruction mechanism of the SBX is
not completely time-invariant.

Greetings,
Marcus

(^1) Please note that the frequency you use for your USRP is not
inherently the frequency that you tune to. The USRP will, by default, tune
as close as possible with the LO synthesizer, and correct the rest by
frequency shifting in the FPGA. To be sure which frequency you set, you
will need to evaluate the tune_result_t that set_center_freq().


On 12/08/2014 09:34 AM, Jawad Seddar via USRP-users wrote:

Hello all,

I am not sure if the following belongs on this list or on the
discuss-gnuradio list but here goes :

I have 2 USRP N210 (let's call them A and B) equipped with SBX
daughterboards and a GPSDO. Even though they both have a GPSDO, B gets its
references (clock and time) from A through a MIMO cable.

I use A and B to send the same signal and a third USRP (C) as a receiver to
observe what's happening. The signal sent by both A and B consists of GMSK
modulated packets (whith a fixed arrival period) sent on a carrier
frequency of around 1GHz. The samples forwarded to A and B are tagged for
each packet with a "tx_sob" and a "tx_time" tag at the beginning of the
packet and a "tx_eob" at the end of each packet.h

 This setup works quite well and I can see both signals from A and B added
together with a phase offset that is different for each execution. I can
compensate for this offset by rotating B's signal and thus I observe fully
constructive signals. Great results so far !!!

 :)

I do get some problems when I have some extra packets to send from A and
not from B. Then the packets sent from A and B do not add up constructively
anymore, in fact I observe a 180° phase shift after each non shared packet
(see attached images for illustration).

The attached images contain the following :
common.jpg : signal sent by both A and B
constructive.jpg : signal received by C when there is constructive
interference

A.jpg : signal sent by A including small packets every 4 common packets
phase_shit.jpg : signal received by C when A sends small packets and B does
not.
phase_shit2.jpg : Clearly shows the phase shift after each small packet

All signals shown are measured from C. You may notice some burst with large
amplitude (goes outside of the window) before each interesting burst, these
are not of any interest here. The tags displayed here are tags added by a
receiving block, not tags set by the transmitters.

I am not sure where these phase shifts come from. I have read things about
the CORDICs but it seemed to me that they should be aligned after each
start of burst, which are present for all packets along with a tx_time tag (<a class="moz-txt-link-freetext" href="http://files.ettus.com/manual/page_sync.html">http://files.ettus.com/manual/page_sync.html</a>).

Is there something I am missing here?

I am using UHD 3.8 and GNURadio 3.7.5

Thanks,
Jawad




_______________________________________________
USRP-users mailing <a class="moz-txt-link-abbreviated" href="mailto:listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com">listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a>



_______________________________________________
USRP-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:USRP-users@lists.ettus.com">USRP-users@lists.ettus.com</a>
<a class="moz-txt-link-freetext" href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a>


</pre>
      </blockquote>
      <pre wrap=""></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
USRP-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:USRP-users@lists.ettus.com">USRP-users@lists.ettus.com</a>
<a class="moz-txt-link-freetext" href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a>
</pre>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>USRP-users mailing list<br><a href="mailto:USRP-users@lists.ettus.com">USRP-users@lists.ettus.com</a><br>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com<br></blockquote></div><br></div></body></html>