[Top][All Lists]

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

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

From: Marcus Leech
Subject: [Discuss-gnuradio] Somebody stop me before I code again
Date: Sun, 08 Jan 2006 19:27:07 -0500
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

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


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

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

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.

reply via email to

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