NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Observing > CcbCmbCampaign > CcbCmbRuns > CcbRunF
   Changes | Index | Contents | Search | Go

ccb comm run F 09jan06

obs log

*********************************************************************
23:00
*********************************************************************

ready to do Brian's tests, Barry is the operator Tau at 34 GHz is between 0.05 and 0.1 according to the 60 hour forecast. Visually sky is clear. Winds are <=10mph

Project ID is TKA_CCB09Jan06

23:10 begin AutoPeakFocus2 on 3C147 GFM is blanked out and taking a long time to refresh. 'Raw' data processing button greyed-out. May have to wait until obs begin? GFM is taking a long time to start up and seems to be eating up CPU. First peaks
look pretty bad but am not sure if the 'raw' mode was properly selected. Yes, this looks like the case, will begin pointing again, so ignore scans 1-5.

Scans 6-10 Good pointing/focus on 3C147

                 OldAz2:   0.000  OldEl:   0.448
                   dAz2:   0.228    dEl:   0.047
                 NewAz2:   0.228  NewEl:   0.495
Scan 10: 0542+4951 (Az,El) = (331.815,76.630) fit passed.
Offset = -10.593mm. Old DFC = -6.497mm. New LFC = -4.096mm.

Scan 11, begin ccbCalib3c147

Sig and Ref Data sampler powers all look good, receiving warning about LO power level which is at 0.03 which Brian told me
to expect. Also warning about >10% of phase state being blanked, I think this is deliberate?

Scan 12, run ccbCalib3c147 again, I can't check the data at the moment so will run for safety though everything looks fine. I believe that sdfits does not yet handle ccb data?
Scan 13, run ccbCalib3C48, source is low (around 30 degrees) but this should be fine.

Hit 'ok' on astrid message accidentally, "Check that rx is configured properly for Ka into GFM (beamswitches, cals, dcr; active surf zero off; archivist is in; etc.) - Continue scheduling block?" and replied "Yes"

Archivist is in.

O.k. this script is pointing and the fit is very poor. El fits are o.k. This is a little weird, halfway through the second
Az peak scan I checked the data processing mode and it was set to 'raw' but fits were bad (looked like it was trying to calibrate). The El fits came in o.k. I checked again and the beamswitch button was selected. WHY?

Second peak is better but not great, fit not done.
                 OldAz2:   0.228  OldEl:   0.495
                   dAz2:  -0.120    dEl:  -0.205
                 NewAz2:   0.109  NewEl:   0.291   *** El heuristics failed

LFC *not* updated for scan 22.
Offset = -39.719mm. DFC = -4.592mm. LFC = -35.127mm.

I don't like this, why is the focus correction so large? GFM has reset data processing to beam switched TB only.

Run another peak scans 24-28 looks noisy but reasonable. Actually, there is a negative offset in the scans.

Re-peak on 3c147. GFM reset to beam switched TB only again! This is very annoying.

  Astrid is responding very slowly, Barry says that there is an ongoing investigation into this. Have mailed Mark Clark just to inform him.
  After 1st scan gfm reset DP mode again. Am giving up on this, why is this happening? Will ask Brian.

  Scan 33: 0542+4951 (Az,El) = (316.080,72.186) fit passed.
Offset = -19.319mm. Old DFC = -4.037mm. New LFC = -15.282mm.

I don't trust these peaks/focuses.

***************************************************************************
00.00
***************************************************************************

Scan 34 beginning crabmap the point in this script looks better, though the DP mode is getting reset at the beginning of each subscan. Am setting it to 'raw' with each scan manually. These fits look a lot better, unsurprisingly. DP is getting reset HALFWAY THROUGH SCANS too.

Crabmap is underway.

scans 80-83 peak looks o.k. but had to set DP to 'raw' by hand every 10 secs or so.
Scan 83: 0510+1800 (Az,El) = (254.126,47.103) fit passed.
Offset = -13.758mm. Old DFC = -4.349mm. New LFC = -9.409mm.

O.k. not sure how ccb data is supposed to be reduced but the data is in an array like (16,4,24000). This implies to me the
16 channels of the ccb, the 4 inputs (two beams, two polarisations) and 24000 'samples'. So, CCB must be beamswitching in some manner, thus a sig-ref/ref would be something like (0,0,*)-(0,1,*)/(0,1,*)
  If I do this for the first few scans we did, i.e. the calibrator maps, it looks reasonable (i.e. like the plots on Brian's door). However the crab map looks poo.

****************************************************************************
02.00
****************************************************************************

Scans 124-127 peak, came in well

                OldAz2:  -0.031  OldEl:   0.212
                   dAz2:   0.082    dEl:  -0.106
                 NewAz2:   0.051  NewEl:   0.106

Scan 127: 0510+1800 (Az,El) = (264.370,36.670) fit passed.
Offset = -14.245mm. Old DFC = -5.200mm. New LFC = -9.046mm.

This looks a lot more reliable. I'm confused, I thought mapping would stop here but it has begun a 1126 scan loop. Should I continue with this or go on to Brian's cycle scripts? I think I'll move on and email Brian for advice for next time.

****************************************************************************
02.07
****************************************************************************

aborted crabmap. Am beginning ccbcycle08. will line up two of these and two ccbcycle14 and leave it for the night.
scans 135-138
                 OldAz2:   0.051  OldEl:   0.106
                   dAz2:  -0.033    dEl:   0.067
                 NewAz2:   0.018  NewEl:   0.173

Scan 138: 0825+0309 (Az,El) = (200.042,53.083) fit passed.
Offset = -13.637mm. Old DFC = -5.694mm. New LFC = -7.943mm.

analysis notes

-- BrianMason - 01 Feb 2006

Topic CcbRunF . { Edit | Attach | Ref-By | Printable | Diffs | r1.1 | More }
Revision r1.1 - 01 Feb 2006 - 19:27 GMT - BrianMason
Parents: CcbCmbCampaign > CcbCmbRuns
Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.