discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] byte-wide ADC transfers


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] byte-wide ADC transfers
Date: Sun, 19 Feb 2006 11:16:43 -0800
User-agent: Mutt/1.5.9i

On Sun, Feb 19, 2006 at 11:47:46AM -0500, Clark Pope wrote:
> 
> Please look at the *current* code.  You are misunderstanding what it's
> doing.  Both modes are capable of sending [ch0, ch7] across the bus.  The
> even channels are the I outputs of the DDCs, the odd channels are the
> Q outputs.
> 
> > I still haven't tracked down why the make_format isn't showing up either,
> > btw.
> 
> You do not have the current usrp code.  I can tell this from the
> verilog you posted.  Please updated usrp and gr-usrp from CVS.
> 
> Using that rbf file and this command (all from current CVS):
> 
>  $ ./usrp_fft.py -f 100.1M -8 -d 4
> 
> produced the attached screenshot.  Note that it is 16 MHz wide.
> I was using the TV_RX daughterboard, which contains an approximately
> 6 MHz wide SAW filter, hence there's not much outside of +/- 3 MHz.
> 
> Eric
> 
> 
> << fft-16MHz-wide.png >>
> 
> 
> Okay, I went and blew away gnuradio-core, usrp, and gr-usrp and reinstalled 
> from CVS. I WAS able to get the usrp_fft.py to do 16 Mhz wide by loading 
> the std_4rx_0tx.rbf file. However, it still doesn't know where make_format 
> is.

What is your PYTHONPATH?  I suspect you've got a stale install
somewhere on the path and that you are picking up at least part of
that.  I suggest removing all gnuradio stuff found anywhere on
PYTHONPATH and doing a "make install" again.

> Even in python if I:
> from gnuradio import usrp
> u=usrp.source_c(0,fpga_filename="std_4rx_0tx.rbf")
> u.make_format(8,8,true,false)
> 
> I get:
> AttributeError: 'usrp1_source_c_sptr' object has no attribute 'make_format'
> 
> At this point it doesn't matter because I can hard code the format, but I 
> just wanted to explain that:

There's a problem in your install.  Thinking that hardcoding
make_format is OK is just papering over a symptom of a bigger problem.

Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]