Forum: GNU Radio USRP2 missing Quadrature samples

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.
8ec0c8ec21f960a56ab17880f309b572?d=identicon&s=25 Leslie Choong (Guest)
on 2009-01-30 20:31
(Received via mailing list)
Hi Everyone, I've been working with Thomas Schmid's old 802.1.54
demodulation code. I've got it running well on the original USRP and
have been trying to get the code to work with the USRP2. I basically
just changed out the source block and yet could not properly
demodulate a packet.

To investigate I used gr-utils/src/python/usrp2_rx_cfile.py to capture
incoming data and then plotted it using gr_plot_fft.py. I noticed 2
things:
1. The first block of data read by the plotter seems to always display
a strange dead signal, but all the other blocks have some In-phase
data.
2. More importantly, I am not seeing any quadrature component in the
IQ-plot (besides the noise at the beginning).

I compared this to data from the USRP using usrp_rx_cfile.py and
gr_plot_fft.py and am able to see IQ data.

Is there a reason for this? A hardware issue? or a Setup issue? I am
using the SVN revision 10306.

I've posted the plots here:
http://www.cs.ucla.edu/~septikus/usrp.html

Thanks for any help you can provide!
-Leslie
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2009-01-30 21:15
(Received via mailing list)
Leslie Choong wrote:
> a strange dead signal, but all the other blocks have some In-phase
> I've posted the plots here:
> http://www.cs.ucla.edu/~septikus/usrp.html


Leslie,

I can't replicate this here.  Are those zero points all exactly zero, or
just very small in comparison to the I channel?

Also, which versions of the FPGA and firmware are you using on the SD
card?

Matt
8ec0c8ec21f960a56ab17880f309b572?d=identicon&s=25 Leslie Choong (Guest)
on 2009-01-31 16:17
(Received via mailing list)
Thanks for the replies.

I have checked the Quadrature values and they are indeed 0.0

I had already followed the steps to flash the SD card (using the one
that came with the USRP2) and used the firmware (txrx.bin) that
gnuradio (rev 10306) produced using make. I used the latest
u2_rev3.bin (dated Dec 31) that is sitting in
http://gnuradio.org/releases/usrp2-bin/trunk/

Just to check I redid the whole process of flashing and retried my
tests and had the same results.

Should I suspect my svn revision and update to the latest? I'll try
that for now, but if anyone has suggestions I'm all ears :) Thanks for
the help so far!

-Leslie
8ec0c8ec21f960a56ab17880f309b572?d=identicon&s=25 Leslie Choong (Guest)
on 2009-01-31 18:27
(Received via mailing list)
So I've pulled down the most recent trunk and re-built gnuradio. One
thing I noticed that I forgot about was that running make in
gnuradio/usrp2 does not produce a txrx.bin under usrp2/firmware/apps.
I must have copied the latest one sitting in the trunk which is dated
Dec 31st (same date as the FPGA binary blob).

I looked into it and it seems like ./configure did not find mb-gcc
(the microblaze toolchain). I installed the pre-compiled binary from
instructions here:
http://gnuradio.org/trac/wiki/USRP2UserFAQ

And then after configuring and running make I get this error:
make[3]: Entering directory `/home/leslie/gnuradio/usrp2/firmware/lib'
if gcc -DHAVE_CONFIG_H -I. -I. -I..  -DHAL_IO_USES_UART  -I../include
-I../lib  --std=gnu99 -Wall -Werror-implicit-function-declaration
-mxl-soft-div -msoft-float -mxl-soft-mul -mxl-barrel-shift -g -O2 -MT
abort.o -MD -MP -MF ".deps/abort.Tpo" -c -o abort.o abort.c; \
  then mv -f ".deps/abort.Tpo" ".deps/abort.Po"; else rm -f
".deps/abort.Tpo"; exit 1; fi
cc1: error: unrecognized command line option "-mxl-soft-div"
cc1: error: unrecognized command line option "-mxl-soft-mul"
cc1: error: unrecognized command line option "-mxl-barrel-shift"
make[3]: *** [abort.o] Error 1

I'm still looking into what these errors could mean. Perhaps this is
the problem mentioned in the wiki about using gcc 4.3 with the
microblaze toolchain? This is all on Ubuntu 8.10, which is gcc 4.3.2 I
believe.

Does it make a difference that I'm using the pre-built txrx.bin? From
reading through the list as long as I use the trunk binaries, they
should work with the latest version of GNURadio.

Or could this be a hardware issue? I've tried reseating the
daughterboard as well. I'll be testing out on a second USRP2 next week
to see if one of the ADCs (or that path to it) is broken.

In the meantime, any comments or suggestions are very welcome. Thanks
for the help!
-Leslie
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-01-31 18:44
(Received via mailing list)
On Fri, Jan 30, 2009 at 04:24:55PM -0800, Leslie Choong wrote:
>
> cc1: error: unrecognized command line option "-mxl-barrel-shift"
> make[3]: *** [abort.o] Error 1

Run ./configure from top directory.  Otherwise you get gcc instead of
mb-gcc.

Eric
8ec0c8ec21f960a56ab17880f309b572?d=identicon&s=25 Leslie Choong (Guest)
on 2009-02-04 01:51
(Received via mailing list)
I was able to compile the firmware with Eric's suggestion but it made
no difference on the performance. I tested this out on another USRP2
to see if it was a hardware issue but again got the same results.

I noticed something interesting though: Using a RFX 2400 board if I
try to tune to 2.45G (my original freq), 2.4G or 2.5G I get similar
behaviour (Q samples are 0). If I tune away from them I start to
receive Q samples!

I sampled at 2.425G and compared it to the USRP1. I noticed 2 things:
1. The IQ samples at 2.425G seem like complete noise compared to the
USRP1 samples.
2. The Amplitude of the USRP2 IQ samples is much lower than the USRP1

I have posted these results at:
http://www.cs.ucla.edu/~septikus/usrp2.html

Am I setting something up wrong? Why are the IQ samples I'm getting
just noise? This is using my own compiled firmware and the latest FPGA
image off the GNURadio website.

Any further help or comments would be great! Thanks again for all your
help!
-Leslie
8ec0c8ec21f960a56ab17880f309b572?d=identicon&s=25 Leslie Choong (Guest)
on 2009-02-05 19:32
(Received via mailing list)
I'm baffled. I formatted the SD card and made sure the USRP2 didn't
boot up (No LEDs lit). Then reflashed it with the latest firmware and
FPGA image (2 LEDs lit). I still see 0.0 Q samples at 2.4G, 2.45G etc.
I've tried swapping the RFX 2400 daughterboard with a spare AND two
with different USRP2's and still see the same behaviour. I've done
this with the latest trunk of GNURadio (revision 10392).

Are the samples I'm seeing at 2.425G even valid? I'm mainly concerned
with the output range of +/- 2mV. Are others seeing this output range
for their USRP2's?

Thanks for reading and all the help!
-Leslie
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-02-05 20:03
(Received via mailing list)
On Wed, 2009-02-04 at 17:24 -0800, Leslie Choong wrote:

> I'm baffled. I formatted the SD card and made sure the USRP2 didn't
> boot up (No LEDs lit). Then reflashed it with the latest firmware and
> FPGA image (2 LEDs lit). I still see 0.0 Q samples at 2.4G, 2.45G etc.
> I've tried swapping the RFX 2400 daughterboard with a spare AND two
> with different USRP2's and still see the same behaviour. I've done
> this with the latest trunk of GNURadio (revision 10392).

Can you run:

usrp2_rx_cfile.py -f 2.45G -d 16 -g 30 -N 1M -v rx.dat

...and email me directly the rx.dat file?

Also, try the same at 2.4G and 2.5G, and email me those.

Finally, please capture the output of the scripts, that is, something
that looks like:

$ usrp2_rx_cfile.py -f 2.45G -d 16 -g 30 -N 1M rx.dat -v
Network interface: eth0
USRP2 address: 00:50:c2:85:30:40
Using RX d'board id 0x0027
Rx gain: 30.0
Rx baseband frequency: 2.45G
Rx DDC frequency: 0
Rx residual frequency: 0
Rx decimation rate: 16
Rx sample rate: 6.25M
Receving 1M samples
Writing 32-bit complex floats
Output filename: rx.dat
$

Thanks,

Johnathan
8ec0c8ec21f960a56ab17880f309b572?d=identicon&s=25 Leslie Choong (Guest)
on 2009-02-06 11:27
(Received via mailing list)
Thanks to Johnathan's help it seems my problem is with the USRP2's
recognition of the daughterboard. I used a USRP1 Rev 4.1 to flash my
FLEX 2400 to the rfx2400 EEPROM using this command:
./burn-db-eeprom -A -t rfx2400 --force

Which worked fine:
TX_A: OK
RX_A: OK

Then I plugged in the board into my USRP2 and still receive this
output when I run:
./usrp2_rx_cfile.py -f 2.425G -N 1M -v outusrp2

Output:
usrp2: failed to enable realtime scheduling
Using mid-point gain of 0.0 ( 0.0 - 0.0 )
Network interface: eth0
USRP2 address: 00:50:c2:85:30:37
Using RX d'board id 0x0001
Rx gain: 0.0
Rx baseband frequency: 0
Rx DDC frequency: -25M
Rx residual frequency: 0
Rx decimation rate: 16
Rx sample rate: 6.25M
Receving 1M samples
Writing 32-bit complex floats
Output filename: outusrp2

This is the same output as before. I can use this daughterboard with
the USRP1 with no problem. Using the USRP1 with usrp_rx_cfile.py:
Using RX d'board A: Flex 2400 Rx

So it seems like the USRP2 is having problems identifying the
daughterboard properly. I found a thread that discusses this, but
found no resolution:
http://lists.gnu.org/archive/html/discuss-gnuradio...

Any insight as to why this is happening with the USRP2? This is with
the latest firmware and FPGA image. Perhaps some hardware jumpers?
Thanks once again for the help!
-Leslie

On Wed, Feb 4, 2009 at 6:32 PM, Johnathan Corgan
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2009-02-06 11:56
(Received via mailing list)
Leslie,

Are you using the latest svn version on the host computer as well?  Have
you modified any files?

Matt
8ec0c8ec21f960a56ab17880f309b572?d=identicon&s=25 Leslie Choong (Guest)
on 2009-02-06 12:00
(Received via mailing list)
Hi Matt, I am using the latest SVN trunk as of yesterday (Revision
10392) and have not modified any files. This is on Ubuntu 8.10 on a
Macbook.
-Leslie
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2009-02-06 13:34
(Received via mailing list)
Leslie Choong wrote:
> Thanks to Johnathan's help it seems my problem is with the USRP2's
> recognition of the daughterboard. I used a USRP1 Rev 4.1 to flash my
> FLEX 2400 to the rfx2400 EEPROM using this command:
> ./burn-db-eeprom -A -t rfx2400 --force
>

You need to use the following:

./burn-db-eeprom -A -t rfx2400_mimo_b --force


Note the "_mimo_b".  What has been happening is that your board was
identifying as a plain rfx2400, and the USRP2 doesn't support the plain
version, so it defaults to treating it like a BasicRX.

Matt
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2009-02-06 13:38
(Received via mailing list)
Leslie Choong wrote:
> Thanks to Johnathan's help it seems my problem is with the USRP2's
> recognition of the daughterboard. I used a USRP1 Rev 4.1 to flash my
> FLEX 2400 to the rfx2400 EEPROM using this command:
> ./burn-db-eeprom -A -t rfx2400 --force
>

Also, are X1 and X101 populated on your RFX2400?  If so, you have a very
old non-MIMO_B version, which is probably why you saw this problem in
the first place.  If so, you will need to follow the directions here:

  http://gnuradio.org/trac/wiki/USRPClockingNotes

Look under Flex2400.

Matt
8ec0c8ec21f960a56ab17880f309b572?d=identicon&s=25 Leslie Choong (Guest)
on 2009-02-06 15:10
(Received via mailing list)
Huzzah! It works! I did have the older Flex 2400 daughtercard so I
moved the resistors around and re burned  it. It now works great.
Thanks to everyone who helped out, especially Matt and Jonathan!
-Leslie
E16be4811324adf8f26be26d77e9d29d?d=identicon&s=25 Bob McGwier (Guest)
on 2009-02-06 20:31
(Received via mailing list)
AHA!!

(sheepish grin on face wondering why signals looked real .... because
they are)


Bob


Leslie Choong wrote:
>>> ./burn-db-eeprom -A -t rfx2400 --force
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.
This topic is locked and can not be replied to.