NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > PlanOfRecordC72005 > ModificationRequest13C705

Changes | Index | Contents | Search | Statistics | Go

Add Support for new Ka Channels to GFM

Modification Request #13 (C07 2005)

• 1. Introduction
• 2. Background
• 3. Requirements
  • 3.1.1 New Spectral channels
  • 3.1.2 Generate Warnings if Desired beam/poln is unavailable
  • 3.2 Fetching the correct Tcal values when beam switching.
• 4. Design
• 5. Deployment Checklist
• 6. Test Plan
• Signatures
• CCC Discussion Area

1. Introduction

GFM needs to support the two new Channels in the Ka receiver.

2. Background

The Ka receiver used to have just two channels. Now it has four.

3. Requirements

General comments

• the following capabilities are meant to apply to all GFM plugins
• The GFM bible (articulates The Vision Thing-- not reqmts but, to bear in mind)
  • New Testament= http://wiki.gb.nrao.edu/bin/view/Data/WebHome?topic=GbtFitsMonitorKA_DCR
  • Old Testament= http://wiki.gb.nrao.edu/bin/view/Data/GbtFitsMonitorKA_DCR?topic=DCRDataDecoding

3.1.1 New Spectral channels

We should be able to select any of the 4 channels and have them work (L1, L2, R1, R2). This means, in GFM's Options -> Tools -> Data selection menu, you should be able to choose any of the beams/polarizations from the menu, and the appropriate beam/polarization be selected from the FITS files just like any other receiver. (Note: I think the DCR plugin allows beam selection, but the others, just poln b/c they use tracking beam). We think this involves no new functionality per se, it should just work.

3.1.2 Generate Warnings if Desired beam/poln is unavailable

If the desired beam and polarization isn't available GFM should complain visibly and not just silently default to the first beam or polarization it comes across. This should happen for any receiver, not just KA.

3.2 Fetching the correct Tcal values when beam switching.

The Ka band receiver has the oddity that when you are in the REF state, not only does the feed change (which always happens... feed 1 --> feed 2 say), but the polarization changes as well. We must get the appropriate tcal when in the REF state. So suppose we are looking at beam 1 left polarization in the SIG state. We look up the Tcal for L1. If we are looking at that same backend input port in the REF state, we would get the Tcal for R2 (not L2 as would be the case for other receivers).

Although beyond the purview of this MR, the polarization also pertains to the calibration of spectral line data.

4. Design

To address the requirements in section 3.1.1 above, all that needs to be done is to remove the "if" statement regarding the Ka receiver in the ReadReceiverInfo method of the Input class in the dcr module of sparrow. Once removed, GFM (and all other programs that use this library) will select channels/beams/polarizations for the Ka receiver just as it does any other multi-beam receiver.

To address the requirements in section 3.1.2 above, the GetSampler method of the Continuum class in the calibration module needs to be modified to sent a visible message to the user when the desired sampler is not found; currently it returns the first sampler without complaint. I believe that this can be accomplished by adding a print statement to the method right before returning the default sampler value. The message will read, "Cannot find beam 'beamname' with polarization 'polarization' in the backend's FITS file."

To address the requirements in section 3.2 above, the GetSampler method of the Continuum class in the calibration module needs to be modified to add an "if" statement that checks to see if we are looking for the sky beam (i.e. not the track beam) of the Ka Receiver. When triggered, the "if" statement will grab the data from the other polarization.

UPDATE (4/4/2006): The design proposal above for section 3.2 is wrong. The "if" statement is indeed needed, BUT should only be invoked when fetching tcal values and not the data iteself. This was implemented incorrectly and is now fixed as of version 6.2.

5. Deployment Checklist

• Send email to gbtlocal regarding nature of changes when patched into Sparrow v5.7.

6. Test Plan

• New spectral channels-- configure TB=1 (all beams routed), do a peak scan. In GFM offline mode you should be able to process the data with either L or R pol selected. If not GFM is not properly getting the "new channels data", if so, it is.
• Warning of unavailable beam/poln-- configure TB=1, but manually unselect the "R" polarization in the DCR (config tool always routes both polns). Process the data with "R" selected and GFM should complain, then process it with another sampler.
• Fetching correct Tcal values-- pick a frequency where the Tcals are quite different. do a peak scan (beamswitching, with both cals tracking). Peak heights should come out with sensible and comparable (better than 10%) amplitudes. HOWEVER this depends on the instrument team entering sensible values for Tcals to the calibration FITS file so can't happen immediately, we'll have to do this test later.

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.

Written	- AmyShelton - 01 Dec 2005
Checked	- NicoleRadziwill - 02 Dec 2005
Approved by Sponsor	BrianMason - 01 Dec 2005
Approved by CCC	RichardPrestage - 19 Dec 2005
Accepted/Delivered by Sponsor	Brian Mason 06feb06 -- HOWEVER correctness of Tcal-fetching not presently verifiable for external reasons

Symbols:

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

CCC Discussion Area

-- PaulMarganian - 11 Oct 2005