Correct idiom for frequency-setting when you don't have a tu

GNU Radio
1

I’m modifying my radio astronomy applications to support other than
tuner-type daughtercards.

Is this roughly correct for supporting such cards (BASIC_RX is the only
one I know of)?

    #
    # Everything except BASIC_RX should support usrp.tune()
    #
    if not (self.cardtype == usrp_dbid.BASIC_RX):
        r = usrp.tune(self.u, 0, self.subdev, target_freq)
    else:
        r = self.u.set_rx_freq(0, target_freq)
        f = self.u.rx_freq(0)
        if (abs(f-target_freq) > 2.0e3:
            r = 0
2

On Sat, Jun 24, 2006 at 12:52:11PM -0400, Marcus L. wrote:

I’m modifying my radio astronomy applications to support other than
tuner-type daughtercards.

Is this roughly correct for supporting such cards (BASIC_RX is the only
one I know of)?

I believe usrp.tune works correctly with all daughterboards.

Or slightly more compactly:

r = self.u.tune(0, self.subdev, target_freq)

Eric

3

Eric B. wrote:

Or slightly more compactly:

r = self.u.tune(0, self.subdev, target_freq)

Eric

That returned an error when used with a BASIC_RX card–with the latest
CVS image.

In the particular instance, target_freq was 10.7e6, which prompted an
error. I would expect
a BASIC_RX card to be able to “tune” to 10.7Mhz.

I looked around for an example that was designed for the BASIC_RX card,
and found
am_rcv.py, which uses the set_rx_freq() interface into USRP. This
seemed to work
OK, which is why I tweaked my code the way I did.

4

On Sat, Jun 24, 2006 at 03:15:37PM -0400, Marcus L. wrote:

I believe usrp.tune works correctly with all daughterboards.

Or slightly more compactly:

r = self.u.tune(0, self.subdev, target_freq)

Eric

That returned an error when used with a BASIC_RX card–with the latest
CVS image.

What was the error?

It worked fine for me. Attached is a screenshot looking at the
10.7MHz IF output of an AR8600 receiver.

This was tested using today’s CVS+SVN. FWIW, I don’t think we’ve made
significant changes in the relevant code for at least 6 months.

Eric

5

On Sat, Jun 24, 2006 at 03:15:37PM -0400, Marcus L. wrote:

I believe usrp.tune works correctly with all daughterboards.
In the particular instance, target_freq was 10.7e6, which prompted an
error. I would expect
a BASIC_RX card to be able to “tune” to 10.7Mhz.

I’ll attempt to reproduce and get back to you.

Thanks,
Eric

6

Eric B. wrote:

I can’t off the top of my head remember, and the hardware environment I
was using isn’t available to me
right now. Perhaps Lamar at PARI (it was their hardware) could re-try
using the usrp_ra_receiver application
with a BASIC_RX, tuned to 10.7e6, and see what happens.

The status bar indicated “failed to set frequency”, which comes as a
result of ‘r’ being zero on return from
r = usrp.tune(foo).

7

On Sun, Jun 25, 2006 at 01:27:37PM -0400, Marcus L. wrote:

Eric

I can’t off the top of my head remember, and the hardware environment I
was using isn’t available to me
right now. Perhaps Lamar at PARI (it was their hardware) could re-try
using the usrp_ra_receiver application
with a BASIC_RX, tuned to 10.7e6, and see what happens.

The status bar indicated “failed to set frequency”, which comes as a
result of ‘r’ being zero on return from
r = usrp.tune(foo).

This probably isn’t the problem, but FWIW r is never zero.
It’s either None or an instance of a class that details the setup.

Trying the checked in version of usrp_ra_receiver.py I get this:

[eb@bufo python]$ ./usrp_ra_receiver.py --help
Traceback (most recent call last):
  File "./usrp_ra_receiver.py", line 27, in ?
from gnuradio.wxgui import stdgui, ra_fftsink, waterfallsink,

ra_stripchartsink, form, slider
ImportError: cannot import name ra_fftsink

After fixing that I get

[eb@bufo python]$ ./usrp_ra_receiver.py --help
Traceback (most recent call last):
  File "./usrp_ra_receiver.py", line 30, in ?
import ra_fftsink, ra_stripchartsink
  File

“/home/eb/gr-build/gr-radio-astronomy/src/python/ra_stripchartsink.py”,
line 30, in ?
import ephem
ImportError: No module named ephem

No ephemeris data for me :wink:

Eric

8

On Sun, Jun 25, 2006 at 01:40:51PM -0700, Eric B. wrote:

On Sun, Jun 25, 2006 at 01:27:37PM -0400, Marcus L. wrote:

The status bar indicated “failed to set frequency”, which comes as a
result of ‘r’ being zero on return from
r = usrp.tune(foo).

Does the hardware in question have two Rx daughterboards installed?
Perhaps you were neglecting to set the -R option
on the command line?

Eric

9

On Sunday 25 June 2006 16:48, Eric B. wrote:

On Sun, Jun 25, 2006 at 01:40:51PM -0700, Eric B. wrote:

On Sun, Jun 25, 2006 at 01:27:37PM -0400, Marcus L. wrote:

The status bar indicated “failed to set frequency”, which comes as a
result of ‘r’ being zero on return from
r = usrp.tune(foo).

Does the hardware in question have two Rx daughterboards installed?
Perhaps you were neglecting to set the -R option
on the command line?

Yes, the particular USRP Marcus was using had a Basic RX in A and a DBS
RX in
B.

Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu