[Discuss-gnuradio] Somebody stop me before I code again

[Marcus Leech]

In between putting coats of paint on the bathroom wall, etc, I managed 
to make further improvements
 to my RA receiver code.

http://www.propulsionpolymers.com/radioastronomy/usrp_ra_receiver.py
http://www.propulsionpolymers.com/radioastronomy/ra_stripchartsink.py
http://www.propulsionpolymers.com/radioastronomy/local_calibrator.py

I'm still playing with the layout of the GUI controls.  I can't get the 
Gain/Averaging/Integration slider "stack" to
 occupy a discreet corner on the right hand side--it insists on 
occupying an obscene amount of territory.
 Someone more familiar with the wxWidgets layout machinery may be able 
to make it look prettier.

It displays the current LMST right below the frequency input field.  The 
axis labels are settable when
 the ra_stripchart_sink_f is created, as is the base of the Y axis 
division granularity.  Also, you can pass
 a function to ra_stripchart_sink_f for calibrating the numbers being 
given to the chart.  This is useful
 for providing calibrated results based on your own observatory.  This 
is controlled through
 an imported set of functions in local_calibrator.py.   I have a 
"default" function that simply
 translates the data values into dB, and another function that I used 
here today that is more
 ornate.  It uses the same 10log10 calibration, but also as a 
side-effect logs calibrated data values to
 a file, stamped with the LMST.  The filename is determined from the 
current date/time.
 There's likely a less-kludgey, and more object-oriented way to do what 
local_calibrator
 does.  But it's a start, and it works like a champ.

This set of code requires that you install the PyEphem package, 
available on the net.

I plan to investigate PyFits to perhaps have the local_calibrator be 
able to log data in
 FITS data formats.  But perhaps a more-general "local-processing" 
block is required
 ultimately.

At this point, you could actually use this for gen-you-whine total-power 
data logging on a real
 radio telescope.

Some caveats:

   o I'm just learning Python and GnuRadio

   o The receiver pipeline produces samples at a fixed 2Hz, and there's 
code that "knows" this
      [This may render the code unsuitable for high-rate scanning, or 
for transit observations on
        radio telescopes with obscenely-small beamwidths].

    o Whenever you change integration times, you have to wait for 
theFIR buffer to fill up
        before you start getting data out of it again.  This can lead 
to surprises in the chart and
        logger.

     o I'm not a real radio astronomer, but I play one on the net 
sometimes.

     o Many of the parameters of ra_stripchart_f aren't available as 
command-line options
        in usrp_ra_receiver--but that will get fixed soon.