[USRP-users] Phase alignment

Marcus Müller marcus.mueller at ettus.com
Mon Dec 8 09:04:42 EST 2014


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 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/4f934457/attachment-0002.html>


More information about the USRP-users mailing list