discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] help with USRP syntax


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] help with USRP syntax
Date: Sun, 7 Jan 2007 01:52:49 -0800
User-agent: Mutt/1.5.9i

On Sun, Jan 07, 2007 at 03:13:28AM -0500, Josh Blum wrote:
> Greetings. I am trying to understand the usrp programming syntax so that 
> I can add USRP support into GRC.

What's "GRC"?

> Below are a few code snippets from the 
> USRP sample codes. It seems that rx_subdev_spec can be a tuple (0, 0) or 
> (1, 0). Would this mean that for tx modules, the tx_subdev_spec is (1, 
> 1) or (0, 1)? Each tuple corresponds to one of the 4 USRP module-sockets? 

I recommend that you just treat the subdev as an opaque type that is
created by code that knows how to parse a subdev spec on the command
line, and which is passed to other code that knows how to interpret
it.

>From the command line you specify either -R A, -R B or in rare (nearly
non-existent cases) -R A:0, -R A:1, -R B:0, -R B:1.  Same story for
the -T transmit options.  The <foo>:1 case allows you to specify the
second subdevice on a daughterboard.  The only the daughterboards that
supports a second subdevice are the Basic Rx and LF_RX.  The <foo>:0
option selects one input, <foo>:1 the other.


As currently implemented (no promises that any of this stays the same,
and thus my exhortation to treat this as an opaque type), the tuple is
interpreted as (<side>, <subdevice>), where A -> 0 and B -> 1.

> I noticed that the last 3 of my examples set a mux, and use subdev. 
> However, the first example is wildly different (I assume the command are 
> different for different modules?). Is there some way I can find out what 
> type of commands I need to use for various USRP modules?

If you use the recommended approach (use subdev), all daughterboards
are treated identically.

> The commands involving the subdev are used to set the gain (obviously), 
> but sometimes you also have to call subdev.set_enable(True)?

set_enable(True) enables the transmitter on the daugtherboards.  Not
all boards support this option.  On those boards that don't, the Tx
path is always "hot".  The other option is to enable the "Auto T/R
switching", using set_auto_tr(True/False).


> Sorry for potentially stupid questions. I am not too familiar with the 
> USRP, and I would like some advice.
> 
> Thank you, -Josh
> 
> TX

Don't call set_pga, set_tx_freq or set_rx_freq.  These examples are
obsolete, and were written before the generalized code for handling
daughterboards.


> u = usrp.sink_c (0, self.usrp_interp)
> 
> u.set_tx_freq (0, options.cordic_freq)
> 
> u.set_pga (0, options.gain)
> 
> u.set_pga (1, options.gain)
> 


This is the preferred style:

> TX

> self.u = usrp.sink_c ()       # the USRP sink (consumes samples)
> 
> options.tx_subdev_spec = usrp.pick_tx_subdevice(self.u)
> 
> m = usrp.determine_tx_mux_value(self.u, options.tx_subdev_spec)
> 
> self.u.set_mux(m)
> 
> self.subdev = usrp.selected_subdev(self.u, options.tx_subdev_spec)
> 
> self.subdev.set_gain(self.subdev.gain_range()[1])    # set max Tx gain
> 
> self.subdev.set_enable(True)                         # enable transmitter


These are also good:

> RX
> 
> self.u = usrp.source_c()                    # usrp is data source
> 
> self.u.set_decim_rate(usrp_decim)
> 
> self.u.set_mux(usrp.determine_rx_mux_value(self.u, options.rx_subdev_spec))
> 
> self.subdev = usrp.selected_subdev(self.u, options.rx_subdev_spec)
> 
> RX
> 
> u = usrp.source_c(USRP_number, decimation)
> 
> u.set_mux(usrp.determine_rx_mux_value(u, options.rx_subdev_spec))
> 
> subdev = usrp.selected_subdev(u, options.rx_subdev_spec)
> 
> u.tune(USRP_number, subdev, frequency)   # First argument is which digital 
> downconverter, 
                                           # not USRP_number.  It should be 0 
in most cases
> 
> subdev.set_gain(gain)


I hope this helped.  Ask again if you've got more questions.

Eric




reply via email to

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