[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Unwanted relative phase change after programming

From: Josh Blum
Subject: Re: [Discuss-gnuradio] Unwanted relative phase change after programming a device
Date: Wed, 11 Jan 2012 18:28:04 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0

On 01/11/2012 03:56 PM, Armando Rocha wrote:
> Dear all
> I am using USRP1 with two basic RX daughter boards and two input signals
> (one at each Basic RX) with the same frequency.
> The two 10. 7 MHz signals cartesian components:
> - (I1, Q1) from one channel of the 1st Basic RX card
> - (I2, Q2) from the 2nd Basic Rx card
> are mixed with the NCO at about 10.7 MHz to almost DC, decimated and
> sent to PC.
> The PC software computes the received signal frequency, amplitudes and
> the relative phase that remains constant along the time if the NCO
> frequency is not changed.
> To compensate frequency drifts the NCO is periodically adjusted by
> reprogramming the two devices." using the tune function.
> After this reprogramming however the relative phase between the signals
> often (but not always) changes a lot (not always the same phase change).
> A detailed suggestion to solve this problem is appreciated as accurate
> phase measurement is important in my application (I can not find a clear
> response to this issue in the discussions).

The issue is setting the cordic frequency while streaming (in other
words, while the cordics are spinning), because you cannot set them
precisely at the same time. Therefore, one cordic will see more cycles
at the new frequency before the other gets set to the new frequency.

However, if you stop streaming, tune the cordics, and re-start
streaming, both cordics should remain phase aligned because the cordics
only spin while samples flow through them.

Another solution, if these frequency drifts keep the signal well within
the initial passband, don't retune the cordics, you can easily
compensate for the frequency drift in the host instead.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]