NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > ModificationRequest3C407
   Changes | Index | Contents | Search | Statistics | Go

Correct Labeling of Ka-band Hybrid-switched Signals

Modification Request #3 (C4 2007)



1. Introduction

The Ka-band receiver contains a hybrid that switches between a "signal" and "reference" state. For each state, a given sampler receives information from a given feed and polarization. Currently, this labelling is only correct when the switch is in one state and not in the other. The system should reflect the changing state seen by the sampler. This should be corrected to help observers with their data reduction.

2. Background

At present, the polarization and feed labels as viewed in GBTIDL are correct only when the Ka-band hybrid is in either the "signal" or "reference" state, but not in both. There has been a great deal of effort expended to determine which state is labelled correctly, and if it is always a given state or if the correct state is different for different datasets. This effort has failed to provide a completely satisfactory answer. However it actually works, the labeling is consistent so the user can recover the correct signal path. Any automated reduction routine could work around this problem, so this is only an issue for those users who wish to use their own reduction routines or inspect the data in detail.

Here is an example for a specific dataset:

#INDEX SOURCE SCAN PROCEDURE POL IFNUM FDNUM INT SIG CAL
0 F10214 10 unknown LL 0 0 0 F T
1 F10214 10 unknown LL 0 0 0 T T

These are the first two dumps for sampler A1. Index #0 is correct, A1 should be seeing feed 0, pol LL in the 'ref' (SIG=F) state. When the hybrid switches to 'sig' (SIG=T), A1 should be seeing feed 0, pol RR but the labelling does not reflect this (but see the note below on the cabling file). Similarly, for A2:

#INDEX SOURCE SCAN PROCEDURE POL IFNUM FDNUM INT SIG CAL
4 F10214 10 unknown RR 0 0 0 F T
5 F10214 10 unknown RR 0 0 0 T T

Index #4 reflects the correct signal path, while index #5 is incorrect.

It should be noted that the cabling file also had a labelling error, so that for this data a label of L1 is actually R2 and R1 is actually L1 (and L2 is R1 and R2 is L2). This is an independent problem from the labelling errors described above and is not addressed by this MR. The reader also should note that the Spectrometer fits file has SIG=0 as the "signal" state and SIG>=1 as the "reference" state.

This improvement will be a benefit to any correlation receiver on the telescope, including the dual-beam W-band receiver as it is currently designed.

3. Requirements

  1. The feed and polarization numbers for each sampler should reflect the true signal path when the hybrid switch is in either the "signal" or "reference" state.
  2. The Ka-band receiver contains a hybrid that switches between a "signal" and "reference" state. For each state, a given sampler receives information from a given feed and polarization. When viewed in GBTIDL, the feed and polarization are correct only when the hybrid is in "reference" state. This should be corrected to help observers with their data reduction.

4. Design

Rationale

The IF manager describes the analog characteristics of the astronomical system in the telescope both for user feedback and data annotation. In its FITS file, it produces one row for every complete path found in the telescope from a signal-generating source, e.g., feed, to a port on a device that digitizes the signal, i.e., backend. Signals whose characteristics change over time during a scan require additional annotation.

Frequency changes generated from the LO1 are handled by the generation of coefficients for- and the specification of the Sky Frequency Formula, and handling the LO1 frequency as a variable in the equation representing changes among switching signal states whose values are recorded in the LO1 FITS file.

Some receivers such as the Rcvr12_18 perform beam-switching electronically, i.e., they change the IF signal paths under control of the sig/ref switching signal during a scan. The IF manager is able to succinctly handle such receivers because the signal path change is always a cross switch and occurs early in the signal path so that the only part of the signal path that changes is the before the transfer switch, i.e., the feeds and polarizers. Each row of the IF FITS file describes the path when the switching signal is in the sig state, so the columns FEED and RECEPTOR are dependent on the sig/ref state. To map between the sig and ref states two additional columns, SRFEED1 and SRFEED2, were added to the table to document the feed in use in the ref state. If a row has FEED equal to 3 and SRFEED1 and SRFEED2 contain 3 and 4 then the feed being used in the ref state would be 4. (The value 0 is entered into SRFEED1 and SRFEED2 for receivers that cannot have path changes during a scan.)

One can easily imagine receiver configurations which this scheme cannot handle. With the current set of receivers for the GBT there are two existing problems with this scheme. First, as described by GlenLangston in April 2003, beam switching prevents a direct mapping between a row in the IF FITS file and tables in the receiver calibration file. Second, Rcvr26_40 beam-switches not only between feeds but also between receptors. In both cases the inadequacy of the SRFEED columns are exposed. Glen proposes replacing SRFEED1 and SRFEED2 with columns that describe the "other" receptor (a string, e.g. L1) rather than the "other" feed (an integer, e.g., 1). This would allow direct mapping between the IF FITS column and receiver calibration FITS tables. The use of receptors rather than beam identifiers would allow switching between R1 and L2, and between R2 and L1 (or whatever pairs engineers might dream up). In addition, BobGarwood suggested that for each IF path, the IF manager explictly determines the receptor for the ref path. In the FITS file, instead of the two SRFEED columns, a REFRECEPTOR column would contain the ref receptor partner to the sig receptor contained in the current RECEPTOR column, e.g., for Rcvr26_40 the IF manager rows would be (first 11 columns only):

     BACKEND BANK PORT  RECEIVER FEED RECEPTOR REFRECEPTOR LO_CIRCUIT LO_COMPONENT SIDEBAND POLARIZE
Spectrometer    A    1 Rcvr26_40    1       L1          R2       LO1A  synthesizer        L        L
Spectrometer    A    2 Rcvr26_40    2       R2          L1       LO1A  synthesizer        L        R

This will provide the information both for characterizing the ref path and for matching to the correct table in the calibraton FITS.

If the receiver does not beam switch, i.e., no ref path, then the values of the RECEPTOR and REFRECEPTOR paths would be the same.

Tasks

The following changes will affect all receivers.

Receiver Configuration Files

Currently all receivers capable of beam switching have entries in their configuration files describing sig/ref beam pairs, e.g., in Rcvr12_18:

# sig/ref feeds (srfeed[srfeedN][2])
srfeedN := 1
srfeed[0][0] := 1
srfeed[0][1] := 2
These will need to be modified to include:
# sig/ref receptors (receptor[receptorN][2])
receptorN := 2
receptor[0][0] := "R1"
receptor[0][1] := "R2"
receptor[0][0] := "L1"
receptor[0][1] := "L2"
(Later versions may remove the srfeed entries.)

New Class ReceiverReceptorPairs

A class for accessing and providing receptor pairs, ReceiverReceptorPairs, analogous to the current ReceiverFeedPairs (to be deprecated), needs to be added to the IF library in ygor.

IFFitsIO

The FITS writing class IFFitsIO needs to be modified to write a REFRECEPTOR column in lieu of SRFEED1 and SRFEED2, and to determine which receptor string to be placed in the REFRECEPTOR column for a given RECEPTOR string.

sdfits

The existing SRFEED column will be removed from the output SDFITS file. Since the receptor is not stored in the current SDFITS file, there seems to be no reason to add the new REFRECEPTOR column to the output of sdfits. The CRVAL4 (polarization) and the FEED column values need to change with the switching state (the SIG value in the output sdfits) when electronic beam switching is occurring. The IF table only describes the signal path for the first switching state and it the REFRECEPTOR value only describes an alternative receptor that is used when electronic beam switching is happening. It does not indicate whether such switching is, in fact, happening. When the SWTCHSIG keyword in the GO FITS file is "BEAMSW" then electronic beam switching is happening. In that case, sdfits needs to label the data in each row with the correct polarization and feed. The SAMPLER name remains unchanged. The IF FITS file FITSVERS will be used for backward compatibility.

The IF FITS file describes the system in the signal (SIGREF==0) state. The REFRECEPTOR value is then used to determine the value of the feed and polarization for the other state.

sdfits gets the CRVAL4 value from ScanData.getStokesCode ScanData assembles the stokes code in it's gatherStokesCodes method. That method needs to be modified to take into account the REFRECEPTOR value when the SWTCHSIG keyword is BEAMSW. getStokesCode will then have an additional "phase" argument using the value already in use elsewhere to retrieve the stokes code for a given sampler and phase.

Similarly the feed information is gathered in scanData and retieved via a function call by the sdfits writer. The feed information also needs to take into account the phase and REFRECEPTOR value as with the stokes code to return the feed name for a sampler and phase. gatherFeedInfo and getFeed will need to be modified. It will probably be best if the steps in gatherFeedInfo and gatherStokesCodes are combined into one step so that only one pass through the IF table information is necessary.

References to SRFEED1 and SRFEED2 in ScanData can be removed as can the getSRFeed method.

gfm

It is important that the labeling of the same raw data in GFM agree with that in GBTIDL to avoid confusion when an observer is comparing what they see in GFM with what they see in GBTIDL. GFM get's the data through a completely different path. It requests the data by feed, polarization, IF, integration, and phase through the backend.getRawPowerByValues method (and getCorrelationByValues when lag data is requested for the ACS). Internally, these labels are translated to sampler, integration, and phase indexes and those are used to grab the appropriate vector from the backend FITS file. The sampler index translation is done in PortTable.getSamplerByValues. Currently that only depends on feed, polarization and IF. A new argument, sigref, will be added to that method.

The PortTable object only uses information from the IF fits file. Consequently, it can only tell that beam switching may be occurring not whether or not it actually is occuring (that information is found in the GO fits file as described above). The IF FITS file describes the system in the SIGREF==0 state. The new sigref argument to PortTable.getSamplerByValues will be equal to the SIGREF value for the switching phase being requested. This argument should always be 0 unless beam switching is occuring. The IF FITS file FITSVERS will be used for backward compatibility.

aips++ filler

These changes will break the existing distributed aips++ filler for first time since aips++ development ended. The aips++ filler expects there to be SRFEED1 and SRFEED2 columns in both the IF FITS table as well as in the Antenna beam offset table. Even non-beam switched data will still break the aips++ filler. Since there are a few aips++ users still around and since the aips++ filler is the only way for GBT data to get in to CASA, it is necessary to at least make the aips++ filler not care if these columns are missing. That work is relatively straightforward. I also believe I know how to build and distribute a GBT patch to the aips++ RPM and we can make that available and installed at all NRAO sites.

It should be possible to modify the filler to also correctly label Ka switched data using the new IF table values. However, since it's been several years since I looked at that code it's difficult to estimate the amount of work. Also, the class names and methods at least reflect the notion that it's the feed that is being switched as opposed to the receptor and so there may be more code re-working than I might hope. If this can't be done within two days, this work should be stopped and the aips++ filler simply patched so that non beam-switched data is correctly filled and we should distribute that patch and revisit a more general fix for beam-switched data at a later date. The IF FITS file FITSVERS will be used for backward compatibility.

GBTIDL

GBTIDL does not make use of the SRFEED information, it simply carries that value along into the data container. That field in the data container is no longer necessary and it will be removed. SDFEED values in existing sdfits files will be ignored by GBTIDL. No additions to GBTIDL are necessary to satisy the requirements of this MR.

5. Other relevant MRs

There are plans for implementing a reduction algorithm in GBTIDL for data taken with subreflector nodding. Since the hybrid-switches yield consistent (if incorrect) labels for the signal path, the reduction algorithm can account for the current labeling system. Even with the incorrect labels, the same sampler pair will be involved for a given feed/polarization pair. This means that only the sign in the reduction algorithm needs to be flipped if the labels are incorrect.

The Ka-band receiver is being partially redesigned this summer. The OMTs have been removed and only one hybrid (with only one polarization per feed) will be used (at least at the beginning of the season). The old design of the Ka receiver (with two hybrids) may be resurrected depending on the fall tests.

6. Deployment Checklist

7. Test Plan

Critical!! ChangeControlCommittee will be reviewing these.

Don't forget to include/acquire any additional GBT test time needed outside integration/regression testing! Get your requests in early!

Important! If possible, you should conduct as many of your tests as possible in offline modes and/or with a simulator. We should constantly endeavor to minimize our use of telescope time for testing!

7.1 Internal Testing

Run scans on the simulator with two different receivers and verify that the IF FITS files correctly contain the new column and the SRFEED columns are not present.

Manually modify the IFFITS files for beam switching data using Rcvr26_40 scans and confirm that gfm and gbtidl correctly interpret beam switching data. Note the gfm version should not have the modification described in MR3C507.

7.2 Sponsor Testing

The tests will require a moving telescope, but can probably be done as part of the Ka commissioning if this work is completed by then. Tests using all our existing beam-switched receivers should have their data labeled by the IF Manager in the correctly for all integrations. We will simply take nodding observations of a bright calibrator to verify the signal path. Tests using the Ka-band receiver should show a proper labeling of the data.

7.3 Integration/Regression Tests

Integration tests should include production use of Rcvr26_40 scans. A simple dataset to test this on is /home/gbtdata/TKA_27JAN07. Any scans will work. Note that this file actually contains data from an observing run in April. Since the purpose of regression tests is to ensure we have not broken the system for use with other receivers, normal regression tests should suffice.


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 DONE - D.J. Pisano & Mark Clark- 23 Aug 2007
Checked DONE - MikeMcCarty - 23 Aug 2007
Approved by Sponsor DONE - D.J. Pisano - 24 Aug 2007
Approved by CCC DONE - AmyShelton - 04 Sep 2007
Accepted/Delivered by Sponsor symbol - name - date

Symbols:


CCC Discussion Area

Topic ModificationRequest3C407 . { Edit | Attach | Ref-By | Printable | Diffs | r1.19 | > | r1.18 | > | r1.17 | More }
Revision r1.19 - 04 Sep 2007 - 15:31 GMT - AmyShelton Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.