SHARC
Submillimeter High Angular Resolution Camera

Caltech Submillimeter Observatory

Caltech Submillimeter Observatory Office,
111 Nowelo St., Hilo, Hawai'i 96720
Voice: (808) 935-1909 Fax: (808) 961-6273

Observing

Pointing

Pointing has had problems in the recent past at the CSO. Ever since the installation of a new tilt meter, pointing has shown very good stability (1-2 arcsec variations only). The only remaining pointing problem is transitory -- pointing wanders for the first 2-3 hours as the telescope cools to ambient temperatures.

As for the cool-down, one thing may be done to increase the useful (with confident pointing) observing time through the night. Either you can ask day-crew to leave dome as open as possible (away from the sun) in the afternoon, so it begins to cool off earlier, or you can go up to the summit a little before sun-down, and do this yourself...

Before you worry about the pointing drift at the beginning, just a few things to consider. The drift seems to manifest itself only in the zenith direction. Since the SHARC array is aligned in Zenith, it only means your source may pop-up in another pixel, than you'd originally expect. The AZ direction pointing seems rather stable (within 1-2"), and SHARC pixels are large (10") in that direction anyway, making it more likely that your source is on the array than not. Oncethe telecope is cool, your confidence in pointing should increase accordingly... If all go well, it should stabilize to around 1-2" rms variations, which is nearly perfect...

While pointing you also want to measure the actual chop throw.

Reference pixel

By default pixel 12 (in the middle of the array) is the reference pixel on SHARC. However, SHARC has a number of bad pixels (1,5,15,16), a few occasionally misbehaving ones (2, 4, 17, 18). Also lately, it was demostrated by Darren that the lower half of the array is about a factor of 2 noiser than the top half (could be a result of the broken FET heater element). Thus, it makes sense to use the range of pixels 19-24 for deep point source observations. The center for this 7 pixel 'subarray' is pixel 21.5. Thus, customarily pixel 21 is used as reference pixel (that's where OTF pointings will be provided). However, apart from this geometry, there is signal-to-noise advantage of placing the source between pixels (thus 21.5) in the end. (Note. This way almost the entire beam falls into two pixels, while positioning onto a pixel will divide the better part of the signal up into three pixels). To move there, you will have to change the FZAO pointing offset, as suggested by the OTF pointing, by 2.5 (in the negative direction, but don't take my word on that -- Check!) to move between 21 and 22.

Methods

If a bright source is available (planets, Jupiter's moons, M42.1, IRAS16293, SGRB2...) use OTF pointing. In case of a ~40" chop throw 'otf 120 2 2 2 2 2' should be reasonable (it will make a single pass at 2 arcsec/sec speed of a 80" strip). Use 'camera' in 'pointing' mode to analyse the result. Since OTF is quick and easy, it is a good idea to obtain a set of pointings to convince yourself of its certainty. Also occasionaly some scans will be a little off in AZ (unresolved timing bug), and thus having more measurements will help you eliminate these outstanding points. It is possible to point in OTF mode on M82 as well. While the source is extended, and has two peaks, the center of emission can be identified with 1-2" confidence. Use M82MID from Darrens catalog ('cat user:[cdd]private_catalog.cat').
Note. Camera will provide pointing offsets to the reference pixel. If you want your source between pixels (ideal for S/N considerations for faint point sources), you should change the final value of FZAO by 2.5 in the desired direction.

For fainter point-sources (IRC10216, OH238.1 etc.) you need to point while chopping. Use the same chop integration settings as for your sources (see below). Step off 5 arcsecs in each direction in AZ, by appropriately changing the FAZO offset. Analyse the resulting scans with BADRS, and make a guess as to which way the pointing wants to be moving. The Zenith pointing should be apparent from the position of the source on the array... Pixel separations in the ZA directions are ~5".

Pointing with Camera

Choose pointing mode 'p'.

In the dual beam data try to measure the apparent chopper throw. Do this by moving the cursor over the peaks (better to use geomentry than signal level, i.e. to pick the center of the contour lines), and press spacebar to get position readings. Compare the to positions and do the math yourself. It is good to measure it a few times (on different file entries) to get a good idea what your actual physical chop throw is. Once certain, reissue the sec command to reflect the apparent chopper throw size.

In the reconstructed beam map, move cursor to source center (gain use geometry) and press 'p', to give suggested pointing offsets, which you maye then manually enter in the UIP window, if wish to use.

Measuring Chop-Throw while chopping

If not bright enough point source exists on the sky for OTF pointing, you will have to use 'chop' integrations to determine your actual chopper throw. Once pointed, try different values of chop throw, by issuing the SEC command (SEC throw). See which value gives you the most signal - this is likely to be your best guess of your actual chop throw.

Chop-slewy Considerations

A typical chop slewy integration on faint sources will be done with the setting 'SHARC /CHOP=4/INT=8'. The result is and integration that is altogether 4 nod cycles (8 nods!) with 4 seconds of integration time (on+off time with overheads) per nod, i.e. 32 seconds of total integration time (with chopper overheads but not including overheads of nodding). This, with a 60% chopper efficiency translates into ca. 10 seconds on, and 10 seconds of off time. In general, if you decide how often you want to nod, and how often to write a file entry, you can set this parameters as:

'>SHARC /CHOP=c/INT=i',
where,
i=2*(time per nod)
c=nods/2=(total integration time per file entry)/i

Such an integration can be commanded by a 'chop 1' in the UIP. To make 10 such integrations (10 entries in the file) simply type 'repeat 10 chop 1' in the UIP window.

Note.: Using 'chop N' as a UIP observing command is identical to setting 'SHARC /CHOP=N' and then observing with 'chop 1'.

Doing longer integrations per nod will reduce nodding overheads, but will increase sky noise contribution. The suggested setting offers a reasonable compromise, but feel free to tinker with it if you have other preferences.

SHARC NEFD and Observation Time Planning

The official approximate SHARC NEFD as a function of tau (225 GHz), as published on the CSO web-page, is calculated for pure on source time (time that the telescope is strictly looking at source). This is a good number for the bolometer performance but it is of little use when planning observation time. The NEFD value that you should use to estimate observing time is roughly a factor of 2 higher (off-time, chopper [in]efficiency and nodding overheads), and is slightly dependent on chopper settings. The reason for this is that actual observation time is ca. 4 times the pure on source time (see above). Thus, near Zenith observations will have an NEFD of ~2Jy/sqrt(Hz) [real-time] rather than the quoted 1Jy/sqrt(Hz) [on-source time] at tau (225 GHz) ~0.04. This is merely a matter of convention (on what time to use), but can cause quite some confusion...

Doubts about pointing certainty

As mentioned being uncertain in the ZA pointing is a less disastrous affair, as your source will still be on the array, only in a different pixel. However, being off in AZ would be more of a problem. Lucklily, the AZ pointing offset (FAZO) seems a lot more stable (~1-1.5" rms), and also SHARC pixels are larger than beam in this direction (10"), which is a comfortable size, not to worry too much about it. However, if, for some unforseen reason, there would be reason to seriously doubt the AZ pointing accuracy, one may compomise some sensitivity for a secure measurement of flux (or upper limit). A possibility is to use the array as if it had two rows (now with 20" in azymuth), surely large enough to have the source inside (if really desperate can also use it as 3, although down in sensitivity by a factor of 3 in integration time). Best way to do this is to generate an integration file. Suppose you want the equivalent of a 'repeat 10 chop 1', then write a text file in your home dir on the USER disk, with the following content (with appropriate values for chop throw inserted, of course):

sec xx 4.123 5 5
azo -5
chop 1
azo +5
chop 1
azo -5
chop 1
... (10 times)

You can still just sum all files in BADRS. Your source should now certainly be contained with its entire flux. The downside is a sqrt(2) increase in the apparent pixel noise for the given integration time... May be worth it, if there is no way to be sure otherwise. :-)

Last Updated 9 May 2000, by Attila Kovacs, attila@socrates.caltech.edu