ARTBLTestbeamLog202306

Article text.

-- Atlasj Silicon - 2023-05-11

--

事前準備

5/9(火) 今村

HSIO2&pc24接続確認

用意するもの

• pc24
• モニター(pc24の画面を映す)
• HSIO2(合体させておく)
• USB-etha
• ethaケーブル
• HSIO2電源(AC-4pin)

手順

1. pc24--USBetha--etha cable--HSIO2で繋ぐ
2. HSIO2の電源ケーブルを挿す *HSIO2の電源ON/OFFはACの抜き差しで行う
3. pc24右上の∴みたいなところをクリック→左下のばってんのロゴをクリック
4. ネットワーク(の設定)画面に移るので、今挿したEthernetの歯車ロゴ(右端)をクリック *今挿したEthernetがどれかわからないのであれば、HSIO2のACを抜けばわかる
5. IPv4のタブを選択
   • IPv4メソッド：手動
   • アドレス：192.168.1.70
   • ネットマスク：255.255.255.0
   • ゲートウェイ：192.168.1.1
   • DNS：デフォルトでONになっているのでそのまま
   • ルート：ONはそのまま、下の「この接続はネットワーク上のリソースのためだけに使用」のレ点を外す
6. Identityのタブを選択
   • 名前：好きな名前に変更…今回は HSIO2 にした
7. ポップアップ右上の「適用」をクリック
8. 今設定していたEthernetをオン/オフする(マウスでカチカチ)
9. terminalを開く
10. sudo systemctl restart dhcpd.service ... DHCPサーバを再起動
11. sudo systemctl status dhcpd.service ... DHCPサーバが動いているか確認 → 緑の●が出てきて動いていそうならOK
12. nmcli connection modify [HSIO2ip] ipv4.never-default true ... ネットワークをローカル用に使うことを認識してもらう。[HSIO2]の部分は6で決めた名前
13. 再び3,4の手順でネットワークの設定を開く → 5の最後で外した「この接続はネットワーク上のリソースのためだけに使用」のレ点がついていればOK
    →今回これが確認できず。12のコマンドが効いていない？5/11時点未解決
14. 再びterminalを開く
15. ping rce0 または ping 192.168.1.10 → 返ってくることを確認

pc24ディレクトリ準備

用意するもの

• pc24
• 時間

手順

1. /home/atlasj/work/ で cp -r FNALtestbeam202302 ARtestbeam202306 ... FTBFのディレクトリを丸ごとコピー(時間かかる)
2. 以下の内容物を削除
   • DT5742/data/
   • HSIO2/data/
   • HSIO2/rceconf/ ... rm -rf * _ _ * でkey番号を持つものだけ削除 ← 今回削除し忘れ
   • HSIO2/rceconf/configs/ ... rm -rf * fe0_ _ * でkey番号を持つものだけ削除 ← 今回削除し忘れ
   • KC705TLU /KC705TLU_Software/data/
   • KC705TLU /KC705TLU_Software/log/

5/11(木) 今村

ROI動作確認

用意するもの

• pc24とHSIO2の接続確認に使ったセットアップ
• 短etha x 4
• KEK114
• KEK112
• LV ... ＋1.2V/＋1.4VがかかればOK *今回はLGADで使用していたTEXIO PW8-3ATP
• HV ... -100VがかかればOK *今回はLGADで使用していたKEITHLEY 6517A
• 4pin molex ケーブル
• LEMOケーブル

電源をくべる

1. KEK114のHVとLVをつなぐ
   *LVのVDDAとVDDDはかける電圧が違うので間違えないように注意！タグ付け推奨
   *HVINとHitORを誤ってつながないように注意
   
   
2. LVの値を設定する
   • VDDA 1.4V
   • VDDD 1.2V
3. LV,HVともに出力させる
4. HVを-100Vまで下げる
5. 電流値に異常がなければ、KEK114 RJ45--短etha--HSIO2 RJ45で繋ぐ
6. ここまでで画像のようになっていればOK
   

CalibGUI を立ち上げる

1. terminalを開く
   1. ssh atlasj@atlaspc24.kek.jp
   2. (pc24に入った状態で) ssh root@rce0 ... pw:ユーザー名
   3. source setup.sh
   4. calibserver
2. 別にterminalを開く
   1. ssh atlasj@atlaspc24.kek.jp
   2. source daq/rce/scripts/setup-env.sh
   3. cd ~/work/ARtestbeam202306/HSIO2
   4. calibGui
3. ポップアップでグレー背景のGUI画面が立ち上がる

KEK114動作確認

1. ConfigFile 設定
   1. GUIの上部 [Update] [Save] [Save As] [Load] のうち [Load]をクリック
   2. ファイル選択の画面になるので /home/atlasj/wotk/ARtestbeam202306/HSIO2/rceconf/KEK114.cfg を選択
   3. [Load]横の Config Name が KEK114、Key: が空白になっていることを確認
   4. Config Root Dir: の横の [Browse] をクリック
   5. 先ほど同様ファイル選択の画面になるので /home/atlasj/wotk/ARtestbeam202306/HSIO2/rceconfに該当するようツリーをたどる
      *最後のクリックが [rceconf]。rceconf/内のファイルはクリックしない
   6. ファイル名を入力する部分に configs と入力して決定
      *configsのファイルはrceconf内に既に存在するが、それはクリックせずに名前を正しく入力すること
   7. Data Dir: の横の [Browse] をクリック
   8. 先ほど同様ファイル選択の画面になるので /home/atlasj/wotk/ARtestbeam202306/HSIO2に該当するようにツリーをたどる
   9. ファイル名を入力する部分に data と入力して決
   10. 上部 [Config Halfstave A] のタブをクリック → 1行目の4つ(Frontend A1-1...) それぞれ[included] [valid] の2つともレ点がついているか確認
       →今回はここでレ点がついておらず、手動でもうまくいかなかった。Chooseからrceconf/configs内のfileを選択したらレ点がついたので、KEK114.cfgが読めていない模様…
2. digital/analog scan
   1. RunNumber を適当に指定。この後自動で数字が増えていくので、データがない状態なら0から始めるのが無難
   2. Scan ConfigのScan Type: プルダウンから [DIGITAL_TEST] を選択
   3. Tuning Parameters: を Target threshold:3000 / Target charge:10000 / ToT target vale:8 に設定しておく
   4. Analyze/Save Histos と Use Manc. Enc. にレ点がついていることを確認
   5. [Start Run] をクリック
   6. 少し待つと走り出す
      • このとき電流/電圧値を確認・記録する
   7. terminalに Done と表示されたら完了
   8. 上部右端 Plots から Plot を表示させて確認 → Occupancyで全体が真っ赤(or 50cntsに該当する色)ならOK
   9. 2から同様の手順を [ANALOG_TEST]で繰り返す
      *RunNumberは自動で加算されるので操作不要
3. PrimList でtune
   1. Prim List の [Load Primlist]をクリック
   2. ファイル選択の画面になるので /home/atlasj/work/ARtestbeam/HSIO2/primlist/primlist_3000e_10keto8tot.pl を選択
   3. [Start Run] をクリック
   4. 少し待つと走り出す
   5. GUIにFinishと表示されたら終了(まあまあ待つ)
   6. 上部右端 Plots から Plot を表示させ確認
      • Occupancyの数字が大きいほうで真っ赤になってるか？
      • 2次元mapにパターンが大きな欠損が見えていないか？
      • 2つ目のファイルも開き、thresholdが3000になっているか確認 → thredistで3000中心のガウス分布が見えればOK
   7. Key番号をメモする
   8. GUI上部左端の [Update] をクリック
4. 線源を置いてSelfTriggerを見てみる
   1. 線源をKEK114のブラックテープがされている中心あたりに置く
   2. Prim Listの [Clear Primlist] をクリック
   3. Scan ConfigのScan Type:で [SELFTROGGER] を選択
   4. Start Run をクリック
   5. 60s~待機 *今回は100s
   6. [Running] をクリックして止める
   7. 上部右端 Plots から Plot を表示させ確認 → 線源の形が見えるはず

KEK112動作確認

上に同じ

今回の動作確認まとめ

• KEK114
  • Primlist結果　Key 37
  • Occupancy map : 良好
  • Threshold：良好
  • Self Trigger：線源がはっきりと見える
  • 電流値
    • VDDA 1.4V/1.04A
    • VDDD 1.2V/0.13A
    • HV -100V/-0.24uA
  • 問題点：KEK114.cfgが読めない
• KEK112
  • Primlist結果　Key 15
  • Occuoancy map：良好
  • Threshold：良好
  • Self Trigger：縞模様が見える。一応線源の位置はわかる
  • 電流値
    • VDDA 1.4V/1.05A
    • VDDD 1.2V/0.13A
    • HV -100V/-0.37A
  • 問題点：縞模様が見える。SigmaとSelf Triggerの結果で顕著

5/18(木) 比江森

HSIO2&pc26接続確認

pc26でHSIO2の読み出しができるようにSWなどをビルド --> なぜか動かない。

• calibGuiでscanを走らせるremote call timeout exceeded の例外が投げられて止まってしまう。
  • ping rce0 などは確認済み。dhcp daemonも動いていた
• pc24 からSWをまるまる移植して動くようになった。
  • calibGuiだと読み出しできていたのが，cosmicGuiで動かそうとすると先のエラーで再びabortされてしまう問題が再発。その後，calibGuiでもう一度scanを走らせようとすると同様のエラーが起きるようになって読み出しができなくなった。なんらかの原因でHSIO2とのcommunciation が取れなくなったから？
  • cosmicGui: FEI4 chipへのconfig がとおることもある。しかし，`cosmicGui: starting CosmicDataReceiver at tcp://33000`の空白時間があったのち，
    ```
    terminate called after throwing an instance of 'RCF:Exception' what(): 30: Remote call timeout exceeded. No resoponce from peer.
    ```
    の例外によって落ちる。これがひとたび起きると，cosmicGuiのみならずcalibGuiであってもconfigさえ通らなくなる。
  • HSIO2の電源引っこ抜きでやり直してみる→ config は通るようになる。
    eithernet の接触が微妙にではあるがずれていたので直した-> これがもしかして効いたかも。と思いわざと外して走らせると
    ```
    what(): unable to establsh network connection.
    ```
    と別の例外が投げられることが分かった。
  • FEI4 LV GNDとHSIO2 GNDを同じにしてみた。（コミュニケーションが落ちる問題と関係があるのか分からないが。。
    • 意味なかった。

KEK114

• 正常。primlist: 181

KEK112

• primlist: 181
• analog scanから結果がおかしい。真ん中あたりで応答が少なくなるような傾向
• GNDLV GNDとHSIO2 GNDを導通させてからのtuning(result: THRESHOLD_SCAN_000181) では改善した

5/22(月) 比江森

HSIO2 emulated trigger 受け取り with/ ROI x 2

• HSIO2はLVCMOSでトリガーを受け取る。

1. TLU adopter board のCMOSout からCMOS が出るようにピンをアサインしたFWをTLUに焼いておく。
2. 信号がちゃんとそのピンから出ているか，オシロとか使って確認する。
3. その出口とHSIO2 のTrigger のシールが貼ってあるピンとを接続する。
4. cosmicGuiを立ち上げる。読み出すFEI4の設定をインプットする（そのやり方は前述）。
5. できた気がしたら，Start Runをおす。
6. cosmicGuiが動き始めたら，emulated trigger を発出する。KC705_Software の./bin/startrun　で動く。
7. 辞めたい時はTLUを./bin/stoprunで止めて，HSIO2のRunnningをクリックしてrunを止める。

…とここまでやってみたが，cosmicGui上のevents: のカウンターが増えない。。確かにトリガーはTLUから出てきているので，HSIO2側の設定に問題がある？

-->cosmicGui上のGUI設定を適切な設定にしないと，外部トリガーを受け取ってくれない。例えば，以下が外部トリガーを受け取ることを確認している設定： IMG_4377.jpg

トリガーを受け取るだけなら，Latency とかConsec.Trigの値は特に関係ない（こいつらはヒットデータを読み出す際に必要）。重要なのは，

1. Trigger Sources には何もチェックを入れない
2. HSIO Ext.1 にチェックを入れて，LogicをORにする（Trigger のシールが貼ってあるとこに繋げた場合。もしその一個隣にさしたとしたら，今度はExt.2 が有効になる？多分。試してない）。
3. manchester Encoding 忘れずに

といったところ。

5/22(月) 今村・比江森

MPPC動作確認（今村・比江森）

用意するもの

• MPPC x4 +1
• HV (KEITHLEY 6517)
• LV (TEXIO PW18-3AD) ... +-5Vかかるやつ
• オシロスコープまたはpico scope
• 線源(Sr90)

picoscopeについて

電源をつなぎ、pc24にUSBを入力したが、picoscope とコマンドを打っても返事がない…今回は使用を断念

手順

1. HV、LVをつないでかける
   • LVは+-5V(逆にしないように)
   • HVは-55V~-60V程度
2. オシロスコープにプローブを付けて電源をいれる
   • 「テストに合格しました」となるまで電源を入れなおす
3. RJ45の耳にワニ口を付けてGNDをとり、プローブの先をSignal芯線に触れさせる
4. 線源を近づける
   • NIM信号が見えればOK
5. NIM信号が出ない・レートが低いときはHVを大きくする
   • 信号が見えればOK(1uAを超えるのはよくないかも…)
6. それでも信号が見えないときは、ANDのICへの入力をプローブで確認する
   • sig1 sig2 というやつ
7. 6で見えない場合、LM360(Comp1/Comp2)の換装が必要かもしれない

• 回路図を見ながら原因を特定していく --> https://cernbox.cern.ch/pdf-viewer/public/MiwFjlIDetdQ8BC/KEK/SciMPPCtrigger/MPPCReadOut_v5/MPPCReadOut_revC.pdf?contextRouteName=files-public-link&contextRouteParams.driveAliasAndItem=public/MiwFjlIDetdQ8BC/KEK/SciMPPCtrigger/MPPCReadOut_v5

今回の結果

• MPPC0
  • Comp2が死んでいる-->換装
  • Comp1は生きてる
• MPPC1
  • HV57 / 1uAでSignal確認
• MPPC2
  • HV56 / 0.6uAでSignal確認
  • HV55V でも信号見えるけど、レート低すぎる
• MPPC3
  • HV56 / 0.85uAでSignal確認
  • HV55V でも信号見えるけど、レート低すぎる
• MPPC yobi
  • HV 56 / 0.38uAでSignal確認

といったところ。

5/23(火) 今村・比江森

MPPC動作確認続き（今村・比江森）

MPPC0，SN75110A ICの換装を行なった（by 今村さん）。
換装後，LVDSドライバの動作確認を目的として，MPPCトリガーdout をTLUに渡してHSIO2がわにTrigBeam が出力されるかを全5台に対してテストした。測定のための要件は以下の通り…：

• MPPCボードのICを動作させるためのLV
• ヒット情報をTLUに渡すためのイーサケーブル
• HV用のLEMOケーブル
• dout を受け取るためのファームウェア
• Sr90
• HSIO2（TrigBeamを受け取ってイベントカウントをするスケーラとして活用）

一台ずつ付け替えてテストした。いずれも以前に設定した最適なHV設定のもとでLVDSが出力されてTLUからTrigBeamが出力され，イベントカウンタが増えることを確認できた。

ROI-NIM変換基板動作確認（比江森）

ROIが鳴ったことをTLUに伝えるためには，HitOR信号が用いられるが，TLUに渡すためにNIM信号に変換する必要がある。このNIM信号変換を行うのが通称ROI変換基板。MPPC基板を応用して作られる基板であり，MPPC基板と比べて載っているSMDやICが少ないのが特徴。載っているICの種類自体はMPPC基板で使われているものと同一。SMDも一緒かは現時点で不明。

この基板が正しく動作することを確認するためには，以下の準備が必要：

• self-trigger が動くことを確認できているROI
  • HitOr はself-trigger を行うために用いられる信号。この信号を外に出せるようにLEMOコネクタがROIに実装されているので，LEMOケーブルを用いてROIとROI-NIM変換基板のHVの印字があるLEMOコネクタとを繋げる。
• ROIのLV, HV
• ROI-NIM変換基板のICを動作させるためのLV.とはいえこれはMPPC基板に必要なものと全く同一。
• NIM信号を取り出すためのLEMO. TLUのNIMinに繋げる。
• Sr90

表面実装済みの基板は2枚あって，それぞれの基盤のバージョンがRev.B, ReV.C なので，便宜上Bボード，Cボードみたいに呼称する。
オシロスコープでプローブしたところ，Bボードの出力NIM信号は図　 IMG_4384.jpg　にあるような状態になっていた。立ち下がりがベースラインに戻っておらず，ダラダラ続いてく様子が見られる。このボードの入力を確認したところ正しく信号が伝わっていることを確認した。また，Cボードに関しては，NIM信号の出力が見られなかった。このNIM信号を出力するIC(SN75110AD)を今村さんが換装してくれた。再度測定してみると，今度はBボードで見られた傾向と同様な出力が見られた。そのため，少なくとも信号が出力できる状態になっていることは確認できたが，そのNIM信号波形がおかしいということまで確認した。

----> 線源を動かそうと思って取り除いてみたところ，線源を取り除いたら図　 IMG_4385.jpg　に示すような信号が出てきた。もちろんこの場合外部放射線由来のヒットではほぼないと考えれば，この信号はnoisy pixel 由来のものであることが分かる。線源をおくと再度ぐちゃぐちゃな信号が再発することがわかったので，レートが高すぎてICたちが対応仕切れてないことが原因な可能性が高い。この見た目の信号をTLUがNIMinとして受け入れてくれるかは気になるところだが，まずはKEK114のハエ叩きをするのが先決か。

5/23(火) 柳瀬

Cooling(日付に限らずここにまとめて記述します)

LV interLockの開発

• 使用する電源：HMP4040 (4ch LV)
• 通信はSerial通信
  • client side→USBtypeA、Server side→USBtypeB
  • ports = /dev/ttyACM0、baud = 9600(ls /dev/tty*)
• HMP4040_usb.pyに、電源との通信プログラムを記述
  • とりあえず最低限channel、OVP、OCP、voltage、current、Output ON/OFFをremoteで設定できるよう実装
• thermocontroll_interLock.pyにraspi温度読み出し＆interLockのプログラムを実装予定
  • 引数 -t {settemp}として、raspiで読み出す温度がsettempより上回った時にHMP4040のOutputをOFFにしたい
  • ntccalc.pyのVtoTの変換式、RtoTの変換式を応用してコードを書く(on going)
• raspi07に関してinterLockの実装完了(raspi03は考える)
  • raspi07で温度読み出すときは、thermocontroll_interLock.py　-t {interLocktemp(40℃？)}　を実行。引数tを設定しないとerror出る。
  • raspi07で繋がれている2moduleについてはいずれも設定温度を超えるとそのchのLVが落ち、アラーム音が一定間隔で鳴るようになっている。raspi03に繋がっているDUTの温度も確認して必要であれば手動でHMP4040usb.pyから落とす。

Peltier PS remote control

• 使用する電源：TEXIO PSF400L 、DP821A_924、DP821A_925
  • ITkTele ×2、ITkDUT×1に利用予定

【TEXIO PSF400L 】

• 通信はSerial通信(下に記述するDP821Aでも通信方法は全く同じ)
  • client side→USBtypeA、Server side→RS232 reverse(ストレートケーブル＋リバースアダプター)
  • Server sideはUSBtypeBだと反応せず...
  • ports = /dev/ttyUSB{i}、baud = 9600(※peltierPS3台のポート識別はおそらくraspiにUSBを挿した順番にUSB0,1,2,...という風に増えていくので適宜 ls /dev/tty*で確認してftdiPSFの部分を変更する)
• PSF400L _rs232usb.pyに電源との通信プログラムを記述
  • とりあえず最低限channel、OVP、OCP、voltage、current、Output ON/OFFをremoteで設定できるよう実装
  • Serial通信の関数の部分でerrorは出ていないが、電源でremote modeになる素振りがない、取説とにらめっこしながらやっていく(on going)

【DP821A_924,925(末尾は電源の識別番号)】

• 通信はSerial通信
  • 内容は上述したPSF400Lと同様
• DP821A _974,975_rs232usb.pyに電源との通信プログラムを記述
  • とりあえず最低限channel、OVP、OCP、voltage、current、Output ON/OFFをremoteで設定できるよう実装
  • このモデルは昔通信に浸かった時、命令と命令の間にsleep(3~5)を入れてあげないとだめだったらしい、今のところそこまで間隔空けなくても大丈夫そうだけどもし上手くいかなかった時はその点注意

• ARTB_peltierPS.pyで3つの電源を同時にremoteで制御できるように
  • テストビームで使うとしたら、チラーが止まるなどしてLVのinterLockが発動したときに、peltierの電源をOFFにして熱がこもらないようにする用途になる(これがモチベーション)
  • DP821A の2台はこのファイルで制御できているのでPSF400Lの通信を確立させて3台同時に制御できるように(ongoing)

• PSF400Lはリモートコントロールできず。。とりあえずこいつに関してはurgentではないので、LV落としてからbeamlineにaccessした時に電源落とす。

ITk Module

• HPK Quad moduleによるとKEKに存在する4chip読めるnon irrad moduleは以下の通り(5/23現在)
  • KEKv1.1Q08　→　KEKで見つからず。。
  • KEKv1.1Q14(fermiで使用)
  • KEKv1.1Q17(fermi予備)
  • PreprodQ01 　→　KEKで見つからず。。
  • PreprodQ03 (fermiで使用)
  • PreprodQ18 (v3.2flex)

• 3chip読めるのはPreprodQ15

• KEKv1.1Q14
  • #58179 std_threshold scan
  • chipname
    • chip1:0x13068
    • chip2:0x13078
    • chip3:0x1309b
    • chip4:0x1308b
  • chip4のEncorecolumn0を65535→65439に変更
    • これをしないとglobal tuneのLoopが途中で止まる＆thresholdscanの結果がパターン状になってしまう
  • 最終的には4chipとも読み出し可能！(fermiで見られていたダメージは消えていた、熱によるダメージっぽかったので時間経過で収まった？)

• KEKv1.1Q17
  • chip2、chip4のconfigを読んだときにLVが~0.2V/chipくらい下がる。
  • フェルミ以前に測定してくれた情報によると、chip4のEncorecolumn2:65535→4095にすることで読み出し可能とのことだったが、chip2,chip4いずれもループは回るが結果が出力しなかった。
  • trim,preampとも変えてみたが変動せず。
  • テストビームには使えない(HPKのところ修正しました)

• PreprodQ03
  • #58232 std_threshold scan
  • chipname
    • chip1:0x1302b
    • chip2:0x1302a
    • chip3:0x13027
    • chip4:0x13028
  • chip4の端に衝撃によるものとみられるdamageが少しだけ存在(fermi帰国後に見られていたもの)
  • 4chipとも読み出し可能！

• PreprodQ18
  • #58268 std_threshold scan
  • chipname
    • chip1:0x1593b
    • chip2:0x15935
    • chip3:0x15956
    • chip4:0x1595d
  • chip3のEncorecolumn1:65535→65023、Encorecolumn2:65535→65531に変更
    • chip3に読み出しが不安定なcolumnが存在したため、それに沿ったcolumnをdisenable
  • 4chipとも読み出し可能！(ただしchip3のtuning等が若干不安定)

• PreprodQ15
  • #58268 std_threshold scan
  • chipname
    • chip1:0x1593b
    • chip2:0x15935
    • chip3:0x15956
    • chip4:0x1595d
• LVがconfigをchipを読み出すたびに下がってしまう。最終的に~1.9Vくらいになる
• chip2は結果が出力しない→connectivity fileから除外
• chip2をの除く3chipの結果は良好。

• Testbeamに用いるmodule
  • 一番好調なPreprodQ03をDUTに
  • v1.1Q14とPreprodQ18をTelescopeに
  • 4chip読めるのはKEKでこの3つしか存在しなかったので予備は3chip読み出せるPreprodQ15になってしまう...

5/24(水)今村・久郷・倉持

荷物準備

• 詳細は https://docs.google.com/spreadsheets/d/1K7jAdqRAG-d-M4fouFL6Ag_GLDClLBd3uN85YGEzCq0/edit#gid=1201320968
• 可動式ステージはレコフレームに装着したまま運ぶ
• MPPCのG10固定に必要なねじはG10に装着済み
• ROIのG10固定に必要なねじは
  • 表：ROI自身についている
  • 裏：袋に入れた
• 可動式ステージ--座布団の固定は M4x10 を使う
• 可動式ステージ--G10は M4x8 を使う
• ケーブルの長さは電源やTLUを荷台に置く前提

13:00- mtg 今村・久郷・倉持・廣瀬

• run plan --> KEK112self, KEK114self, MPPC trig
• 電源関係
  • LVは分配基板を利用、TEXIO x2でよさそう -->分配基板動作確認
  • HVは電流値をモニターしたいので、takasagoではなくKEITHKEYにする-->木で分配
• todo整理

荷物梱包の様子

5/26(金)北・今村・久郷

手順

magnet control : http://usagi01.kek.jp/artbl.html

link to Grafana : http://130.87.192.22:3000/d/m-xg4WFnz/pf-ar-acc-dashboard?orgId=1&refresh=30s

開始時

• MACにログイン　ユーザー名：ARTBL　パスワード：artbl
• initiallize magnet : /share/nfs/workdir/Manuals/Control/sh/AllMag_setup.zsh
• set momentum : /share/nfs/workdir/Manuals/Control/sh/Set_momentum_Both.zsh
• 退避確認ボタン→シャッター開ボタンでビームを出せる状態になる

終了時

• /share/nfs/workdir/Manuals/Control/sh/AllMag_off.zsh

5/31(水) 倉持　柳瀬　久郷

ITk setup 動作確認

3台のITkを冷却できるか試験したい。

ただ前回のbeamtestで6台分岐のADC基板がお亡くなりになっていたので代用の温度モニターの手段を構築

raspi2台体制でmonitor

kekrasp03:室温&DUT温度

kekrasp07:tele2台

チラーはひとまず5℃設定。チラーのチューブの枝分かれがない方(よく冷える方)をCCでLVが高いDUT(PreprodQ03)に繋げる。

KEKARTB 本番　6/1-6/6

Beam time 6/1(Thr) 9:00 a.m.- 6/6(Tue) 10:30 a.m.

準備 倉持、柳瀬、久郷、今村

架台にキャスターを取り付ける
y方向の位置が3cmほど下がったのでラボジャッキを調整

光軸調整かなんかでレートが非常に低い(650Hzとか…)

Set->real

1GeV->0.99GeV

2.3->2.29

2.992->2.99

3.2->3.18

3.75->3.73

4.5->4.47(max)

momentumを変えるときはシャッターを落とすこと!!

data taking 1st day(6/1) 倉持、柳瀬、久郷、今村

ITkを入れずにまずビームのモーメンタムスキャン

• event数が前回200k近くあったのに今回は20kくらい(efficiency 10%未満)
  • TLUのbusy timeを1.3ms->10usに変更しても同様
  • dataをtakingを始めたが妙にhit数が小さい
  • FEI4のHVがかかっているか確認-->どうやらかかってなかったようです(電流確認!)
• なぜかHSIO2のtrigger rateがext scintiのもの（Graphanaで見れるもの）より高い
  • HSIO2 1000Hz / Graphana 600Hz
  • LeCroy に挿して確認--> ext scintiのNIM,NIMout(LeCroy trigger),CMOSout(HSIO2 trigger)が1kHz程度？で同期しているように見える、鉛ガラスはそれに対して2回に1回程度しか来ない
  • ビームは来ていないのにトリガーを発行しているケースがデータの半分くらいを占めていそう-->お気持ち2倍くらいrunとる
  • ついでにbusy入れ忘れに気づく-->今までのデータ意味なし
• 正しい状態で取り直す…

6/1 17:00-1:00 夜シフト (★今村・廣瀬)

モーメンタムスキャン

• KEK112 , KEK114, 鉛ガラス, ext scinti trigger
• モーメンタム（ベンディングマグネット）を変えながらデータを取る-->最もレートが高くなるモーメンタムを探る
• 1点2run(LeCroy の65535でrunを切る)
• run number
  • TLU 71-82
  • HSIO2 381-392
  • LeCory 33-44

QRFマグネットスキャン

• KEK112 , KEK114, 鉛ガラス, ext scinti trigger
• 3GeV設定
• 上流マグネットの電流値を変えながらデータを取る
• 1点2run( LeCroy の65535でrunを切る)
• QRF 49.95-->0 / QRD 0 / QSF 16.18 / QSD 15.07
  QRDは5月測定の結果から決定、それ以外はデフォルト
• RunNumber
  • TLU 83-98
  • HSIO2 393-408
  • LeCroy 45-60
• 結論：QRF 24.97A でレート最大

QSFマグネットスキャン

• KEK112 , KEK114, 鉛ガラス, ext scinti trigger
• 3GeV設定
• 下流マグネットの電流値を変えながらデータを取る
• 1点2run( LeCroy の65535でrunを切る)
• QRF 24.97 / QRD 0 / QSF 28-->0 / QSD 15.07
  QRFはひとつ前の測定から決定、QRDは5月測定の結果から決定、QSDはデフォルト
• 1st scanning run
  • TLU 99-106
  • HSIO2 409-416
  • LeCroy 61-68
  • 結果byひろせさん
  • 
  • QSF - 黒: 28 A - 赤: 20 A - 緑: 10 A - 青: 0 A --> つぎは20 A周辺を細かく
• 2nd scanning run
  • TLU 107-114
  • HSIO2 417-424
  • LeCroy 69-76
  • 結果byひろせさん
  • 
  • QSF - 黒: 24 A - 赤: 22 A - 緑: 20 A (さっきのやつ、太線) - 青: 18 A - オレンジ: 15 A
• 結論：QSF 20A でビームが最も絞れる

ビームスタディ用データテイキング

上記のスキャンで得た結論のコンディションでひたすらデータを取る

• KEK112 , KEK114, 鉛ガラス, ext scinti trigger
• 3GeV設定
• QRF 24.97 / QRD 0 / QSF 19.97 / QSD 15.07
  QRF/QSFはひとつ前の測定から決定、QRDは5月測定の結果から決定、QSDはデフォルト

6/2 9:00-17:00 昼シフト (★中村、久郷、柳瀬、(倉持))

ITksetup install

9:00~　富士にあるITk＋FEI4＋Cooling関係のthingをARTBLに運搬

• AtlasPC24,Lecroyは撤退
• TimonさんからPCBが送られてきました。(ARTBLにおいてます)
• LVはch1~3をITk,ch4をFEI4。
• HVはkeithley2台を1台ITk×3でTで分配、もう1台でFEI4×5をTで分配。
• セットアップは以下(MALTAはまだ未実装)
• チラーは5℃設定

下流　KEK144　KEK141　(MALTA)　ITktel 　ITkDUT　ITktel　KEK134　KEK132　KEK114(ROI)　上流　　←←Beam

FEI4構成リスト

A0 KEK144 RJ1
A1 KEK144 RJ2
A2 KEK141 RJ1
A3 KEK141 RJ2
A4 KEK134 RJ1
A5 KEK134 RJ2
A6 KEK132 RJ1
A7 KEK132 RJ2
A8 KEK114 RJ1
B0 KEK114 RJ2
B1 KEK114 RJ3
B2 KEK114 RJ4

• 温度モニター
  • kekrasp03：work/CYRIC_Software_devel/RaspiTempMon/　sudo python3 thermo_controll.py
  • kekrasp07：work/CYRIC_Software_devel/RaspiTempMon/　sudo python3 thermo_controll_interLock.py　-t　{interLocktemp}　interLocktempはとりあえず40でいいと思います。
  • kekrasp03→　top：PreprodQ03、bottom：室温　　 　　　　
  • kekrasp07→　top：PreprodQ18、bottom：ITkpixv1.1Q14　
  • tele×2(kekrasp07)についてはinterLockが働きます。LVが落ちたらスクリプトを回してるPCから音が鳴るはずなので落ちたら、interLockが実装されてないLV ch3の温度をよく見て必要であれば落としてください(kekrasp07:~/RaspiTempMon/　sudo python3 HMP4040_usb.py実行でリモートでも落とせるようにしています。)

• LV(HMP4040)
  • ch1 PreprodQ18 (tel上流)
  • ch2 ITkpixv1.1Q14(tel下流)
  • ch3 PreprodQ03 (DUT)
  • ch4 FEI4
• HV(keythlay6517A)
  • 上FEI4
  • 下ITk 3台

Berkeleyから電源セットが届く。
一通りsetした後なのでdataをとりながら合間をみてsetupできるように準備を進める

ITk3台の冷却は3台とも室温程度に制御できた。

kekrasp03 ch1:KEKPreprodQ03
ch2:room temp

kekrasp07 ch1:KEKPreprodQ18
ch2:KEKv1.1Q14

readout結果(6/1現在)
KEKPreprodQ03(DUT) 4台とも読み出し良好
KEKPreprodQ18(flex tele) chip4のみconfigがまわらない状態。輸送やsetup時に壊れた?
KEKv1.1Q14(flex tele)chip3,4は読み出し良好。chip1,2のEncoreColの最適値を探す

台風接近のため夜シフトは切り上げて終了。

ITkをふくめたdata takingは翌日に持ち越し

6/3(Sat.) 昼の部 久郷、倉持、中村、(比江森)

ITkはQ14のconfigの調整。-> chip1 disabled

上の方の加速器の深刻なエラーですぐにrateをあげられないそう。午後以降もできるかどうかはわからない

加速器の入射不調で11:30から調整を行う。
ビーム全然でないかも…

ITkが無事に走るまでFEI4でdata taking
Correlationの調整を行い、FEI4の5layerに全部beamが当たるようになった

3GeVビームだからITk通過後のscatteringがひどい…

加速器側の不具合で変なタイミングで止まるかもしれない。
rateは未だ上がらず1.3kHz程度

ITkは昼の間ずっとrunできるように調整

17:00ごろのTLU#148 からITk3台をincludeしたrun

KEKPreprodQ18 without chip4
KEKPreprodQ03 all chip included
KEKv1.1Q14 without chip1

tuning結果 #004471~004482

masking結果

Q18 #004514

Q03 #004517

Q14 #004520

KEKARTB calib log

12:30 調整

13:30 調整

17:55 よりwireが抜かれてビームが出ない状態に

wire2 13.15mm 126Hz
12.15mm 1.3kHz

3rd June Evening Shift (Hiemori,Yanase)

【ITk Debug】

19:55 S0 trigger S0，GBusy 10 ms の bit file を作った。（bitfils/kc705tlu_S0_GBusy10ms.bit みたいなやつ）

• YARR がトリガーを受け取っていない状態でerror が出まくる問題が，トリガーレートが理由だと改善することが期待されたが，トリガーを受け取っていないのにそもそもerrorが出続けていたわけなので，改善はしなかった。
• 3台を2台以下にして回してみたら，エラーなく走るようになった。3台でやったのが原因か…(20:00頃)
• runを回すごとにscanConsoleが、atlaspc26のメモリを食いつぶしていって、22:00頃にはpc26がまともに動かないほどに...。(1module runでもダメ)

とりあえず下に状況(ITkDAQerror)を羅列します

• Onlinemonを見る限り、noisy pixelは鳴ってなさそう。ちゃんとmaskingできてる。(のちにITkのrawdataが重すぎるせいでatlaspc7へのrsyncに莫大な時間がかかるようになり、ITkをいれたrunだと、onlinemonitorが実質出来なくなりました。atlaspc26でonlinemonを実装したけどpc26側の問題？でplotが表示されない。。OnlineMonWindow.hh file not foundといわれてしまう)
• errorはmemoryが9.0Gくらい～になり始めてからどんどん出始める。
• noise scan、selftrigger、ともにビーム由来のHitがまるで見えない。(selftriggerについてはHit0)
• moduleの問題ではなさそう、DAQ側の問題。
• 試したこと
  • controllerを16×1.json→16×1_extrigger.jsonにしてみた→変わらず
  • 引数 -pをなくしてみた　→変わらず
  • 久郷さんが前半シフトでやってくれたnoise scan直後のconfig fileをcopyして再度実行→変わらず
  • 最新のYarrをgitからcloneしてconfigをコピーしてやってみる(yarr-devel-20230603)→変わらず、yarrのversionに関係があるわけではない
  • 最新のYarrでDUTのconfigを新しく作り直してやってみる(PreprodQ03 _ARTB_test)→変わらず
  • memoryの空き容量を増やすためにpc26にあるFNALdataをrmした。→変わらず
• シフトの最後にHVケーブルの接触が悪いことに気づいた(アクセスしたときにかかっていなくて、ケーブルを抑えつけたらかかる状態。)。多分ITkをrunに入れ始めた当初からHVはかかっていなかった。とりあえずケーブルは富士B4のプローバーHVケーブルを貸借。

【明日の前半TODO】

• HVかかってから読み出しを行っていないので、どちらのyarrでも良いのでexttriggerをとってみる(とりあえずDUT1moduleのみで大丈夫)

6/4 (Sun.) 昼シフト（★久郷、廣瀬(、比江森)）

09:15: 3 GeV 、ベストなマグネット設定（QRF = 25 A, QRD = 0 A, QSF = 20 A, QSD = 15 A）でDAQスタート

09:30: FEI-4のみならデータがとれているっぽいが、ITk 3台を入れるとDAQが強制終了（Expect new stream while start a new eventのようなエラーが大量発生しているのが原因？）。

• YARRのみでDAQを始めたらTLUからトリガーが出ないがYARRはトリガーを受け取っている状態？ --> そもそもYARRのみでTLUは走らせられない（中村さんがYARRのみ用のファームをコンパイルくしてくれた --> kc705tlu_YarrOnly_1.3mBusy.bit）。

11:30: FEI-4 + ITk 1台のみ(DUT) をいれてDAQ

• DAQは走ったがYARRのデータが空

12:00: ITkモジュールへのHVの確認

• 6517 (下) の表示は最初-140 uAぐらい (本当だったら多すぎる！) --> だが、HVを0にしても表示が変わらないので、どうもゼロ点がずれていただけのよう。zero correctionした。
• モジュール3台つながった状態で-100 V印加しても、流れる電流は0.1 nA以下（そもそも流れていなそう）
• 念のため、Q18のケーブルで-3 Vだけかけた状態でテスターで測ると、ちゃんと-3 V来ている。
• 昨夜の時点では0.6 uA流れていたらしい

13:30: HV周りのチェック

• 6517下で4 Vだけかけて導通チェック→3本ともちゃんと来てる
• その状態でできるだけケーブルを動かさないように気をつけながら電圧をかける→1 nA以下
• 6517上と下を入れ替える（上がITk、下がFEI4）→やっぱりITkは電流は流れず。FEI4は1.5 uAとか流れるので、6517下の問題でもない
• 冷却パイプ周りが結露していたので、念のため中で結露が広がっていないかを確認 --> 冷却ブロック周辺以外は特に結露無し
• ボックスをあけたので、ついでに基板上までHVが来ているか確認（2 V）→来てる
• もう一度、Q14に6517を直接つなげてHVかけてみる → やっぱり電流は流れない（O(1) nAかそれ以下）

いまのところ、原因はよくわからない。まずはQ14を動かすことを目指してデバッグをする。2410を試す前に、一度ビームを出してみる（ダメもとで実は信号見えないか＋いろいろ触ったので、DAQがちゃんと走ることの確認）

15:28: FEI-4＋ITkはQ14だけでビーム出す

• Q14信号見えません
• (ScanConsole のエラー消えてる)

16:00: 2410試す

Module

0 V

-130 V

diff.

Q18

0.31 nA

-3.66 nA

3.97 nA

Q03

0.25 nA

-6.44 nA

6.69 nA

Q14

0.63 nA

-4.88 nA

5.51 nA

All

0.63 nA

-8.59 nA

9.22 nA

• ゼロではないカレントが流れた気がするが、少なすぎる気がする。
• 3モジュールともデータない

• PCB上のピンでLVGND/HVGNDを導通させたところ、電流が流れるようになった。

　　　Q18 ~300nA

　　　Q03 2Vで>1uA流れ、それ以上上げようとするとrange~200uAでoverflowする

　　　Q14 ~100nA

• Q03はセンサーが壊れている可能性が高いので、Q18/Q14のみ電圧をかける

　　　Q18+Q14 ~200nA　

• この状態でselftrigger scanを行った結果、run#004621 PreprodQ18 Chip4でヒットのようなものが見えたが、他のチップは見えなかった。

　　　それ以降selftrigger scanを行っても、PreprodQ18を含めてヒットが入らなかった

• てみる(とりあえずDUT1moduleのみで大丈夫)

6/4 (Sun.) 夜シフト（★比江森、今村）

以下，同様にベストなマグネット設定。
ITk データ収集できない問題のデバッグを行う。
現在までの状況を整理すると，

[Q14]
電流値 ~300nA
selftrigger
①maskなし：chip1~chip4すべてhitらしきものが見えない
②maskあり：chip1~chip4すべてhitらしきものが見えない

[Q03]
電流値 over1000nA@2V-->流れすぎ
センサー死んでるかもなのでとりあえず無視

[Q18]
電流値 ~100nA
selftrigger
①maskなし：chip1~3は何も見えない、chip4のみhitが見える(ビームとは断定できない)
②maskあり：chip1~chip4すべてhitらしきものが見えない

という感じ。（今村さんのまとめを拝借）

Q03に関しては異常な状態のため，ワンチャンあったQ18のみに絞って原因究明を行う。

• digital scan
  yutahie script:Mask_noisePixel.cpp を用いてうるさいやつを落としていくと，chip4 の(col, row) = ( 36, 171 )にenable & hitbus をdisableしてもoccupancy 400 のヒットが現れ続ける。これはencorecolごとdisable すべきかもしれない。というわけで，corecol masking を追加した：encorecol0: 65513 -> 65519 にした。
• analog scan
  100 発入射してそれ以上の応答を示すピクセルがやけに多い。さらに，前述のスクリプトでこいつらを除外しても消えない（が，実際にはenable hitbus ともにdisableの設定になっている）…
• selftrigger source
  ひとまず以上の傾向が見られている設定で，selftriggerを回してみた。結論としてはすっからかんで，数ヒット程度が数ピクセルのみに現れる。selftrigger でnoisy pixelがいてDAQを邪魔するのなら分かるが，そのようなピクセルは存在しないのが不思議。ヒットとして見えなくても，HitOrが発行されてデータ収集を占有するようなことがあり得る？ もしそうなら，それをどう見つければ良いか。
• std_noise scan
  freq= 30 kHz, 30 s 走らせてみる。すると，ビーム由来の信号っぽいヒットが見られた（delta rayとか）。結果の例は，例えば　yarr runNumber #004658。
  統計を貯めるとびーむシェイプがもう少し分かるようになるかもということで，300 s ，50 kHz trigger でもう一度走らせてみた：より一層ビームの形が比較的分かるようになった（例えば#4660）。1 kHz 程度のビームでクロックトリガーを見ていることを考えると，解釈できる程度のヒット数かなあという感じ
• fnal_exttrigger scan
  これをやるには latency scan が必要

tuning したにも関わらず，analog scanで noisy pixels がちらほら出るのが気になる。tuningに問題があった？と考え，シャッターを閉めてtuning に専念することにしてみる。

• Chip3以外はとてもよくtune できる。Chip3に関してはtuning の段階でnoisy pixels (s.t. enable & hitbus already masked)が影響して，global tuning threshold が引っ張られて高く出てしまい，pixel tune threshold でTDAC=-15 の高い閾値ピクセルたちが閾値分布の高い方の裾に広がってしまう。こいつらは，analog scanでも同様にうるさいヒットを鳴らしている。厄介なのは，前述したようにenable & hitbus はdisable にしていることであり，最終的に黙らせるためにはcore col masking を必要とすること。というわけで，こいつらを含む core col を色々maskした。=-> tuning できた。（core col masking だらけだが… threshold scan#004691）　しかしs -curve が描けてないピクセルがChip3だけやけに多い（0e ~ 35000e scan）。noisy なピクセルもいそう。
• とりあえず，この状態でexternal trigger scanを試す。(TLU run# 以降がそれ)
• std noise scanでビーム由来らしきヒットが見られていたので，external trigger scan でも見られるはずと期待しlatency scanを試してみた。範囲は0 から100 までで，10刻みぐらいで取っていった。が，chip3 にノイジーな傾向は見られたほか，それ以外のchipで特定のlatencyに対してヒットが増えるような傾向は見られなかった。。　latency=60でdelta ray由来のヒットがchip2 に見られ，tag=1あたりに高いエントリー数を示していた。もしかしたらこれがdelta ray由来のヒットのものかもしれない。ということは，もう少し遅いlatencyが最適値になっているかもしれない。
  しかし，結果としてはどのlatencyにおいてもヒットがたくさん入るようになる傾向は認められなかったことから，そもそもヒットを正しく拾うことができないような状態になっている可能性は否定できない。chip3 がnoisyであることが影響することも理由としては考えられる。実際，chip3 は前述の問題からdisabled core columnがchip全体にわたって置かざるを得なくなっていてtracker としての機能を損ないつつあるため，chip ごとdisableしてしまうことも選択肢の一つとして検討すべきかもしれないねえ~

6/5 (Mon.) 昼シフト（★比江森、柳瀬）

以下，同様にベストなマグネット設定。
ITk データ収集できない問題のデバッグを行う。

HV測定

• PreprodQ18 が再度測定したらHVが流れなかった。電源をkeithley2400にチェンジして、再度測定をしたらちゃんと測定できてそう。
  • PreprodQ18:~200nA@-130V
  • PreprodQ03:-~1μA@-130Vくらい。昨日みたいなことはないが確かに高すぎる気はする
  • v1.1Q14:~300nA@-130V
• PreprodQ03 は戦力外通告。scatteringを防ぐためにレコフレームからおろした。
• 他2つはHVは健全にかかっている。

Cooling

• 一度Moduleを外して裏面を見てみたらTIMに若干の結露とASICの裏面にも水滴が1~2滴あることが判明。一度2つのモジュールともファンを使って乾かす。
• チラーの温度を13℃に設定してモジュールの温度が結露がなくなるように～30℃になるように保つ。
• そもそもセットアップに触れてないのに読み出しやHVがおかしくなる原因として考えられるのはやはり結露の可能性が高い(ARTBの湿度が高い＆乾燥空気がないというのをなめていた。)
• ちなみにDUTは外したので温度の読み出しはkekrasp07の1台体制で臨む。

読み出し

• 一昨日見られていたyarrのmemoryが重すぎていろいろ不具合が起こる現象はなぜか解決。
• selftriggerについては、maskingをしなければしっかり全体にHitが入る(うるさいやつが誘発してる？ ex.)#4727 selftrigger )が、maskingをしてしまうとからっきし。
• noise scanではビーム由来のHitっぽいのがちゃんと見える？(ex.)#4778)
• 外部トリガーはHit数があまりにも少ない
• 内部トリガーで鳴っているのに、外部トリガーでならない理由
  • latency scan(50,75,100,125,150)をしたがいずれもHit数が増加した傾向はなし
  • TLUにTriggerを送る機能がなかった→焼き直したらHitがしっかり出るようになった
• 以降DUTをPreprodQ18に、v1.1Q14をtelescopeの2台体制Datatakingで行う(connectivity:example_rd53b_PreprodQ18_KEKv1p1Q14_ARTB_setup_all.json)

6/5 (Mon.) 夜シフト（★今村、倉持、中村）

以下，同様にベストなマグネット設定。3GeV設定。

参加者

• KEK114, KEK132, KEK134, Q18, Q14, KEK141, KEK142
• 0,1,2,3,4,5,6

とりあえずデータを取る-->OnlineMonitorで確認

• 比江森柳瀬がQ18を上流から見て左に+20mm-->ITk同士のコリレーションが端にしか見えない、hitmapがべた塗り…？
• Q18を10mmもとに戻す-->hitmap的に裾しか当たってなさげ。ITk同士のコリレーションも端にしかきてない
• Q18を比江森柳瀬セッティングに戻す＋Q14を20mm動かす
  • #217～hitmap的に真ん中にあたってそう＋ITk同士のコリレーションが真ん中に来た！
• FEI4とのコリレーションが見えない-->どうやらOnlinemonitorのバグ？倉持がんばる
• ITkにあたっている位置が下すぎる＋Q18の歯抜けのところにビーム中心が来ている-->ジャッキでレコフレーム全体を下に5mm&可動式墓標で+5mm(FEI4とビームの位置関係を保持するため)+Q18を上流からみて右に10mm
  • #223～位置よさげ！コリレーションが見えない…
  • イベント落としてる？-->イベント数少なめrunを取ってみる
  • ＃225 コリレーションが見えた！
  • 落とすとしたら最初に落としてるっぽい from #223,224 -->skip reset を消して走らせてみる#226~#258
  • #225 correlation, #226~#230 NO correlation, #231 correlation... -->skip reset関係なく落とす時があるっぽい、落とさないときはずっと落とさないので最初にやらかしている？
  • とりあえず50000evts程度のrunをたくさんとった
  • 昨日の時点では35 runで correlationが見えたのが 4 run.... 大体11%の確率....ひどい

6/6(火) 9:00~12:00 倉持、柳瀬

--skip-resetの有無でcorrelationが見えるかどうか50k event程度のrunをいくつか走らせてみる

今日のrunに関しては一向にcorrelationが見えない…→TLU#285で最初に見えたが、途中で消えた...。途中でもeventがスキップされることはありそう。

correlationを落とすとしたら最初の方なのでEventLoopmanagureでITkのeventを数eventずらしてcorrelationがみえるかどうか確かめたい。

v1.1Q14のLVが2.4V@5.8A(CC)でかかっていて発熱量が多く、温度が~39℃くらいまでいったので、5.4A(CC)に下げた。それでも2.2Vかかっていて読み出しに影響はなさそうなのでこれで様子見る

6/9(金) 9:00~13:00 倉持、柳瀬、比江森、久郷

maltaをROIとFEI4Dual1層目の間に導入。

maltaとITkを入れたrunを走らせる。

まずmaltatoFEI4とのcorrelationを見ながらdata taking.

maltaを上流から右に10mm 動かしFEI4とのcorrerationを観測。

ITkをPORしてrunを走らせてもcorrerationは見えない．

--maltaも1/2の確率でcorrrelationがみえない時がある。これはFTBFではなかった現象なのでもしかしたらDAQ PCの処理能力の問題も絡んできている可能性が考えられる。-- 後ほど確認したらmaltaはcorrelationとれていました。

FTBF:HSIO2 & LeCroy -> atlaspc24, ITkpix & Malta->atlaspc26

ARTB:HSIO2& ITkpix & malta->全てatlaspc26でoperate

Comments

-- Atlasj Silicon - 2023-05-26

-- Atlasj Silicon - 2023-05-26