Dec2016 FNAL Test Beam Log

12/4

• ドミトリーの鍵の受け取り@Communication Center
• Fermi Test Beam Facility（FTBF）の下見
• 行なうべきWebトレーニングのうち終わっていないもの（Radiological Workerなど）の消化

12/5

• Fermilab IDを取得
  
  User's Officeにてパスポートと海外保険の証明書を提示→承認メール受信→Key and ID Officeにて写真撮影し交付
  
  ※海外保険は必ず入っておくこと。また、クレジットカード付帯のものは証明書発行まで1週間ほどかかる上に保障額が少ない。出張費扱いになるので必ず入るように。
  
  なお、緊急の場合、出国後でも加入できる保険がある。（ https://www.worldnomads.com/travel-insurance/ ）
  
  
• 届いている荷物を回収、確認
  
  EMSで11/28に送ったもの以外は届いていた。
  
  EMS日本郵便追跡番号リスト EJ228871277JP EJ228871246JP EJ228871285JP EJ228871263JP EJ228871229JP
  
  12/5 13:16に届いていることを確認
  
  
• 借りるべきものの手配
  
  
• SVX4 telescope, FEI-4, FE65p2のintegration

TLU

• LVDS以外は動作確認（LVDSは確認手段がないので、とりあえずFE65のアダプターカードにはLVCMOSを入れている）。
• 磁場テストのFirmwareを改造。扱う信号とdaughter card分の信号を拡張および変更した。TriggerをエミュレートしてTriggerを配るテストを実施。
• SVXへNIMレベルの疑似Triggerを1Hzで配り、イベント収集に取りこぼしがないか確認。→7分の1位lossしている。
  矢島さんに相談。
  結局、Triggerのレートを上げることでこの問題は解消した。
• FE65 Adaptor cardへLVCMOSレベルの信号を配り、extriggerでの動作確認を実施。
  →Triggerに反応していない模様。
  →Trigger INとOUTが逆になっていた。FirmwareをTimonに修正してもらう。
  →Triggerに対する反応を確認。
  →ただしBusyが見えない。Firmware段階でのミス。

HSIO2

SVX

• SVXへNIMレベルの疑似Triggerを1Hzで配り、イベント収集に取りこぼしがないか確認。→7分の1位lossしている。
  矢島さんに相談
  →SEABAS2のBUSY信号が原因。
  Preamp reset(2usec)とパイプラインリセットの長い信号が出ていることが原因。
  特にパイプラインリセットの長い方のBUSY信号に引っかかっている。
  これはBUSY信号がトリガーレートに同期してしまっているため。
  トリガーレートを例えば100Hzや200Hzにするとこの問題は解決した。
• 上記の問題に関して、SEABAS2のファームウェア上でPreampリセットをOFFにする機能がある。
  top.vのL720で、SetPerstVetoParam()からリセットの長さを指定できる。
  top.vのファイルはsctjdaqp/FPGACodes/TLUの中にある。要求があれば対応可能。
• Daughter Boardは3.3Vで良いのか？(SVXの仕様上は2.5Vだが)
  →良い。レギュレータで調整している。3.4VくらいまではOK。
  わざわざ3.3Vと高くしているのは、レギュレータがヘタっているため(by矢島さん)

12/6

TLU

• 宇宙線を用いてMPPCが4つ全て動作すること、正常にcoincidenceが取れNIM信号が発行されていることを確認した。線源欲しい。

HSIO

• TriggerはNIM1,2でBusyはNIM3,4となっている
• Busy信号は200nsec程度
• Cosmic GUiをExt Triggerで動作確認　→ 1kHzでイベントが進むことを確認

SVX

• SEABAS2に入れる、TLUからのタイムスタンプ用のクロックはNIMの100kHzクロックにする。
  この際ズレることは考えられてはいない。
• SCTJDAQのオンラインプロットのヒストグラムのデータを処理するPostProcessingを使えるようにした。
  細かく言うと、オンラインプロットの結果は一時的にsvx_ana.rootという名前で保存されるが、リネームせずに次のRUNを走らせると上書きされてデータが消えてしまう。そこで、リネームする機能をpostProcess.pyによって実装している。
  pythonスクリプトが不必要なファイルを読み込もうとしてTracebackを出し続けていたが、修正して正しく動作するようにした。
• 解析プログラムhitmakerでのスレッショルドの値の設定が気になっている。hitmakerの出力ファイルが空であったため。
  telehitmakermethod.cppのなかでスレッショルド決めている。L158のIsOverThreshold()あたりを探る。

12/7

セットアップ

• ビームテストに必要なものをビームラインへ移し、組み立てた
• inspectionが行われ、受理された
• ネットワーク環境
  ビームラインの隣にSw-Hubを設置し、各FPGAを接続。イーサネットケーブルはビームラインの隣の壁面状のPatch Panelに接続(P1Q1)
  Control Roomへ繋がっており、室内のPatch PanelからSw-Hubへ接続。このSw-Hubから各DAQ PCへと繋がっている。
  IP Adress

name	IP adress
atlasj	192.168.7.43
atlassi01	192.168.7.77
KEKSiPC (Main DAQ)	192.168.7.15
Raspberry pi	192.168.7.35
SVX PC	192.168.7.22

HSIO

• HSIOの番号の対応

• HSIO module Chip

• HSIO	module	chip
  A0	KEK83
  A1	KEK114	4
  A2	KEK101	2
  A3	KEK104	3
  A4	KEK113	1
  A5	KEK113	2
  A6	KEK113	3
  A7	KEK113	4
  B0	KEK115	1
  B1	KEK115	2
  B2	KEK115	3
  B3	KEK115	4
  B4	KEK112	1
  B5	KEK112	2
  B6	KEK112	3
  B7	KEK112	4

• このうち使うのは、KEK83(single chip), KEK114(RJ4), KEK101(RJ2), KEK104(RJ3), KEK113(RJ2), KEK115(RJ3), KEK112(RJ3)　である。

SVX

• ビームライン上への設置は終了。
• リモートコントロール環境が整った。
  SEABAS2 ←→ Sw-Hub ←→ Patch Panel ← | → Patch Panel ←→ Sw-Hub ←→ SCTJDAQ PC
• Control RoomからSVXとの通信環境は確立した。configは通っているので接続は大丈夫と判断する。
• Timestamp用100kHzクロック信号のNIMケーブルはまだ挿さっていない。
  他のDAQはTimestamp情報を付与しないようなので、SVXのみTimestampをつけることにしたい。

12/8

Summary

HV settings

Sensor	HV source	GPIB Adress	cable #
FEI4	6517	28	A4
FE65	6517	29	A2
MPPC	2410	24	A3
SVX	2410	10	A1

LV settings

TLU Trigger Logic

Signal	Connector	comment
MPPC Trig 0		-
MPPC Trig 1		-
MPPC Trig 2		-
MPPC Trig 3		-
ROI Trig HitOr		-
Trig for HSIO2		-
Trig for SPEC		-
Trig for SVX
Busy from HSIO2
Busy from SPEC
Busy from SVX
LVCMOSout1	LVCMOSout1
LVCMOSout2	LVCMOSout2	picoscope A
LVCMOSout3	LVCMOSout3	picpscope B
LVCMOSout4	LVCMOSout4	picoscope C

HSIO

SVX

• 9時ごろ、HDDの容量が残り少ないので,外付けHDDに一部データのバックアップを実行。
• 午前中、SVXの動作確認テストを行った。SCTJDAQではなくtele_softを使用。
  configが本当に通っているのか、ペデスタルの設定を変えて見て変化が現れるかをチェックした。
  1208_optest : 適当に走らせたデータ。動作チェック。
  1208_optest_2 : Telescope No.0のRampRngを000に設定。ペデスタルの値40程度。
  1208_optest_3 : Telescope No.0のRampRngを010に設定。ペデスタルの値90程度。
  1208_optest_4 : Telescope No.0のRampRngを001に設定。ペデスタルの値65程度。
  1208_optest_5 : Telescope No.0のRampRngを011に設定。ペデスタルの値128程度。
• 午後、気になっていたHV Currentの再チェック。
  壊れている可能性があるTelescopeはNo.2
  保護抵抗なしでDirectにHVをかける。
  No.2 TelescopeのHVケーブルを外す → I < 3μA at 80V
  No.2 TelescopeのHVケーブルを接続 → 10VでCurrent Limitを超える。limit値の105μA以上流れ始める。
  → No.2 Telescopeが確実に悪い。
• No.2 Telescopeを取り外してワイヤーボンドを顕微鏡で確認した。
  Rear側センサーとASICの間のボンディングがぐしゃぐしゃ。前に山元くんがここから8本ピンセットで外した。ただしここはHVとは直接関係しない場所である。
• 花垣さん、No.2 TelescopeのRear側センサーのHVワイヤーボンドをカッターナイフで切断。
• その後、10Vかけたところで結局105μA以上流れてしまって先ほどと結果が変わらない。センサーのどこかに異常があるのは確かだと思われるが詳しい原因はこの時点では不明。
• (17:30)ビームラインへ伸びていたNo.2 TelescopeへのHVケーブルの先は養生テープで覆って使用不可能にした。もうHVをかけて使わないので。
  * 残り3枚のTelescopeのHV Currentをチェック。HVケーブルには保護抵抗が入っている。
  Current Limitは10μAに設定。

HV[V]	Current[μA]
10	~1
20	~1.2
40	~1.3
80	~1.6

大体以前のビームテストの時と同じようなCurrentで、流れすぎるという問題は起きていない。

• (18:00頃)残りのテレスコープ3枚でDAQを走らせることを考え始める。
  • 4枚の時のままのconfigをそのまま通すとERROR。そのままではダメなようだ。DaughterBoadのフラットケーブルの位置を変えても同じ。

12/9

SVX

• テレスコープ3枚でDAQを走らせることが可能に。死んだと思われるNo.2 Telescopeは調査できるようになった。
  解決方法はsctjdaq/SVXTools/tele_soft/include/svxcommon.hのTELESCOPE_NUMを書き変えること。
  4枚に戻すとき、あるいは5枚以上追加するときもこの部分をいじることで対応できる。

12/10

山元より

Cooling BoxとSVXのGas flowについて

シフターのすべき事をまとめました　 gas operation

次回のタンク交換は12/12月曜日午前中です。

---

TLU

現状：ROI triggerも受けられるようなFirmwareのエミュレートが完了。

have to do list

• SiTCP 経由でdataをよむ。（タイムスタンプ付きで）
• runのstart stopを統合する。現在のままでは各DAQシステムのスタートを揃える為には、全てのDAQを開始した状態でFirmwareをやくという手段を取らざるをえない。
• Tree形式で Event Number, Hit point(x, y), の情報を持ったファイルを出力しそれらを読み込んでEvent displayを作る。

HSIO

現状：12/9にtuningが完了し特に問題が見られなかったのでMaskし始めた。

問題点：Noiseが全体に広がる問題が起こり、全てのchでMaskされる可能性がある。

方針：HV, 温度などの条件が変わるとtunigし直さないといけない。

12/7のlogにまとめてある表のうち、使用するチップは

KEK114(RJ4), KEK101(RJ2), KEK104(RJ3), KEK113(RJ2), KEK115(RJ3)

となった。

SVX

現状：Mask Scan, Threshold Scan完了。

online monitorを作るためのrootファイル(Tree)の出力を試みた。

問題点：run中にTreeConverterを走らせるとDAQが止まる。

16:40頃から、特に操作せずともDAQが止まる問題(18:34〜Meeting中に問題が再現するか確認。40秒ほどで止まる事が2回中2回確認された)が生じた。

TCPの接続が不安定な事が原因(?)

方針：SVXのDAQ PCをビームラインにおき、SVXのSEABAS2をDAQ PCに直接つなげる。

FE65

現状：500eでtunig完了。

問題点：noise scanにおいて、leakage current compensationがないところでnoiseが多い。

方針：極めてnoisyなpixelのみMaskをかけるようにした。

12/11, 12/12

beam status

今年中にFTBFエリアにビームが出る可能性は極めて低い。

ビームを曲げるためのワイヤが切れたことが主な理由である。

ワイヤの交換を行うにはビームを止める必要があるが、DOEの要請からニュートリノ実験のためにビームは止めることができないとのこと。

TLU

現状：TimeStampを発行し、各検出器でEvent Numberのずれがないかを確認するため、SVX以外にもTimeStampを配れるように変更。

問題点：書き込みに時間がかかるため現在のtriggrt rateの1 kHzに追いつかない。

方針：rootファイルへの書き出しをやめてbinaryファイルにすることでこの問題を解消する。

HSIO

• HSIOからのデータをオンラインモニター用にCnvertするようにプログラムを書き換え中。
• 解析プログラムの雛形は完成した。
• Cosmic GUIは走らせ続けている。
• Thresholdは昨日から安定している。以前にThresholdが崩れた(ダブルピークになるなど)のはHV環境が原因と推測。

SVX

• 12/10のlogにあるDAQが止まる問題は、SVXとの接続を変更することで解消。
  
  DAQ PCとSEABAS間のEthernetケーブルの長さの問題、またはSwitching HUBが原因と推測。
  
  優先度はともかく、この推測を確かめるテストを行う予定。
  TreeConverterをDAQ中に走らせるとDAQが止まる問題は、datファイルにread accessすることが直接的な原因ではないことがわかった。
  おそらく、ConvertすることでSVXとDAQ PC間の通信に負荷をかけることになるのでDAQが止まったのだと推測した。
  
  
• オンラインモニター用のデータ出力を可能にするよう編集中。
  datファイルにする前の段階で hitch や pipelineIDをFillしている行があるので、そこで標準出力またはテキストファイルに書き込みできるように編集する方針。

FE65

オンラインモニター用のデータ出力のためのConverterは準備完了。

Gas flow

およそ見積もり通りであったが、12/12 9:08~17:28までほとんどN2タンクの残量が変わっていないことが疑問である。

それまでの残量の記録をまとめる。

記録時間	TUBE3 残圧（N2タンク1次圧）	TUBE8 残圧（N2タンク1次圧）	comment
12/9 18:03	10.9 MPa	14.6 MPa	TUBE3のみOPEN 流量は3 SCFH~1.5 L/min
12/10 10:23	8.4 MPa	14.6 MPa
12/11 10:31	4.7 MPa	14.6 MPa	10:50頃CMSのグループから流量を下げるよう言われたので、1.75 SCFH~0.9 L/minに変更。
12/11 12:27	4.6 MPa	14.6 MPa
12/11 17:05	4.2 MPa	14.6 MPa
12/12 9:08	2.7 MPa	14.4 MPa
12/12 15:21	2.6 MPa	14.4 MPa	ほとんど減っていないので、　12日にタンク交換予定であったが13日に変更。
12/12 17:28	2.6 MPa	14.4 MPa

SVXのHVカレントはほとんど安定しているので、N2 flowとしては 1.75 SCFHで十分だと判断した。

HV:80 V, ~2 uAに対して、LV:3.3 V, ~4Aであるので、発熱量としてはLVが優勢である。

実際、12/11 19:51から行ったSVX DAQ長期安定テスト中は、0.3uAほど(10%強)HV currentが増えている。

12/13

FE65

温度-25degCで再チューニング

Thresholdを下げようとするとanalogの応答が返ってこなくなるピクセルが多数
→ PrmpVbp を100にあげることで解決（以前Timonから頂いたアドバイス）

500eでtuning成功

データ:
digital 123
analog 121
threshold 122
tuning 120
noise 125

SVX

• SCTJDAQにオンラインモニター用にバイナリデータをデコードしてrootファイルを作る部分を参考にして、テキストファイルで出力することを試みている。
  sctjdaq/SVXTools/tele_soft/src/logger.cpp
  sctjdaq/SVXTools/tele_soft/include/logger.h
  に関数を追加。
  動作テストをするにはSCTJDAQをコンパイルしてDAQを再試行しながら見る必要がある。
  DAQが遅くなるようならば別の方法を考える。
  例えば、ファイルの更新があることを毎回判定してバイナリデータをデコードして保存する等。やり方は調べないといけない。
• 上の方針はやろうとしていることに合わない。現状のTreeConverterにgetterメソッドを追加する程度で良い。

12/14

beam status

TLU

HSIO

FE65

SVX

• OnlineMonitor 用にバイナリデータのデコーダを書いている。設計方針はfixされた。
  確認のために書いておくと、EventNumber, Timestamp, hit ch X, hit ch Y, adc, pipelineIDのデータを出力して、他の検出器とのCorrelationを同時に見られるようにすること。
• class SVXconverter {
  private:
  string filename;
  ifstream infile;
  int xx;
  int EventNumber;
  

  public:
  SVXconverter(string filename);
  ~SVXconverter();

  void GetAnEvent (int &eventnum, int *xx);
  void GetEvent (int EventNumber);
  void GetNextEvent ();
  };
  のようなテンプレートクラスに沿って設計。現在のTreeConveterとは異なるが、getterはひとまず実装済み。
  イベントナンバーを指定してイベント情報をgetできるようなメソッドを実装する。これが結構難しいというか面倒な部分。

[Remain Task]

• LANケーブルの長さ？によるTCP connectionエラーの再現性のチェック
• 死んだNo.2 SVX Telescopeの原因調査
• 解析プログラムTestBeamAnaの改良。

Gas flow

流量とタンク残圧に関するまとめ。

gas_tank_summary

Cooling box 環境

box内の温度、湿度、気圧に関する簡単なまとめ。

cooling_enviroment

12/15

beam status

TLU

SVX

• SEABAS2とSCTJDAQ PCとのTCP connection errorの原因調査を行なった。
  [ 安定している環境]
  8ポートのうち、PATCH PANEL;SCTJDAQ PC;KEKSiPC;RaspberryPiが接続されている。
  2本は先に何も繋がっていない、テスト用ポート。
  [ 構成1]
  SEABAS2をSw-Hubに、SCTJDAQ PCもSw-Hubに接続した。
  この時のSw-Hubはビームホール内の物(阪大から持参)である。LANケーブルの長さは2本とも7m程度のものである。
  SVXのデータはSCTJDAQ PCの外付けハードディスクに保存され、これをKEKSiPCから見られるようにNFSクライアントを立ち上げて参照できるようにしている。
  そのため、SEABAS2とSCTJDAQの2接続が必要になるのでSCTJDAQ PCから2本のLANケーブルを伸ばしている。なお、ethernetポートが1つしかないので、SEABAS2にはLANポートを、共有NetworkにはUSB Ethernet Adapterで接続している。
  [結果1]
  上の状況では、SCTJADAQ PCとSEABAS2のTCP connectionの確立までに10秒程度時間がかかる。
  11:20にDAQをstartしたが、その3分後イベントが増えなくなる。TCP connectionが途切れる。この時約42000eventsほど。
  [ 構成2]
  共有Networkに接続せず、Sw-Hubのみ経由でSCTJDAQ PCとSEABAS2を接続する。
  [結果2]
  TCP connectionは意外にもあっさり通った。
  11:24にDAQをstartした。1分後TCP connectionが途切れた。
  [結論]
  Sw-Hub経由でSCTJDAQ PCとSEABAS2との通信を行うと、通信が不安定になることがある。
  [考察]
  Sw-Hubを介すると通信が不安定になるのはなぜか？
  一つ考えられるのはrootingの不具合。なぜおこるのかはハブの仕様を知らないとわからない。
  また、SOIグループではSEABAS2をSw-Hub経由でDAQ PCと通信しているが、このような通信の不安定性は見られないという。
  ファームウェアの問題という可能性もあるが、これは調査に知識と時間がかかる。
  何が問題かはもう一度阪大で精査する必要がある。
  [問題の回避策]
  SEABAS2とSCTJDAQ PCは直接イーサネットケーブルで接続するようにする。
• OnlineMonitor の開発
  SCTJDAQで出力されるバイナリファイルのデコーダを開発中。EventNumberを引数にすればそのイベントの情報を出力するメソッドは実装したがデバッグがまだ必要。
  telescopeごとにhitchとadcの値を出力するが、全部同じになってしまっているバグ。早く直す。
  今のところバイナリデータを前からreadしながらストリームの位置をシークしているが、イベントヘッダからイベントデータサイズ(byte単位)のみ取得してその分だけストリームの位置をシークするようなコードの方がスマートな気がするので、動作速度に問題、余裕があればその方針でも考えて見る。
  SVXconverter.hh(未修正版)
  

  [Remain Task]

  • 死んだNo.2 SVX Telescopeの原因調査
  • 解析プログラムTestBeamAnaの改良。

12/16

12/17

12/18

12/19

12/20

12/21

12/22

-- Atlasj Silicon - 2016-12-06

Comments