Forum: GNU Radio Single-tone test using USRP2 with RFX2400 and XCVR2450

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ba9db45a086952262010f650adf8bacd?d=identicon&s=25 Yongsang Kim (ysjr)
on 2009-04-24 05:30
Hi, all.

I did single-tone test using USRP2 with RFX2400 and XCVR2450.
There are some undesired signals in the results.

My single-tone test is as follows:
- Wired connection between USRP2 and Spectrum analyzer
- Single-tone is transmitted from USRP2 using the following commands
   ./usrp2_siggen.py -f xxxx
   ./usrp2_siggen.py -f xxxx -w xxxx
- For daughter board, RFX2400, XCVR2450 and Basic TX are tested
- Newest GNU radio and firmware
- PC specification (I'm pretty sure that the spec is good enough to
transmit single-tone stably)
   -- CPU: Intel core2quad processor Q9550
   -- Ethernet card: Intel 82567LM Gigabit LAN (PCI express slot)
   -- Memory: 4GB DDR2 800 MHz SDRAM memory

Except the case of Basic TX, there are some undesired signals in the
results.
So, I guess the undesired signals are generated by RFX2400 and XCVR2450,
not by mother board.
I'm afraid that the undesired signals cause some kind of distortion of
desired signal.
(In fact, when I transmit OFDM signal using XCVR2450, I fail to
demodulate the received OFDM signal)

The resulting spectrum figures are shown in the following link and I
marked
the undesired signals in the figures.


http://141.223.23.5/Spectrum.zip


Short descriptions for each figures are as follows:

1. File name: RFX2400_2p375GHz_01
   Used daughter board: RFX2400
   GNU radio command: ./usrp2_siggen.py -f 2.375e9

2. File name: RFX2400_2p375GHz_02
   Used daughter board: RFX2400
   GNU radio command: ./usrp2_siggen.py -f 2.375e9 -w 2M

3. File name: XCVR2450_2p52GHz_01
   Used daughter board: XCVR2450
   GNU radio command: ./usrp2_siggen.py -f 2.52e9

4. File name: XCVR2450_2p52GHz_02
   Used daughter board: XCVR2450
   GNU radio command: ./usrp2_siggen.py -f 2.52e9 -w 2M

5. File name: BasicTX_30MHz_01
   Used daughter board: Basic TX
   GNU radio command: ./usrp2_siggen.py -f 30e6

6. File name: BasicTX_30MHz_02
   Used daughter board: Basic TX
   GNU radio command: ./usrp2_siggen.py -f 30e6 -w 2M

I would appreciate that if somebody let me know what is problem of my
daughter boards or my test.
Thanks.
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2009-04-26 09:01
(Received via mailing list)
Yongsang Kim wrote:
> - For daughter board, RFX2400, XCVR2450 and Basic TX are tested
> not by mother board.
> I'm afraid that the undesired signals cause some kind of distortion of
> desired signal.
> (In fact, when I transmit OFDM signal using XCVR2450, I fail to
> demodulate the received OFDM signal)
>
> The resulting spectrum figures are shown in the following link and I
> marked
> the undesired signals in the figures.


What you are seeing are normal transmitter non-idealities, including DC
offset (aka carrier feedthrough), and IQ imbalance (aka sideband
suppression.  These can be improved through tuning, but they are not bad
as is.  Also, on the XCVR you are seeing the phase noise skirts as well.

Matt
3017a63dd5d902bdcf426915d07a21d4?d=identicon&s=25 Changkyu Seol (snow98)
on 2009-04-27 06:08
Matt Ettus wrote:
> Yongsang Kim wrote:
>
> What you are seeing are normal transmitter non-idealities, including DC
> offset (aka carrier feedthrough), and IQ imbalance (aka sideband
> suppression.  These can be improved through tuning, but they are not bad
> as is.  Also, on the XCVR you are seeing the phase noise skirts as well.
>
> Matt

With the XCVR2450 and USRP2, we also observed that the 2MHz (at
baseband) is
appearing at (f_c-2MHz) not (f_c+2MHz) where f_c is the center
frequency. It
seems that the complex conjugate of original baseband signal is
transmitted at
XCVR2450.

We verified this with OFDM signal which is demodulated
successfully when we flip the left and right of the FFT ouput before
processing (integer frequency offset compensation, channel estimation,
etc)
at the receiver.
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2009-04-27 21:52
(Received via mailing list)
Changkyu Seol wrote:
> With the XCVR2450 and USRP2, we also observed that the 2MHz (at
> etc)
> at the receiver.


Please update your firmware and try again.  I believe I have fixed this
problem now.

Matt
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-04-28 01:06
(Received via mailing list)
On Mon, Apr 27, 2009 at 12:50 PM, Matt Ettus <matt@ettus.com> wrote:

> Please update your firmware and try again.  I believe I have fixed this
> problem now.

The USRP2 firmware that contains this fix has been posted to:

http://gnuradio.org/releases/usrp2-bin/trunk/txrx_...

Johnathan
3017a63dd5d902bdcf426915d07a21d4?d=identicon&s=25 Changkyu Seol (snow98)
on 2009-04-28 05:38
Johnathan Corgan wrote:
>> Please update your firmware and try again. ?I believe I have fixed this
>> problem now.
>
> The USRP2 firmware that contains this fix has been posted to:
>
> http://gnuradio.org/releases/usrp2-bin/trunk/txrx_...
>
> Johnathan

Thank you very much for such quick update.
The flipping problem is resolved with updated firmware.

Changkyu Seol
45a1bbc742210950df5afa87895ff0ab?d=identicon&s=25 Igor Almeida (Guest)
on 2009-08-28 17:28
(Received via mailing list)
On Fri, Apr 24, 2009 at 12:30 AM, Yongsang Kim<lists@ruby-forum.com>
wrote:
> - For daughter board, RFX2400, XCVR2450 and Basic TX are tested
> - Newest GNU radio and firmware

I [believe I] am having a similar problem with USRP rev4 and RFX2400.
Sending a QAM-modulated signal in a 2.5GHz carrier with no
synchronization gives me a lot of background noise before the actual
signal. So I am prepending a 2MHz sine wave in a separate block,
executed prior to the QAM modulation, but I cannot find the impulses
in +- 2M after the receiving USRP downconverts it from 2.5GHz.
The part of the signal which is supposed to contain the 2M wave shows
both real and imaginary sinusoidal signals, always close to DC by 3k
Hz or so. Am I missing anything?

--
Igor Almeida
D9b2772a9387f5dbe010dbc0c3a93f8d?d=identicon&s=25 Douglas Geiger (Guest)
on 2009-08-28 18:04
(Received via mailing list)
On Fri, Aug 28, 2009 at 11:09 AM, Igor Almeida<igor.contato@gmail.com>
wrote:
>
> --
> Igor Almeida

That sounds like it could be a frequency offset between TX and RX. You
say you aren't synchronized (which I interpret to mean you don't lock
the clocks of the TX and RX together somehow) - do you have a costas
or similar carrier offset recovery block/process on your receiver?

--
Doug Geiger
doug.geiger@bioradiation.net
45a1bbc742210950df5afa87895ff0ab?d=identicon&s=25 Igor Almeida (Guest)
on 2009-08-28 19:10
(Received via mailing list)
On Fri, Aug 28, 2009 at 12:56 PM, Douglas
Geiger<doug.geiger@bioradiation.net> wrote:
> That sounds like it could be a frequency offset between TX and RX. You
> say you aren't synchronized (which I interpret to mean you don't lock
> the clocks of the TX and RX together somehow) - do you have a costas
> or similar carrier offset recovery block/process on your receiver?

Correct, the USRPs are physically disconnected.
Right now, the graphs are:

sig_source_f -> float_to_complex -> head -> usrp.sink_c

usrp.source_c -> file_sink (on the other PC)

TX usrp sends the first 1000 cycles of a 2MHz sine wave (sig_source
with 4MS/s), then the "training graph" is disconnected and another one
with the QAM modulator kicks in. Both scripts tune to 2.5G.
The strange thing is no matter what frequency I set the sig_source to
(already tried 1.5k, 2k, 1M and 2MHz, sampling frequency 4MS/s), the
fft on matlab always shows a single impulse at aproximately -3kHz. In
the time domain, the signal is sinusoidal on both real and imaginary
parts, when I expect it to be only real since the carrier has (should
have) been removed.

I believe I am missing some trivial concept here.

--
Igor Almeida
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-08-28 23:21
(Received via mailing list)
On Fri, Aug 28, 2009 at 02:05:02PM -0300, Igor Almeida wrote:
> sig_source_f -> float_to_complex -> head -> usrp.sink_c
If you're trying to send a sine wave, this will work much better:
(Generates a complex sinusoid == exp(jwt))

  sig_source_c -> head -> usrp.sink_c

Or you could use a hilbert transform to generate the quadrature
component.  float_to_complex will be setting Q to zero the way you're
using it.



> have) been removed.
>
> I believe I am missing some trivial concept here.

See above.

Eric
45a1bbc742210950df5afa87895ff0ab?d=identicon&s=25 Igor Almeida (Guest)
on 2009-08-28 23:27
(Received via mailing list)
On Fri, Aug 28, 2009 at 5:22 PM, Eric Blossom<eb@comsec.com> wrote:
> If you're trying to send a sine wave, this will work much better:
> (Generates a complex sinusoid == exp(jwt))
>
>  sig_source_c -> head -> usrp.sink_c
>
> Or you could use a hilbert transform to generate the quadrature
> component.  float_to_complex will be setting Q to zero the way you're
> using it.

Yes, setting Q to zero was the original idea. The whole point of using
a sine wave was to have a better estimation of when the QAM signal
actually started, but this "solution" gave me another problem to work
on :)
My question is why the received signal has sinusoidal components on
both I and Q given that the wave has been "translated" to 2.5G (upon
tx) and then back to DC (after the FPGA in rx). Should I not expect
two impulses at +- 2M? Instead, what I get is a single impulse at
aproximately -3kHz, regardless of the frequency set on the sig_source.

> Eric
>



--
Igor Almeida
This topic is locked and can not be replied to.