[USRP-users] Phase alignment

Ian Buckley ianb at ionconcepts.com
Mon Dec 8 13:35:16 EST 2014


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.
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.
Alternatively you could transmit continuously with both USRP's but send digital silence when idle so that CORDIC phase remains locked between the units.
-Ian

On Dec 8, 2014, at 8:20 AM, Marcus Müller via USRP-users <usrp-users at lists.ettus.com> wrote:

> 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.
> 
> Greetings,
> Marcus
> 
> [1] https://github.com/EttusResearch/fpga/blob/master/usrp2/sdr_lib/duc.v
> [2] https://github.com/EttusResearch/fpga/blob/master/usrp2/sdr_lib/duc_chain.v
> [3] https://github.com/EttusResearch/fpga/blob/master/usrp2/top/N2x0/u2plus_core.v#L727
> 
> 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
> 
> _______________________________________________
> 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/ff0894ec/attachment-0002.html>


More information about the USRP-users mailing list