discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] microtune.i / SWIG overview


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] microtune.i / SWIG overview
Date: Sat, 17 Apr 2004 14:47:50 -0700
User-agent: Mutt/1.4.1i

On Sat, Apr 17, 2004 at 02:03:49PM -0700, cfk wrote:
> Dear Guys:
>
>     I am trying to understand src/gnu/scripting/microtune.i as I get
>     prepared for a USRP with a microtune 4702 frontend. I can see
>     some "%include" statements and class definitions.  I can also
>     find the microtune_4702.h/.cc files, but I am a bit lost by the
>     .i file that I have never come across before.

The .i files are specially modified header files that are read by SWIG.
SWIG is the program that we use to generate the glue between C++ and
Python.  http://www.swig.org 
SWIG can generate glue for about a dozen scripting languages.


Here's how how it goes together:

We generate libgnuradio.so, a standard C++ shared library, 
that contains the compiled C++ routines.

SWIG reads the .i files and generates two files, _GnuRadioPython.cc
and GnuRadioPython.py, the python wrapper for the low level stuff.
_GnuRadioPython.cc gets turned into yet another shared library
_GnuRadioPython.so

GnuRadio.py is our hand coded top level glue which imports the SWIG
generated stuff plus some other python code required to make it all
hang together.

In python when you

>>> from GnuRadio import *

GnuRadio.py imports GnuRadioPython.py
... which dynamically loads it's corresponding shared lib _GnuRadioPython.so
... which causes libgnuradio.so to also be loaded to resolve symbols


>     My experience is with driver writing mostly, so maybe this is a
>     C++ or Python scripting nuance that I dont grok yet.

>     Could you consider writing a paragraph or two back describing
>     the care and feeding of ".i" files in src/gnu/scripting/. I am
>     thinking in particular how one goes about describing a complete
>     executable program, be it C++ or Python that will initialize a
>     4702 and get it to where it can receive *some* frequency.

When I'm a bit further along the rewrite path, I'll definitely put
together a detailed discussion about how this all plays together.
SWIGish things are somewhat different in the rewrite, so I really
don't want to spend too much time on it now.

>     I understand this will end up with
>     includes/instantiations/invocations of additional things like
>     VrSigSource and others.

>     I guess my main problem is I dont yet have a feel of how it all
>     might fit together to make an executable yet and I am eager to
>     understand enough of how the software fits together to allow me
>     to make *stuff* happen.

>     I also understand there is a re-write in progress, but I am
>     hopeful that a couple of paragraphs can allow some progress to
>     be made on this end in the meantime.


There's a good Python tutorial:

   http://docs.python.org/tut/tut.html

   ... although I prefer the PDF formatted version in the tarball below
    
All the standard python docs in PDF:

   http://www.python.org/ftp/python/doc/2.3.3/pdf-letter-2.3.3.tgz

More good stuff at http://www.python.org/doc/


----------------

Here's a program that is for a build that's somewhere between the CVS
head and the rewritten stuff.  It's not correct in a few details, but
the basic outline is sound.  The signal processing graph is set up in
build_graph; the microtune 4937 is messed with towards the bottom.

The handling of the 4702 will need to be revisited to handle it when
it's on the daughterboard.

The GNU Radio stuff ends up being an extension loaded into python.

Eric
 
----------------------------------------------------------------

#!/usr/bin/env python

# simple broadcast FM receiver

from GnuRadio import *

#
# return a gr_FlowGraph
#
def build_graph (IF_freq):
    input_rate = 20e6

    CFIR_decimate = 125
    RFIR_decimate = 5
    fm_demod_gain = 2200

    quad_rate = input_rate / CFIR_decimate
    audio_rate = quad_rate / RFIR_decimate

    volume = 1.0
    
    src = GrHighSpeedADCSourceS (input_rate)

    # compute FIR filter taps for channel selection
    channel_coeffs = \
      gr_firdes.low_pass (
        1.0,          # gain
        input_rate,   # sampling rate
        250e3,        # low pass cutoff freq
        8*100e3,      # width of trans. band
        gr_firdes.WIN_HAMMING)

    # input: short; output: complex
    chan_filter = \
      GrFreqXlatingFIRfilterSCF (CFIR_decimate,
                                 channel_coeffs,
                                 IF_freq)
    # input: complex; output: float
    fm_demod = \
      GrQuadratureDemodCF (volume * fm_demod_gain)

    # compute FIR filter taps for audio filter
    width_of_transition_band = audio_rate / 32
    audio_coeffs = \
      gr_firdes.low_pass (
        1.0,            # gain
        quad_rate,      # sampling rate
        audio_rate/2 - width_of_transition_band,
        width_of_transition_band,
        gr_firdes.WIN_HAMMING)

    # input: float; output: short
    audio_filter = \
      GrFIRfilterFSF (RFIR_decimate, audio_coeffs)

    final_sink = GrAudioSinkS ()
    
    fg = gr_FlowGraph ()

    fg.connect (src, chan_filter)
    fg.connect (chan_filter, fm_demod)
    fg.connect (fm_demod, audio_filter)
    fg.connect (audio_filter, final_sink)

    return fg

if __name__ == '__main__':

    # connect to RF front end
    rf_front_end = microtune_eval_board ()
    if not rf_front_end.board_present_p ():
        raise IOError, 'RF front end not found'

    # set gain and radio station frequency
    rf_front_end.set_AGC (300)
    rf_front_end.set_RF_freq (100.1e6)

    IF_freq = rf_front_end.get_output_freq ()
    fg = build_graph (IF_freq)
    fg.start ()        # fork thread(s) and return
    raw_input ('Press Enter to quit: ')
    fg.stop ()




reply via email to

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