Dec2016 FNAL Test Beam Log
back to
FermilabTestbeam
12/4
- ドミトリーの鍵の受け取り@Communication Center
- Fermi Test Beam Facility(FTBF)の下見
- 行なうべきWebトレーニングのうち終わっていないもの(Radiological Workerなど)の消化
12/5
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 |
KEKSiPC (Main DAQ) |
192.168.7.15 |
atlassi01 |
192.168.7.77 |
atlasj |
192.168.7.43 |
SVX PC |
192.168.7.22 |
Raspberry pi |
192.168.7.35 |
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
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
Gas flow
流量とタンク残圧に関するまとめ。更新しました。
gas_tank_summary
Cooling box 環境
box内の温度、湿度、気圧に関する簡単なまとめ。更新しました。
cooling_enviroment
12/16
午前:Fermilabのピクセル開発グループの研究室ツアー
午後17時以降:SeaQuest実験の施設見学
TLU
SVX
- SCTJDAQ PCとSEABAS2の通信の検証
外川さんと小野さんが居るのでいろいろ聞いてみました。
設定
IP address
- RaspberryPi: 192.168.7.35
- SCTJDAQ PC: 192.168.7.20
- SVX SEABAS2:192.168.10.16(デフォルト)
- KEKSiPC: 192.168.7.15
- TLU SEABAS2:192.168.7.16
一つのハブに上の全てを集約した状態[ 構成1]。
まず、SCTJDAQ PCが192.168.10.16と通信している時、つまりDAQが走っている時に、
sshで192.168.7.xと通信しようとすると、観測したところでは必ず通信が止まることを確認した。
システムログを見ても,パケット受信量は止まってから増加していない。
外川さん曰く、192.168.10.x系列と通信している時に、192.168.7.x系列が入ってくることが問題ということだそうです。
それが原因なら、突然通信が止まったという前日の記録を説明するには、止まった時に192.168.7.xと何らかの通信があったと考えるべき。NFSで共有ディレクトリを作っていて、そこに192.168.7.x系からアクセスがあるとまずいのか?
じゃあ全部192.168.10.x系列に揃えてしまえばいいのでは?となるが、TLUのSEABAS2とSVXのSEABAS2のIPがデフォルトのもので重複しているのでSVX SEABAS2のIPアドレスをEEPROMに書き込まれた値に変える必要がある。SEABAS2はデフォルト値(192.168.10.16)か、EEPROMに書き込まれた値(?)のどちらを使うかをジャンパーピンで変更できるので、重複させないためにはEEPROMに書き込まれた値の方を指定すれば良いということ。
ですが、その値が不明で矢島さんに聞いている途中。
pingで192.168.10.xxxを255通り試したが届いてない状態。
もしもIPアドレスが192.168.10.16しか設定されていないのなら、一つのハブにSEABAS2を直接つなぐ構成はやはりやめたほうがよさそう。
12/17
TLU
SVX
- SEABAS2のEEPROMにセットされたIPアドレス情報を得るためには、内部レジスタにUDPでアクセスすれば良いとのこと。
アクセスするにはsctjdaq/SVXTools/tele_soft/src/comm.cppの中の関数
int Comm::read_udp_data(unsigned int address, unsigned char* data, int array_size, int length, int output)
を使えば良い。
第1引数:最初のアドレス、第2引数:1byte情報を詰める配列へのポインタ、第3引数:配列要素数、第4要素:読み込むバイト列の長さ、第5引数:出力関係
間違ったアドレス空間を読んでいたので、後日やり直しする。
そもそもなんで記録されていないんだろう。
- SiTCP Utilityを使ってアクセスしてみる。
デフォルト: 写真
EEPROM: 写真
デフォルトの情報は納得できるが、EEPROMの情報はうーん?ソフトウェアの実装方法を知らないのでなんとも言えない。
- SVXconverter.hh
テレスコープごとのhitchとadc valueを表示できるようにした。
- ネットワーク接続問題は何もできていない。
12/18
SVX
12/19
11:00〜12:30 徳武さん空港送り
13:00〜14:00 FNAL打ち合わせ
15:00〜17:30 g-2、D0の測定器見学
SVX
12/20
DAQのIntegration Test
17:35 TLU run_number = 000008
|
Run Number |
Event Number |
SPEC |
144 |
1100836 |
SVX |
15 |
100074 |
HSIO2 |
90 |
100076 |
デバッグモード(1枚でもシンチが鳴ったらトリガーが出るモード)がオンになっていたのでオフにした。
17:45 Run_number = 000009
|
Run Number |
Event Number |
SPEC |
145 |
1100033 |
SVX |
16 |
100001 |
HSIO2 |
91 |
100003 |
Comment:
17:50 Run_number = 000010
|
Run Number |
Event Number |
SPEC |
146 |
- |
SVX |
17 |
120143 |
HSIO2 |
92 |
- |
Comment:SPECが途中で落ちた。
17:54 Run_number = 000011
|
Run Number |
Event Number |
SPEC |
147 |
1735070 |
SVX |
18 |
157445 |
HSIO2 |
93 |
157447 |
Comment:TLUがEvent Number=157413から後、値がおかしい。
18:06 Run_number = 000012
|
Run Number |
Event Number |
SPEC |
148 |
1730388 |
SVX |
19 |
157306 |
HSIO2 |
94 |
157308 |
Comment:さっきと同じ。
18:22 Run_number = 000013
|
Run Number |
Event Number |
SPEC |
149 |
1730454 |
SVX |
20 |
157312 |
HSIO2 |
95 |
157284 |
Comment:TLUがEventNumber=157000くらいでDAQが飛んだ。改良。
18:40 Run_number = 000014
ゴミ。
18:44 Run_number = 000015
|
Run Number |
Event Number |
SPEC |
151 |
2200219 |
SVX |
22 |
200018 |
HSIO2 |
97 |
200020 |
Comment:200000イベントより多いのは、while文を抜けてもトリガーをまだ送っていたから。
SVXとHSIO2は常に2イベントずれてる。SPECは11倍くらい。なんでや。
18:56 Run_number = 000016
|
Run Number |
Event Number |
SPEC |
152 |
2200220 |
SVX |
23 |
200018 |
HSIO2 |
98 |
200020 |
Comment:200000イベントより多いのは、Softwareが200000イベントきたと判断してからstop信号を送るため、その間に20msecラグがあるから?
stop run(トリガーを止める)ならトリガーの数で決まるので良いのでは?
19:06 Run_number = 000017, TLU Ev_Num=103278
|
Run Number |
Event Number |
SPEC |
153 |
1141305 |
SVX |
24 |
103753 |
HSIO2 |
99 |
103755 |
Comment:SVXのイベントナンバーがHSIO2よりも2だけ少ないのは常に見えてる。これが常なら後で合わせればいい。TLUとSVX,HSIO2とが500くらいずれているのは謎。
とりあえず動くDAQはできた。とりあえず。
MPPC
一番下流側は死んでいた。3枚線源を当てて生存確認。
TLU
HSIO
SVX
- SVX4の読み出しに使っているSEABAS2のEEPROMの中のMACアドレスを変更した。
MAC ADDRESS : 7C:F0:98:01:08:DE
IP ADDRESS : 192.168.7.20 (temporary)
TCP Data Port : 24
UDP Port : 4660
- SCTJDAQ SoftwareのIPアドレスの部分だけを変更してコンパイルしても、Iinitializeはできるがconfigを通そうとするあたりで通信先を見失う。
しばらく待つとsegmentation fault。 ログ。
とりあえずこの件は保留。
他にもEEPROMの設定値を設定し直さないといけないのかもしれない。TCP command Port番号が65535のままとかが悪さをしている?
ソースコードを調べないとわからない。保留。
- DAQは、SEABAS2とDAQ PCを直接繋いでデータを取ることにする。
- SCTJDAQのRUN NUMBERの出力先の変更
(sctjdaq/gui/sctgui.pyの中で設定します。DAQはpythonスクリプトを走らせるだけなのでコンパイルは不要。)
変更前 : sctjdaq/gui/run_number.txt
変更後 : //media/SVX_TELE/svx_data/data/run_number.txt
- SVXのDAQの流れ
1.DAQの立ち上げ
2.configファイルの読み込み
3.setupボタンを押す(initialize)
4.statusに全てLOADEDが表示されていることを確認する。DEAD, Noneが出たらプロセスが走っていないか通信ができていない。
5.configボタンを押す
6.statusが全てCONFIGUREDになっていることを確認する。
7.startボタンを押すことでDAQがスタート。statusがRUNNINGになっていることを確認する。最初のトリガーが来るまではEvent NumberとData Rateが変な値を表示しているがこれは仕様。run_numberはこの時点で+1増える。
8.stopボタンを押すとDAQがストップ。
9.この後もう一度startボタンを押すとDAQが走るかに思えるが、なぜかバグる仕様。Kill DAQボタンを押して3に戻ってください。
12/21
片付け予定日午前中、β線源を当ててヒットマップを見てみるテスト。タイミングスキャンも。
午後、片付け、何を持って帰るか決める。
Run_number = 000017 / Start : 20:14 20/12/2016 / Stop : 09:20 21/12/2016
TLU Ev_Num = 46672186
|
Run Number |
Event Number |
SPEC |
154 |
46672251 |
SVX |
25 |
46672266 |
HSIO2 |
101 |
46672271 |
Run_number = 000022 / 11時頃 21/12/2016
TLU Ev_Num =
|
Run Number |
Event Number |
SPEC |
|
|
SVX |
|
|
HSIO2 |
|
|
Comment:全てタイミングスキャンなし。FE65にβ線源(Sr90)を当てた場合。ヒットっぽいものが見えた。
Run_number = 000023 / 11時頃 21/12/2016
TLU Ev_Num =
|
Run Number |
Event Number |
SPEC |
|
|
SVX |
30 |
38983 |
HSIO2 |
106 |
39012 |
Comment:
シンチのみにβ線源(Sr90)を当てた場合。ヒットっぽいものが見えた。
FE65以外はビームでのタイミングスキャンがやはり必要。β線源でそれをやるのは非効率的。
TLU
HSIO
SVX
- タイミングスキャン無しではやはりβのヒットは見えなかった。当然と言えば当然。
片付け
各グループ持って帰るものリスト
12/22
帰国予定日
昼ごろまでに空港に出発。
12/30
KEK115の動作確認開始。作業ディレクトリはatlasj note(HSIO2のオレンジのシールが無い方)の ~/Dropbox/FEI4tunings/HSIO2/test20161230
CalibGui のソースにマンチェスターエンコーディングを追加→成功。
Digital test→RJ4が通らない 抜くとうまく走り特に問題は見られない。key 1
Analog test →前回のテストビームで見られた各チップの中心に広がるノイズは確認できず。下の方がちょっと汚いが状態は悪くは無い。
tuning -2400e
Digital ..,ok
Analog ...RJ3に応答なしピクセル多数あり
あ GAが113のままになっていた(正1243)Digital Analog ...ok key=26,27
tuning ...ok th key 47
fnalのconfig fileを調査KEK115 RJ4のGAが6になっていた。
KEK113 tuning ...ok at 2400e
key=20
SELF_NOISESCAN下の方に筋状にノイズがひろがる
→以前から見られている問題を再現した。
原因はなんだろう。
1、レギュレータ
2、エンコーディングが悪さをしてたり・・? → 今日調べてみる
3、フレックス固有の問題? → 正月明けにフレックス以外のモジュールでレギュレータを使ってみたりいろいろ。
マンチェスターエンコーディングの部分をコメントアウトして再度コンパイルしてみる。→まったく関係なし(コードは戻した)
--
Atlasj Silicon - 2016-12-06
Comments