Hi,
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.
1st method:
I used, tx_samples.cc and receive_streaming_samples.cc.
2nd method:
Using the GRC, created a signal source, and file sink and usrp2 sink
on One PC and another PC usrp2 source and file source. So plotting both
the input stored samples and output received samples, observed the above
mentioned drift of mismatch of samples of the waveform and again at the
end and start it perfectly matches or overlaps.
Kindly help me in understanding this phenomena, why this is happening on
raw data (IQ) samples sending. But this never happens, when i checked
with the benchmark_rx.py and benchmark_tx.py used (as internally these
two are using GMSK modulation, sync work and packets framing method).
best regards,
srinivas.
srinivas naga vutukuri wrote:
end and start it perfectly matches or overlaps.
Kindly help me in understanding this phenomena, why this is happening on
raw data (IQ) samples sending. But this never happens, when i checked
with the benchmark_rx.py and benchmark_tx.py used (as internally these
two are using GMSK modulation, sync work and packets framing method).
Is it possible that this is due to a phase/frequency- drift between the
two units? I think benchmark_rx implements a PLL (Costas- loop) for
frequency/phase- offsets, and might (don’t remember) as well implement a
form of early- late- gate loop (Optimized Müller & Müller algorithm) for
time- synchronizing the samples.
I don’t know if the phenomena you see is due to this, but it might…
BR
//Mattias
I mean drift, slight shift in the both the input and output receive
waveforms.
best regards,
srinivas.
On Wed, Mar 3, 2010 at 03:26, srinivas naga vutukuri
[email protected] 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
On Wed, Mar 3, 2010 at 1:06 PM, Johnathan C.
[email protected] wrote:
USRP2 to another USRP2.
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
On Thu, Mar 4, 2010 at 06:59, Tom R. [email protected]
wrote:
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.
One of the demos in my GNU Radio training course during the
bit-error-rate testing lab is to spray the transmitter crystal with
Duster or other cold spray. The BERT receiver continuously displays
the calculated frequency and timing offset, so the transient becomes
very obvious, yet the carrier and symbol timing loops deal with it
just fine.
Johnathan