NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > PlanOfRecordC72007 > ModificationRequest2C707

Changes | Index | Contents | Search | Statistics | Go

Improved Processing of Ka-band Pointing Data by GFM and PrePoint

Modification Request 2C707, October 2007

• 1. Introduction
• 2. Background
• 3. Requirements
• 4. Design
• 5. Deployment Checklist
• 6. Test Plan
  • 6.1 Internal Testing
  • 6.2 Sponsor Testing
  • 6.3 Integration/Regression Tests
• Signatures
• CCC Discussion Area

1. Introduction

The use of the CCB (Caltech Continuum Backend) with the Ka-band receiver will become more common in the near future. The primary PTCS pointing and OOF calibrations will be done in this mode. So it is important for GFM and PrePoint to handle the CCB data gracefully. Certain aspects of this observing mode are different from the usual cases for most of the other receivers in combination with the DCR:

• four frequency channels, instead of just one (the usual DCR setup) Frequency selection from amongst the 4 channels is already handled through the options dialog -- BSM 27nov07
• two beams, but only one channel per beam: 1R and 2L. Isn't this 1X and 2Y (or the converse) now? --BSM 27nov07

2. Background

Previously the main concern was that GFM produce reasonable pointing corrections, which it does.

At the moment, when one runs gfm (or prepoint) on Ka-band CCB data, it looks by default for the XL polarization data on beam 1 and complains because it cannot find it. The only data processing options available in GFM are "X/Left" or "Y/Right". Regardless of which one you select, the same exact plots and fitted parameters result, but in neither case are the plots labeled correctly (they should be labeled "1R/2L" because this is the only combination that exists).

GFM/PrePoint ignores any noise cal data, and produces amplitudes in terms of raw counts; thus no information about system temperatures can be determined.

For Ka/CCB data, PrePoint produces an output file with two lines for each scan, labeled RCP and LCP, but in fact these two lines are identical. It only processes one of the four frequencies.

3. Requirements

• GFM should not have rigid expectations about what beam and polarization combinations exist. It should find out from the IF FITS files and/or the backend data files what these combinations are.
• GFM should understand the special properties of the Ka-band receiver, i.e., cross-pol switching and 4 frequencies.
  • Is there any way to capture the special properties of the receiver in a FITS file somewhere? Then GFM could read the information from the data set and know what to do with the data. I sort of hate the idea of hard coding behaviors. My paranoia stems mainly from the history of this receiver. It has undergone many changes and we keep having to change the software every time. At one point GFM was working with CCB/DCR data with the Ka-band receiver and it broke after the last round of changes. Now we have to change it again. AmyShelton

How about the description from:

http://wiki.gb.nrao.edu/bin/view/Data/GbtFitsMonitorKA_DCR

• GFM should have the option of processing the noise cal data and producing calibrated data and system temperatures.
  • I would reword this to say: "GFM shall produce calibrated data and system temperatures for all CCB datasets in the Peak and Focus plugins. Raw data should be shown in the Continuum tab." AmyShelton
• PrePoint should produce outputs for all frequency channels.
  • What sort of outputs? I'm not familiar with PrePoint enough to know. AmyShelton
• GFM displays should be labeled correctly.
  • Can you be more specific about what labels in which plugins need to be modified and what they should say? E.g. change blah in the blah plugin to blah. AmyShelton

To expand on the above, the specific things I know that need to be done are:

• handle the 1-cal-firing, beamswitched case. Probably all 2-cal (or no-cal) cases are already handled properly, or will be once any potential labelling issues are sorted out, since they are the same as other receivers.
• update the calibration database (current measurements are from 2005 judging from the file name, and are incomplete for the continuum tables-- only 2 freq channels exist). Possibly the continuum tables could be done away with in favor of just averaging over the spectral line cal values but then the following item is more cumbersome:
• if 1-cal data is to be calibrated correctly to better than 15%, 1-cal data will need to be collected and stored separately from the 2-cal data in the measurements database now. Alternately we could just accept that GFM's calibration of 1-cal data will give some idea but it's not very accurate.

BSM 27nov07

4. Design

5. Deployment Checklist

6. Test Plan

6.1 Internal Testing

6.2 Sponsor Testing

6.3 Integration/Regression Tests

Signatures

APPROVED: I acknowledge that my request is fully contained in this MR, and if the SDD delivers exactly what I specified, I will be happy.

ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.

Symbols:

• Use %X% if MR is not complete (will display )
• Use %Y% if MR iscomplete (will display )

CCC Discussion Area