[USRP-users] Phase alignment

Marcus Müller marcus.mueller at ettus.com
Mon Dec 8 11:20:26 EST 2014

Hi Jawad,

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!

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:

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
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.

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".

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.


[1] https://github.com/EttusResearch/fpga/blob/master/usrp2/sdr_lib/duc.v

On 12/08/2014 04:09 PM, Jawad Seddar via USRP-users wrote:
> 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 <usrp-users at lists.ettus.com>:
>>  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 (http://files.ettus.com/manual/page_sync.html).
>> Is there something I am missing here?
>> I am using UHD 3.8 and GNURadio 3.7.5
>> Thanks,
>> Jawad
>> _______________________________________________
>> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> _______________________________________________
> USRP-users mailing list
> 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/20141208/0b457b78/attachment-0002.html>

More information about the USRP-users mailing list