Hi Everyone, I’ve been working with Thomas S.'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:
- 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.
- 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
Leslie C. 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
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
On Fri, Jan 30, 2009 at 04:24:55PM -0800, Leslie C. 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
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
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:
- The IQ samples at 2.425G seem like complete noise compared to the
USRP1 samples.
- 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
On Wed, 2009-02-04 at 17:24 -0800, Leslie C. 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
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/2008-12/msg00155.html
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 C.
Leslie,
Are you using the latest svn version on the host computer as well? Have
you modified any files?
Matt
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
Leslie C. 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
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
Leslie C. 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
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
AHA!!
(sheepish grin on face wondering why signals looked real … because
they are)
Bob
Leslie C. wrote:
./burn-db-eeprom -A -t rfx2400 --force
Discuss-gnuradio mailing list
[email protected]
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.