Hi all,
inspired by the question of George N. I extended the usrp_oscope.py
script to enable dualchannel and complex mode for basicRX and LFRX.
You can find a patch and the complete modified script at:
http://www.olifantasia.com/projects/gnuradio/mdvh/oscope_basicrx_dualchan/
You can copy the new script or apply the patch to your current
gr-utils/src/usrp_oscope.py.
The patch should apply cleanly if you have version 3.1 of gnuradio.
There are two new commandline options:
-C, --basic-complex Use both inputs of a basicRX or LFRX as a single
Complex input channel
-D, --basic-dualchan Use both inputs of a basicRX or LFRX as seperate
Real
input channels
With --basic-complex both inputs of a basicRX or LFRX are enabled to
form a single complex channel (I=input A, Q=input B)
With --basic-dualchan both inputs are treated seperately and so you get
two input real channels. (I1=input A, Q1=0, I2=input B, Q2=0)
The difference between the two options becomes clear when you set a
nonzero frequency.
With the dualchannel option you can set the frequence for each channel
seperately.
With the complex option you can set only one frequency. If you set this
to nonzero, this is only usefull if you actually have an I and Q signal
connected to both inputs.
Greetings,
Martin
Below is the original question which inspired m to write this
modification.
On Fri, Oct 26, 2007 at 07:14:48PM +0200, Martin D. wrote:
There are two new commandline options:
With the complex option you can set only one frequency. If you set this to nonzero, this is only usefull if you actually have an I and Q signal
connected to both inputs.
Greetings,
Martin
Thanks Martin!
Can you please go ahead and commit your patch?
Eric
Eric B. wrote:
On Fri, Oct 26, 2007 at 07:14:48PM +0200, Martin D. wrote:
Hi all,
inspired by the question of George N. I extended the usrp_oscope.py script to enable dualchannel and complex mode for basicRX and LFRX.
Thanks from me too! I appreciate it, and based on my question… can
obviously put it to use 
Eric B. wrote:
With the dualchannel option you can set the frequence for each channel seperately.
With the complex option you can set only one frequency. If you set this to nonzero, this is only usefull if you actually have an I and Q signal
connected to both inputs.
Greetings,
Martin
Thanks Martin!
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.
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))
What do you think?
Martin
On Mon, Oct 29, 2007 at 12:34:12AM +0100, Martin D. wrote:
Eric B. 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.
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