discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] patch to extended oscope to enable dualchan and c


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] patch to extended oscope to enable dualchan and complex mode on basicRX and basicTX
Date: Sun, 28 Oct 2007 18:24:49 -0700
User-agent: Mutt/1.5.9i

On Mon, Oct 29, 2007 at 12:34:12AM +0100, Martin Dvh wrote:
> Eric Blossom wrote:
> > 
> > Can you please go ahead and commit your patch?
> Done,
> 
> I think this is an improvement but maybe it can still be improved further.
> The disadvantage of my current patch is that knowledge about daughterboards 
> and muxvalues is in the oscope script.
> It is always better to have this info/knowledge in one place, and one place 
> only.
> This would mean we would have to extend the code in gr-usrp.


> What do you think about the following possble setup:
> for basicRX and LFRX the subdev code could be extended the following way.
> subdevspec A:0
> use input A of daughteboard A as a real input   iscomplex() should return 
> False
> subdevspec A:1
> use input B of daughteboard A as a real input   iscomplex() should return 
> False
> subdevspec A
> use input A and B  of daughteboard A as a complex input   iscomplex() should 
> return True
> 
> (Note however this would change the API. At the moment you actually get A:0 
> when you specify A.
> We could also do something like A:real (which would be an alias for A:0) and 
> A:complex which would give a complex input using both inputs.

The Basic Rx and LF Rx are only boards that this matters with.
As you said A and A:0 and equivalent.  Perhaps we should extend the
syntax to support A:* or some such.

> It gets more complicated when you want to use multiple inputs as multiple 
> channels.
> You would want to be able to call usrp.determine_rx_mux_value() with multiple 
> subdev specs
> for example:
> usrp.determine_rx_mux_value(self.u, 
> (options.rx_subdev_spec0,options.rx_subdev_spec1))

Unless it's really transparent, and makes sense for most cases, I
think I'd want to leave it alone.  Part of problem is that for the
multichannel case, you start to get additional constraints when it
comses to frequency setting etc.  E.g., extracting two channels
from a single daughterboard vs extracting two channels from two
daughterboards.

If you can think of way to handle the entire mess in a way that makes
sense, and doesn't complicate the typical single channel case, I'm all
ears.

Eric




reply via email to

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