Re: [Discuss-gnuradio] The sinusiodal waveform is drifting from input to output.

[Tom Rondeau]

On Wed, Mar 3, 2010 at 1:06 PM, Johnathan Corgan
<address@hidden> wrote:
> On Wed, Mar 3, 2010 at 03:26, srinivas naga vutukuri
> <address@hidden> wrote:
>
>> I am transmitting the sinusoidal wave form (IQ samples), in the following
>> methods, and found that when i stem plot in the MATLAB both the input wave
>> form data on one USRP2 and the received data on another USRP2, initially the
>> waveform is exactly fitting (i mean overlapping), and after certain samples,
>> it starts ie., in the input wave form and the output data waveform drifting
>> slightly and at the end samples both the waveforms overlaps perfectly. Why
>> this slight drifting is happening when transmitting the I Q samples from one
>> USRP2 to another USRP2.
>
> This is almost certainly due to receiver frequency and timing drift
> between transmitter and receiver USRPs.  It's a fact of life in
> real-world radio systems, requiring significant design effort to
> compensate for; you're seeing exactly what you should expect to see.
>
> The digital demodulators in GNU Radio typically use DSP blocks like
> Costas loops for frequency/phase synchronization and Mueller&Mueller
> timing recovery blocks to track timing drift.
>
> Johnathan


A fun thing to do on the USRPs is to blow on the crystal while it's
transmitting. If you transmit a tone with usrp_siggen.py and receive
it using usrp_fft.py with a high decimation rate (so you're only
looking at a fairly small frequency window), you can see the effects
that temperature makes in the oscillator's operation. You should see
the tone in the FFT window swing left or right and the come back to
settle on a nominal frequency.

I haven't tried this with the USRP2, but it should work similarly
(since it's not a TCXO).  But the point I'm making is that oscillators
have real constraints and issues related to anything from physical
makeup to environmental conditions.

Tom