Found problem with std_4rx_0tx.rbf

Hi,

There’s a problem with the std_4rx_0tx.rbf in the latest release. This
problem did not exist in 3.0.

Please see the attached image. All four inputs should look exactly the
same, but there is something wrong with input 0. It could be that the
imaginary part of the input 0 signal is getting suppressed. I don’t
know.

Here’s what I did: I have a brand new usrp with two basic rx boards. I
connected a signal generator to a four way splitter and then connected
the
four way splitter directly to the four usrp inputs. The signal
generator
was set to 480khz at -17 dbm. Then I executed “multi_fft.py -d 100 -f
500000 -g 0”. The attached screen shot shows the problem with input 0.
If
I move the signal generator to 520khz, the reflection moves to the other
side of zero freq. If I swap cables on input 0 and input 1, the problem
stays with input 0.

Thanks for your help,
Hans

On Tue, Oct 23, 2007 at 05:16:14PM -0700, Hans G. wrote:

connected a signal generator to a four way splitter and then connected the
four way splitter directly to the four usrp inputs. The signal generator
was set to 480khz at -17 dbm. Then I executed “multi_fft.py -d 100 -f
500000 -g 0”. The attached screen shot shows the problem with input 0. If
I move the signal generator to 520khz, the reflection moves to the other
side of zero freq. If I swap cables on input 0 and input 1, the problem
stays with input 0.

Thanks for your help,
Hans

Is it reporting any overruns? I.e., uOuOuOuOuOuOuOuO…

Eric

Yes

----- Original Message -----
From: “Eric B.” [email protected]
To: “Hans G.” [email protected]
Cc: [email protected]
Sent: Tuesday, October 23, 2007 5:37 PM
Subject: Re: [Discuss-gnuradio] found problem with std_4rx_0tx.rbf

On Tue, Oct 23, 2007 at 05:45:02PM -0700, Hans G. wrote:

Yes

If it’s reporting overruns then all bets are off.

multi_fft.py implements applies a channel filter to each stream.
Try turning it off. It should be possible from the command line, but
isn’t. Change:

    parser.add_option("-F", "--filter", action="store_true", 

default=True,
help=“Enable channel filter”)

to

    parser.add_option("-F", "--filter", action="store_true", 

default=False,
help=“Enable channel filter”)

Eric

On Wed, Oct 24, 2007 at 08:57:11AM -0700, Hans G. wrote:

Hans
I can reproduce it. There’s definitely something off with
std_4rx_0tx.rbf.
I’ve opened ticket:195 http://gnuradio.org/trac/ticket/195

[This is all I’m going to do about this right now.]

Eric

Eric B. wrote:

I can reproduce it. There’s definitely something off with std_4rx_0tx.rbf.
I’ve opened ticket:195 http://gnuradio.org/trac/ticket/195

[This is all I’m going to do about this right now.]

Since that RBF has only been re-synthesized a couple of times in the
last year or so, it would be straightforward to manually replace the
file with the versions from 3.0 series, and see where the problem
started. I think there will be at most 4 versions to test. You
wouldn’t need to change the host code any, just get the proper RBF from
the repository and manually install into $prefix/share/usrp/rev2 and 4.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

Eric, thanks for your attention.

If anyone fixes this bug, or has a work-around, please let me know.

Thanks,
Hans

----- Original Message -----
From: “Eric B.” [email protected]
To: “Hans G.” [email protected]
Cc: [email protected]
Sent: Wednesday, October 24, 2007 10:50 AM
Subject: Re: [Discuss-gnuradio] found problem with std_4rx_0tx.rbf

Hi,

Without the filter it still has the same behavior. Also, I’m going to
try
this on my faster computer that doesn’t have usrp overruns. Right now
it
only has Ubuntu server, so I’m downloading the installer for Ubuntu
Desktop
so I can run the spectrum display.

I wonder if anyone on the list has been able to reproduce this problem.

Thanks for your help,
Hans

----- Original Message -----
From: “Eric B.” [email protected]
To: “Hans G.” [email protected]
Cc: [email protected]
Sent: Tuesday, October 23, 2007 6:37 PM
Subject: Re: [Discuss-gnuradio] found problem with std_4rx_0tx.rbf

Hi All,

I have just had and attempt at building and installing the latest GNU
radio
stable release on Gentoo Linux. It has all been pretty easy.

Got the source from SVN.

Emerged all the correct packages.

$ emerge swig fttw cppunit boost alsa-lib sdcc guile wxpython xmlto
numpy

Then did the normal build.

$ ./bootstrap
$ ./configure --exec-path=/usr/
$ make
$ make check
$ make install

Make check passed all tests. (Easy peasy hey :wink:

The problem I now have, is when I try running any of the examples or
usrp
.py scripts I get “ImportError: No module named gnuradio”.

How do I get python to find the gnuradio module?

Additionally what scripts can I run to check gnuradio is working without
a
USRP attached?

Thanks,

Simon.

Ok, I found that the bug was introduced into std_4rx_0tx.rbf at version
4848. Version 4287 does not have the problem.

Hans

----- Original Message -----
From: “Johnathan C.” [email protected]
To: “Eric B.” [email protected]
Cc: “Hans G.” [email protected]; [email protected]
Sent: Wednesday, October 24, 2007 10:57 AM
Subject: Re: [Discuss-gnuradio] found problem with std_4rx_0tx.rbf

Hi Simon,

Make check passed all tests. (Easy peasy hey :wink:

The problem I now have, is when I try running any of the examples or usrp
.py scripts I get “ImportError: No module named gnuradio”.

How do I get python to find the gnuradio module?

There are two ways to go about this in Gentoo. The main problem is that
python in Gentoo’s portage installs/looks for modules in /usr/ whereas
other distributions and GNU Radio install and look in /usr/local by
default.

The first solution is to add a path to your python environment to point
to the newly installed python modules in /usr/local/.

The second method, which I found is much easier and helps stay
consistent when I used to run Gentoo, is to change the prefix on
configure:
./configure --prefix=/usr/

I think you’re on this track as you specified --exec-prefix… just also
specify a --prefix.

  • George

Simon Alford wrote:

$ ./bootstrap
$ ./configure --exec-path=/usr/
$ make
$ make check
$ make install

Make check passed all tests. (Easy peasy hey :wink:

It would be useful to document your efforts on our Wiki at:

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

Use account name ‘guest’, password ‘gnuradio’.

The problem I now have, is when I try running any of the examples or usrp
.py scripts I get “ImportError: No module named gnuradio”.

How do I get python to find the gnuradio module?

I’m not all that familiar with Gentoo, but three things have to happen
post install for USRP applications to work:

  • The shared library loader needs to be able to find GNU Radio .so
    files. This may be as easy as re-running ldconfig, or you might have to
    add something to /etc/ld.so.conf

  • Python needs to know about the GNU Radio install. The files will get
    put into $prefix/lib/pythonX.X/site-packages/gnuradio, which is
    typically already a place Python knows about, but you might have to set
    PYTHONPATH to include that directory up to but not including the
    ‘gnuradio’ part. ($prefix is typically /usr/local)

  • The USRP device file needs to have permissions altered for someone
    besides root to be able to write to it. If Gentoo uses udev then there
    is a configuration directory under /etc you can drop a file into that
    does this (see the UbuntuInstall wiki page as an example). Typically we
    create a group called ‘usrp’, give the device file root.usrp ownership,
    and 660 permissions. Then just add users to group ‘usrp’ as needed.

Additionally what scripts can I run to check gnuradio is working without a
USRP attached?

The best method is to run the ‘make check’ command from the top-level
source directory. This runs through hundreds of unit tests on various
parts of the tree. But you’ve already done that.

In $prefix/share/gnuradio/examples/* you’ll see a number of installed
example programs. Under ‘audio’ there is dial_tone.py, a simple tone
generator that will test your audio output as well.

More complicated are the ‘digital’ examples. You can run
‘benchmark_loopback.py’ without a USRP and it will exercise a lot of the
tree.

Let us know how it works out.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

Hi again,

I have now got a working gnuradio install on Gentoo Linux. George’s
suggestion of adding --prefix=/usr/ to the ./configure command worked.

I think all is working now, will test a USRP with it soon. I have run
the
benchmark_loopback.py and it produces many lines of output like this:

ok = True pktno = 631 n_rcvd = 632 n_right = 632

Which I assume is the script working. 50% of the time when I run the
script
it completes without an error. The rest of the time it exits with an
exception, although the script looks like it completes its output before
the
exception. The exception I get is:

Exception in thread Thread-1 (most likely raised during interpreter
shutdown):
Traceback (most recent call last):
File “/usr/lib64/python2.5/threading.py”, line 460, in __bootstrap
File “/usr//lib64/python2.5/site-packages/gnuradio/blks2impl/pkt.py”,
line
162, in run
<type ‘exceptions.AttributeError’>: ‘NoneType’ object has no attribute
‘unmake_packet’
Unhandled exception in thread started by
Error in sys.excepthook:

Original exception was:

Is this a problem that I will need to fix before I start using gnuradio
with
the USRP or can I safely ignore it for now?

Thanks

Simon.

Hans G. wrote:

Ok, I found that the bug was introduced into std_4rx_0tx.rbf at version
4848. Version 4287 does not have the problem.

The changes in changeset 4713 looked suspicious.
"Refactored FPGA *.vh files. Moved common pieces to toplevel/include. "
But I couldn’t find any obvisous mistakes there.

Then I generated a complete diff between r 4287 and 4848 the following
way:
$ cd usrp
$ svn diff -r 4287:4848

But I didn’t find any mistakes there even.
It is also possible that something went wrong when generating
std_4rx_0tx.rbf.
Has anybody tried rebuilding it (with Quartus II) with the current trunk
code (r 4848 or later)

When looking further into the code for the RX_chain I did find a few
(unrelated) bugs in
usrp/fpga/sdr_lib/rx_chain.v
When the NCO is turned off (RX_NCO_ON is not defined)
then sample_strobe is assigned to 1
However sample_strobe is an input, so this will fail.

The same mistake is made for decimator_strobe when the CIC is turned
off.

It can be solved by adding wires for sample_strobe_internal and
decimator_strobe_internal and assigning to that in stead.

This probably hasn’t surfaced because at the moment NCO and CIC are
always enabled.
see lines 31,32, 64 and 74 below.

usrp/fpga/sdr_lib/rx_chain.v
31 input sample_strobe,
32 input decimator_strobe,

51 ifdef RX_NCO_ON 52 phase_acc #(FREQADDR,PHASEADDR,32) rx_phase_acc 53 (.clk(clock),.reset(reset),.enable(enable), 54 .serial_addr(serial_addr),.serial_data(serial_data),.serial_strobe(serial_strobe), 55 .strobe(sample_strobe),.phase(phase) ); 56 57 cordic rx_cordic 58 ( .clock(clock),.reset(reset),.enable(enable), 59 .xi(i_in),.yi(q_in),.zi(phase[31:16]), 60 .xo(bb_i),.yo(bb_q),.zo() ); 61else
62 assign bb_i = i_in;
63 assign bb_q = q_in;
64 assign sample_strobe = 1;
65 endif // !ifdef RX_NCO_ON
66
67 ifdef RX_CIC_ON 68 cic_decim cic_decim_i_0 69 ( .clock(clock),.reset(reset),.enable(enable), 70 .rate(decim_rate),.strobe_in(sample_strobe),.strobe_out(decimator_strobe), 71 .signal_in(bb_i),.signal_out(hb_in_i) ); 72else
73 assign hb_in_i = bb_i;
74 assign decimator_strobe = sample_strobe;
75 `endif

Greetings,
Martin

On Fri, Oct 26, 2007 at 09:35:14AM +0100, Simon Alford wrote:

Which I assume is the script working. 50% of the time when I run the script
<type ‘exceptions.AttributeError’>: ‘NoneType’ object has no attribute
‘unmake_packet’
Unhandled exception in thread started by
Error in sys.excepthook:

Original exception was:

Is this a problem that I will need to fix before I start using gnuradio with
the USRP or can I safely ignore it for now?

It’s OK to ignore it.

Eric

Hello Simon!

I have a small request to you:

Please do not create new topic just with replying to an existing
mail/posting. The mail refers to the old one and some mailclients use
this referrers to thread mails. Just replying to create a new mail lets
your mail end up in the tread, that has nothing to do with your Gentoo
issue.

In this very case I have a mixed up thread with discussions about a FPGA
bitstream and Gentoo Linux.

In short: If you have a new topic, please create a new mail.

Thank you!

Patrick

Engineers motto: cheap, good, fast: choose any two
Patrick S.
Student of Telematik, Techn. University Graz, Austria