ASTE OTF立ち上げ

澤田 剛士・鎌崎 剛 他 （2005/03/10 ASTE会議資料）

スケジュール・作業の概要

• 1/9--1/13
  • 動作試験用指示書の作成
  • OTFおよびポジションスイッチの動作確認(COSMOSに改修が入ったため)
  • リダクション環境の整備(ほぼ45mからのコピー: ASTE環境固有の問題への対処など)
• 1/14--1/18
  • aobsのOTF対応
  • 動作確認(観測→データ取得→リダクション がひととおり行えることの確認)
  • バグ出し
• 1/19--1/27
  • アンテナ駆動性能測定(スキャン中のトラッキングエラーの測定・ approach, transientに必要な時間の決定)
  • 機能確認
  • バグ出し
• 1/28--2/4
  • 試験観測(OTFとポジションスイッチのデータ比較) 山口・池田他

アンテナ駆動性能の測定

OTF観測においてアンテナが安定に駆動されることを確認し、 助走(approach)および次の助走開始点への移動(transient)に必要な時間を決定するために アンテナ駆動性能の測定を行った(図1参照)。

図1：OTFスキャンパターンの概念図。

Approach時間 およびon-sourceスキャン中のトラッキングエラー

• 測定・解析 (Az,El)=(180^o,30^o), (180^o, 50^o), (180^o, 70^o)においてAzスキャンおよびElスキャンを行った。 スキャン速度は、天球面上で15, 25, 30, 50, 100 ["/sec]。 分光計のデータ読み出しは0.1秒ごとに行われるので、 345 GHzでナイキストサンプルを行うためには、スキャン速度は 100"/secが上限となる。 アンテナが開始点に静定後、approachが始まる設定。 100 msecごとに吐き出されるOTFアンテナログファイルから (Az,El)それぞれについてProg値とReal値の差を時間に対してプロットした(図2)。
• 結果
  • approach開始後しばらく経つと、Az, ElともProg-Realの値は 0に近くなる。0のまわりのばらつきの程度は、典型的に peak-to-peakで1" (Az), 2--3" (El)。
  • approach開始後 Prog-Realが0近辺に落ち着くまでの時間は スキャン速度に依存する。Prog-Realが1"以下に なるのは(スキャン方向により異なるが、典型的に) スキャン速度30"/secで2秒前後、 100"/secで3秒前後であった。
• 結論
  • 345 GHzのOTF観測に対しては、アンテナは十分安定 (peak-to-peakでAz 1", El 3")に駆動される。
  • approach時間は4秒に設定することを推奨する (遅いスキャンを行う場合は3秒で十分かもしれない)。

図2： approach開始後の時間(横軸)に対するアンテナProg値とReal値の差(縦軸)のプロット。 順方向(AzまたはElの増加方向)4スキャン、逆方向2スキャンを重ねてプロットしてある。 (a) (Az,El)=(180^o,30^o)におけるAz方向スキャン、 (b) 同じく(Az,El)=(180^o,50^o)、 (c) 同じく(Az,El)=(180^o,70^o)、 (d) (Az,El)=(180^o,30^o)におけるEl方向スキャン、 (e) 同じく(Az,El)=(180^o,50^o)、 (f) 同じく(Az,El)=(180^o,70^o)。

Transient時間

• 測定・解析 approach時間を4秒に設定し、Dec〜0^oの天体をOTF観測した。 スキャン速度v_scanと transient時間t_tranの組 (v_scan,t_tran) = (30 ["/sec],2 [sec]), (60 ["/sec],2 [sec]), (100 ["/sec],2 [sec])の場合について、approach時間中に アンテナのReal値がProg値に追いつくかどうかをアンテナログから調べた(図3)。 スキャン終了後、アンテナ(のProg値)はtransient時間で次のapproach開始点まで移動し、 そのまま静定を待たずにapproachを開始する設定。
• 結果
  • transient時間2秒では、2--3秒でReal値がProg値に追いついている(図3a,b)
  • スキャン速度100"/sec、transient時間1秒の場合には、 Real値がProg値に追いつくまでに約3--4秒かかっている(図3c)。 天体の位置やスキャン方向によっては、approach時間(4秒)内にProg-Realが 0に十分近づかないおそれがある。
• 結論 transient時間は2秒に設定することを推奨する。

図3： approach開始後の時間(横軸)に対するアンテナProg値とReal値の差(縦軸)のプロット。 (a) (v_scan,t_tran) = (30 ["/sec], 2 [sec])の場合、 (b) 同じく(60 ["/sec], 2 [sec])、 (c) 同じく(100 ["/sec], 1 [sec])。

環境整備

• aobsのOTF対応
• リダクションソフトのASTE対応

機能確認

• 観測座標系
  • (RA,Dec), (l,b)、およびそれらにポジションアングルをつけたもの
  • 太陽系内天体は現時点では不可
• 分光計
  • チャネル範囲切り出し、チャネルビニング、128 MHzモード/512 MHzモード、 一部のアレイのみ使用、ウインドウ関数(none, hann, hamm)
  • 周波数スイッチは開発中

現在の状況

• 指示書作成 aobsで可能。Scan patternに「OTF (raster)」という項目が追加され、 continuumと同様のインターフェースでスキャンパターンの指定を行う。
• 観測 通常の観測と同様に行う。QLOOKはない(来年度開発予定)。 生データは山頂の /cosmos3/aste/raw/otfdata/GROUP/PROJ/ に生成される。 データレートは分光計1本(1024ch)あたり約40MB/hr。
• リダクション F社製コマンド+天文台製GUI (IDL)。 現時点では山頂・山麓および野辺山でリダクションが可能。 機能はベースライン除去(多項式/sin)・bad dataのフラグ・マップ作成等。
• 今後必要な作業・測定
  • 最適な観測パラメータの決定(OFF点とOFF点の間に入れられるスキャンの長さ、等々 ...)
  • 周波数スイッチ対応
  • 2周波同時観測の確認
  • リダクション環境の整備
  • Webページの整備

Bug fix

• データ取得タイミングが間違っていた
  • ACGに入れる1PPS信号の位相が逆だった(1PPSの立ち下がりが積分開始のトリガーとなる。 位相が逆であったため、正秒に開始されるべき積分が500 msec前に始まっていた) → 正しい1PPSにつなぎ換え
  • 正しい位相の1PPSにつなぎ換えた場合、ACGへのSTART命令に起因する乱れが1PPSに乗り、 その立ち下がりを1PPSの正秒立ち下がりと誤認して積分が早く始まってしまっていた → START命令の送信タイミングを変更して回避
• 座標がRA方向に数arcsecずれることがある (WSとACUの時刻同期の微妙なずれに起因 → バッファを拡張して回避)
• 座標がスキャン方向に1.5点(150 msec)ずれる
  • ログファイルからRADECを計算する際に100msec前のAZEL値を使っていた (100 msec)
  • 観測点座標を積分の開始時刻におけるアンテナ位置から計算しているため(50 msec) → 開始時と終了時の平均値を使うように改修。 今回取得したデータについては未修正(再マージすればOK)
• マージが異常終了する (ログファイルで時刻の重複が発生していた)
• 異常な座標値が入ることがある (フラッシュされてない中途半端な状態のログファイルを読んでいた)
• 積分時間(秒)の下一桁が6, 7, 8, 9の場合に、スキャンの最後それぞれ1, 2, 3, 4秒間のデータがおかしい (バッファ処理のバグ)
• マップのポジションアングルを指定したときにXY座標に不正な値が入る
• R, sky, offのデータ取得後に不要な待ち時間が発生する
• etc....