Log 
Article text.
-- 
 
 Atlasj Silicon  - 2022-11-02 
 出発前準備 
 To do(2022/12現在) 
 
-  Fermilabユーザー登録
  -  渡航の申請
  -  冷却セットアップの設計・plan
  -  ITk pixel moduleとTLUの同期試験
 
 
 既存のセット動作確認 byきた 
 HSIO2とPCの接続確認 
1/23
接続先PC(atlaspc24)にZYNQ動かすソフトやらcosmicGuiやらが入っていたので新しいインストールはナシ。動作確認だけ行う。
新しいPCでやるときはソフトインストール等が必要。詳細→TBディレクトリ内のcc7.tct
HSIO2とpc24をUSB-ethaで接続。HSIO2にAC電源を接続。HSIO2の電源ONOFFはAC電源抜き差しで行う
(pc24側)
ネットワークの設定→IPv4タブで以下の設定をして適用 
-  メソッド:手動
  -  ルート 
-  アドレス:192.168.1.70
  -  ネットマスク:255.255.255.0
  -  ゲートウェイ:192.168.1.1
 
 
  -  この接続はネットワーク上のリソースのためだけに使用のチェックを外す
 
 
一旦該当するネットワークをOFFしてONにする
DHCPサーバーを再起動
systemctl restart dhcpd.service
DHCPサーバーがちゃんと動いているか確認
systemctl status dhcpd.service
緑でrunningっぽいことが確認できた。
ネットワークをローカル用に使うことを認識してもらう。コマンドで
nmcli connection modify [eth] ipv4.never-default true
[eth]部分はネットワークの設定からIdentityタブで決めた名前を入れる。今回はHSIO2。このコマンドはsudoじゃないとできなかった。
ネットワーク設定からこの接続はネットワーク上のリソースのためだけに使用のところにチェックがついていることを確認。ついてればOK
ping 192.168.1.10 または ping rce0 →通信できることを確認
 PC24上にFNALtestbeam用ディレクトリを作成 
homeのディスクがいっぱいだったのでELPH202207ディレクトリをpc24の外付けディスクに移動。
外付けディスクにシンボリックリンクを貼った。
ELPH202207をFNAL202302に名前変更してコピー。データなどの中身を消した。
 読み出し試験 
 準備 
テレスコープ候補(KEK144, KEK141, KEK132, KEK134, KEK142), ROI候補(KEK114, KEK112)を用意
LVをかける
ROI候補:1.4V(VDDA). 1.2V(VDDD)
テレスコープ:1.8V
HVをかける
RJ45をethaでHSIO2に接続
 読み出し試験 
PC24からHSIO2の方でcalibserverを立ち上げる 
-  ssh root@rce0 (passwd : root)
  -  source setup.sh
  -  calibserver
 
 
PC24上でconfig用guiを立ち上げる 
-  source daq/rce/scripts/setup-env.sh
  -  cd ~/work/FNALtestbeam202302/HSIO2/
  -  calibGui
 
 
 とりあえずKEK114だけ動かしてみる 
GUIトップページで 
-  load→KEK114.cfg
  -  config root dir → /home/atlasj/work/FNALtestbeam202302/HSIO2/rceconf/configs
  -  data dir → /home/atlasj/work/FNALtestbeam202302/HSIO2/data/
 
 
ここでrunしてもうまく走らなかった。host.rceとかでmakeをしなおしたりsudoでsourceしてみたりいろいろやったのでどれが原因だったかわからない。とにかく急に走るようになった。
GUI上Config 
HalfstaveA タブ→チップ4つをすべてinclude
digital scanもanalog scanも走った感じがする。→plimlistを使ってtuneしてみる。3000threshold10ke8totに合わせるやつを回す。→結果を見た感じいいかんじ。(key20)
ソーススキャンする(60s)→いいかんじ
maskの確認。mkmaskでマスク作ってみた。→いいかんじ。
 読み出し試験結果まとめ 
名前   目的  tuneのkey Selftrigger Selftrigger② コメント
KEK114 ROI 17 19 20 LVの接触が悪?
KEK132 tel 36 37 -
KEK134 tel 53 54 - 先にHVかけようとしてもかからない。configを先に
KEK141 tel 71 81 -
KEK142 tel 108 109 -
KEK144 tel - - - 読み出し不可。HVかからない。そもそもconfigも通らない。
KEK112 ROI - 135 136
トラッカーとして使うのはKEK132, 134, 142, 141
ROIとして使うのはKEK114
 シンチ動作確認 
1/24シンチの動作確認。シンチ全部で4枚。だめかもしれない…以下状況 
-  HVはかかる。
  -  H1とH2の信号がそもそも出てない?山にならずに波で見える。ベースラインがすごく上にあるわけでもない
  -  H3のANDの入口では二つともHIになっている
  -  
 
 
 2023/02/20 
writer: yutahie
 荷物の箱出しおよびレコフレームの組み立てを行った。
writer: Kuramochi
明日確認すること 
-    トッドさんにレコフレームの下部分の金具のことについて聞く
  -  チラーを借りてつなぐ
  -  Training (9:30~)
 
 
 2/21(Tue) 
9:30- 北・倉持・比江森・久郷・中村 Training
柳瀬・今村は午後からなのでFTBFで作業
<作業> 
-  クーリングの断熱材加工
  -  HSIO2を置くためにレコフレーム周辺整理
  -  Electronic lackのダメージ修復 with Maria
  -  ITk DUTのcooling boxにPreprodQ09設置
  -  Controlled access training
 
 
翌日は8時から作業 4時までにbeamlineのsetupをする
 02/23(Wed)~02/23(Thu) 
記入者:今村
 8:00~20:00 全員でセットアップ作業 
 
-  モーションテーブルの動作方法確認…今村・倉持 → 作業用に一番低い位置に設定
  -  レコフレーム(DUTなし)搬入
  -  配置決め…レコフレーム背後に棚を作ってもらってボードやLV基板系・PC類を設置、チラーは手前に台を用意してもらって設置、下流側手前にMPODやルクロイ  
  -  フレームのねじ受けM4サイズが不足していたので、下駄の穴をM6対応に拡張してもらう(一度M5で発注した、発注前に確認気を付ける)
  -  16:00の安全検査に間に合うように配置・配線を進める
  -  チラーに巻くチューブがない… → ウレタンで代替
 
 
 20:00~5:00 北・今村・比江森・柳瀬・中村でセットアップ続き 
 
-  19:00ごろ?ステージを実際の高さにする
  -  21:00ごろ?レーザーでレコフレームが斜めになっていることを確認、修正
  -  ITkのクーリングボックスの向きを変える
  -  チラーが流れない(特にLGAD)→チラーが下から入るから?
  -  ネットワーク関係設定 http://atlaspc5.kek.jp/do/view/Main/FermilabTestbeam2023
 
 
 安全検査のために注意することや対策 
 
-  framableなものは却下される(例:プチプチや発泡スチロールなど) 
-  かにボードなどの足元はテープ状のフォーム的なものをもらって敷いた。何がframableだと判断されるかよくわからないので、Toddなど現地の人に聞いてもらうのが良いと思う
 
 
  -  ケーブル類はフレームに固定・床に安全に目張り・ぐるぐるにして宙ぶらりんの3択で固定する  
  -  延長タップが短かったので借りた。長めを持っていかないとケーブルが宙ぶらりんで怒られる
 
 
 DUT配置について 
  
 LGAD関係 
 
-  最初温度計を入れ忘れた → 木曜深夜、ITk配置向き変えのついでに温度計を入れて簡単な冷却試験 
-  温度計のレゾリューションが悪い(+-10℃くらい)
  -  LV入れて30分ちょい放置 → 最高で27℃くらい。なんとなく温度が上がっている傾向は見える
 
 
  -  DUT配置のときにサンプルを入れなかったので、後で入れる羽目に… 安全検査までにはケーブルをつないでおくので先に入れておいたほうが良い
  -  LeCroy をAuturのチームから1台拝借(夕方ごろ?) 
-  SMA-MCXが8本足りない → Crisに2mのものを貸してもらう…2台のLeCroyそれぞれでPMTとの時間差をとるので、ケーブルの長さは時間分解能にはあんまり影響しないと思っている
  -  自分たちのLeCroyを192.168.8.3に設定。connectivitytestが通ることを確認。vncも見れる。
  -  くりするくろいは192.168.133.167に設定されていたので新しくUSB-EthaをPC24にさした。connectivitytestは通る。リモートデスクトップができない。LeCroyUserでログインしたから?
 
 
  -  最初のサンプル  
  -  http://atlaspc5.kek.jp/do/view/Main/Feb2023TestbeamPhoto?id=1&filename=1677191357120.JPEG#igp1
 
 
 ITk関係 
20:00~ ・ITk Telescope(v1.1Q17)にコネクターがついていなかったので、いったん取り出してつける→LV正しくかかった
・アライメントの関係でITk tele×2、DUT×1の前後を入れ替える大工事
・ペルチェ導通確認→ok
  ペルチェ@DUT ...4Aー9V
  ペルチェ@telescope ...4Aー2.3V 
  ※OUTPUT ON直後の電圧の目安(時間経過で電圧増加や環境温度でブレあり)
・チラー動作確認
  チラーfor telescopeはflowが弱くて(特にLGAD2台に)液が十分流れない(チラーの高さやチューブの位置を調整しても×)
   →KEKでの測定よりも低い設定温度でやってみる(TODO)
  チラーfor DUTは現状ブレーカー落ち?の関係で電源がつかない
 電源関係 
 
-  配線と導通チェック。 
-  ±5V(シンチ、ROI変換基板、TLU用) 
-  ひとつのTEXIOに追いバナナしたら大変なことになった。レコフレームからレコフレームを生やして補強。
  -  実際に電圧をかけて電流値が正しいことを確認。
 
 
  -  MPOD(LV) 
-  MPOD本体にさす方はFuseをつけてからケーブルつながないとおこられるらしい。
  -  それぞれふたつLVを用意。ひとつはLV
 
 
 
 
 
 
 ネットワーク関係 
http://atlaspc5.kek.jp/do/view/Main/FermilabTestbeam2023
 02/23(Thu) 
 昼シフト(倉持,久郷) 
lab taxiの始業は7:30で実際にtaxiが動き始めるのは7:45かららしい
7:30くらいに電話でtaxiを呼んだら 8:05くらいに来た。MTestよりFTBFの方が通じた。
夜中何をやったのかわからない上にThinkPadの内部ネットワークの接続方法がわからない。
朝supervised accessできたのでsetupを確認していたが9時前くらいに追い出される。
MALTAのVDDA,VDDD?(MALTAの電源関係詳しくわからない)のoutputがONになってたので一応切りました。(LVはかかってなかったです)
9:30くらいからBeamが出てるのでControlled accessでしか入れないっぽい。
10:00ごろからMariaとKehangと一緒にDAQのRemote Controlについて教えてもらう
LV(HMP4040)のcommunicationがうまくいかずMariaとKehangがデバッグ中
16:48 Raspi の時間が数日ずれていたので修正 (Graphanaで確認済み)
 夜シフト(北、今村、比江森、柳瀬) 
 ITk関係 
・チラーチェック
  ・チラーfor telescopeは設定温度-20℃でやってみる(実際は液温-3.5℃くらいまでしか行かない)
  ・チラーfor DUTがまだ電源つかない、Toddに聞いてみる(TODO)
  ※ちなみにテープで止めてはいるがチラーの200V電源ケーブル外れやすいため注意
・telescope&DUTのLVチェック
  PreprodQ03→5.6Aー2.38V
  PreprodQ09→5.6Aー1.60V
  v1.1Q14→5.6Aー2.05V
  ・PreprodQ09(DUT)のLVが明らかに小さい。ケーブルの極性はあってる。LVケーブルの問題でもない。パワーコネクタ―もしっかり入ってそう。配送中あるいはセッティング中にモジュールに何らかのダメージか..?→チラーfor DUTが動かないので読み出し試験ができないため、正常に読み出せるかはTODO(場合によっては予備のv1.1Q17に変更する必要あり)
・温度計接続→ok
  ↑上流
  Telescope 
PreprodQ03 →temp5
  DUT 
PreprodQ09 →temp6
  Telescope v1.1Q14→temp3
  ↓下流
  ※Resolutionにばらつきがあるのは仕様らしい、値自体はそれっぽいのでよい
・冷却試験(5.6A(CC)、チラー-20℃設定、ペルチェ4A(CC))
  Q14もpreprodQ03もT=25±5℃くらいに落ち着いた→問題なさそう
・マルチモジュール読み出し試験(telescope×2)
  ・DPケーブル接続
  ↑上流
  Telescope 
PreprodQ03 →portA
  DUT 
PreprodQ09 →portB
  Telescope v1.1Q14→portC
  ↓下流
  ・chipID一覧(efuseのやつ)
    ・PreprodQ03 Chip1:0x1302b Chip2:0x1302a Chip3:0x13027 Chip4:0x13028
    ・v1.1Q14 Chip1:0x13868 Chip2:0x13058 Chip3:0x1309b Chip4:0x1308b
  ・マルチモジュールの読み出し自体は成功!したが、v1.1Q14の結果にパターン状のぐらつきと、剥がれらしきものが見られた(runNumber: /home/atlasj/work/FNALtestbeam2023/ITkpixel/yarr-devel-20221212/data/002294_std_thresholdscan )
  
  <メモ>
  ・Q14のLVが2.05V 5.6A(CC)で低かったのでQ14は5.8A(CC)で測定
  ・PreprodQ03のdigitalが汚かったのでTrim8→12にした→きれいになりました
  ・PreprodQ03Chip & Chip4のnoisy pixelが含まれるcore columnをdisableした。が,これを行なった経緯は比江森所感に記載。
  ・v1.1Q14のchip4はuntunableなのでdisableした。
以下,比江森所感(ねむいのでロジック破綻してるかも?) 
-  上流ITk telescopeがpreprodQ03であることは,e-fuse IDから確認ずみ。sensor structureもpreprodのものになっているので,間違いない。
  -  e-fuse IDの確認はchipNameにe-fuseIDを入力する前に行ったことから,YARRが吐き出したe-fuseIDは間違いなく正しい
  -  しかし,読み出しを行っていた時,インストールされていたのはv1.1Q17だと誤認していたので,KEKでの測定データを参照してv1.1Q17で必要なcore columnをdisableした。
  -  このcore column diablingを行なった理由が,読み出しがうまくいかなかったからv1.1Q17に対する処方箋が必要だと判断したからなのか,それともv1.1Q14の読み出しがうまくいかなかったことをpreprodQ03のせいだと誤認したからなのか,ちょっと自信がない。
 
 
以上のことから,念の為確認してほしいのは,
preprodQ03の読み出しを全てのcore columnをenableにした上で行い,読み出し結果に問題がないことである。問題なければ,大丈夫。問題があったら… (デバッグお願いします。)←All OK!
PreprodQ03 はall core column enableで読み出し&tune可。夜にうまく読み出せなかったのはおそらくv1.1Q17と思ってcore columnを設定していただけだと思われる。後述するがv1.1Q14はnoisy pixelをマスクすることでChip4はtune可能
 LGAD関係 
 
-  使用チャンネルを決定して接続 
-  Pixelはamp2とamp4を外す(PMTのために) 
-  atlasosci02:ch0-amp1,ch1-amp3,ch2-amp5,ch3-amp6,ch4-amp7,ch5-amp8,ch6-amp9,ch7-PMT
  -  cmsosci:ch(7)-amp10,ch8-amp11,ch9-amp12,ch10-amp13,ch11-amp14,ch12-amp15,ch13-amp16,ch14-PMT
 
 
  -  Stripはすべてつなぐ 
-  ADC ch0-amp1...ch15-amp16
 
 
 
 
  -  LeCroy をリモートで見られるようにした 
-  atlasosci02...192.168.8.3 via xfreerdp @ pc24 ←etha繋いでvnc使えるようにした
  -  cmsosci...192.168.5.169 via R-desktop/vnc
 
 
  -  HV,LVがかかるかを確認→OK
  -  ビームが来たタイミングで信号らしきものがみえた @ 150V
  -  acquisition.pyを走らせるコードを北さんが作成→でデータ取得ができることを確認
  -  PMTの信号が小さくなっているかは不明...
  -  ADCはまだつないでみてない
 
 
 FEI4/ROI 
 
-  HV,LVをかけた
  -  Configを通した
  -  ミスったポイント 
-  RJ45の差し位置
  -  VDDA VDDBが逆だったかも
 
 
 
 
 次シフトへの引き継ぎ欄 
 
-  ビーム関連 
-  1分のうち4秒間だけビームが出る
  -  ピーピー音が鳴っていないときにビームが出ている
  -  CR内のいくつかのモニターで確認可能…入口水槽上、メインスペース隣、上流側出口付近
  -  メーンスペース隣のカウントをしているモニターで秒数も確認可能
 
 
  -  ITKPIX 
-  DUTの冷却試験と動作確認をお願いしたいです。今すでにチラーが動いているので,ちゃんと冷えてるか,そしてちゃんと読み出しできるかのチェックをお願いしたいです。
  -  KEKv1.1Q14のchip4,確かにtuningできないけど,どうにか復活できたりしませんか?ちょっとcore column disablingとか試してみて欲しいです
  -  preprodQ03の読み出しチェック
 
 
  -  MALTA 
-  (yutahieむけメモ) 
-  maltaMultiDAQ self-triggering してるっぽい問題
  -  maltaMultiDAQ なぜかplane2 のデータが入らない問題
  -  online monitor 組み込むためにどうやって考えるか問題(.root でやってくれててウレシー その構造を眺めて必要な情報を取り出すクラスを適当に作る)
  -  online monitor の作成
  -  他トラッカーとの同期試験
 
 
 
 
  -  LGAD 
-  LeCroy はリモートで見れます(R-desktopまたはVNC経由)
 
 
  -  FEI4 ROI 
-  一応動くけど、ちょっと不穏なのでセルフトリガーでも見てくれると嬉しいです
  -  ROIは出ない、configは通るしヒットマップは見える…
 
 
  -  そのほか 
-  接続関係はatlaspc24のmemo.txt
  -  MPODはisegで操作  
 
 
 
 
 2/24(Fri.) 
 昼シフト(倉持,久郷) 
 ITk pix 
上流側のtelescopeが冷却できていなかった。
Beamlineにcontrolled accessし、上流側telescopeにチラーの水が回っていないことを確認。
チラーのホースを上に固定することで水が循環し、全てのITkがLV ONの状態で冷却可能に
tel 2台は30度±10度くらいをふらふら、DUTは6度くらいで安定している。
チラーが回っていない時は50度がmeanだったので冷却はできてそう。
3台のmoduleの読み出し
KEKPreprodQ03(ITk tel up)
KEKv1.1Q14(ITk tel down)
~~KEKPreprodQ09(DUT)~~
は全部マルチチップ読み出し可 読み出し結果も良好
KEKv1.1Q14はchip4にnoisyなpixelがあるのでcore column enableをいじってマスクしないとanalogscan以降が回ってくれないので(以前からみられた)configを変える必要がある。
config/rd53b_1DPKEKv1.1Q14_FNAL_Chip4.json
"EnCoreCol0":65439
確認したらKEKPreprodQ09が刺さっているはずのportBから通信が帰ってこないことが判明。
コードが抜けてしまった or portBの故障?
次のcontrolled accessで確認
 Online moniter関連 
rsyncするときの設定をミスってもとのSiliconTBのディレクトリでうまくコンパイルできなかったのでSiliconTBSoftware-develを作りました。
Online monitor無事起動
mkconfig.shも動くっぽい
一層目のFEI40は当たってるけどそれ以降のtelescopeは当たってなさげ
FEI41のdataが何もない…entryはあるけど正しくプロットされてない(要デバッグ)
IBLのsetupでLVとcomminicationがとれたらしい、今はcoolingの作業とかをしてるらしい
 夜シフト(北、今村、比江森、柳瀬) 
 ITk関係 
 
-  基本的に全体のアライメントした。
  -  
  -  PreprodQ09 (DUT)とcommunicationが取れなかった(LVが低すぎる)のでPreprodQ17に入れ替えた。 
-  6.0A(CC)ー1.85Vで低いのがやはり不穏
  -  PreprodQ17 はchip1,3,4は完璧、chip2がscan回るけど結果が出ない状態→access時に6.0A→6.4A(CC)にして、trim=15にしたら読めるようになりました
 
 
  -  PreprodQ03 のChip4が突然cannot communicationになった。 
-  access時にみたら2.6Vくらいかかってたので、5.6A→5.2A(CC)にしたら読めるようになりました
 
 
  -  LVは時間経過で増えたり減ったりすることもあるみたいなので(特にpreprodQ03、preprodQ17)、突然読めなくなったときはその辺を疑ってみてください。
  -  3台multi module読み出しに挑戦→全chip読み出しには成功したが結果が汚くなってしまった。 
-  データ処理が追い付いていない?→frequency下げてみたが効果なし
 
 
 
 
<やなせ個人的メモ> 
-  冷却:LGADdownがflowstopしていたチラー雑魚すぎstopしているところを流れるようにすると他が犠牲になる
  -  今後もし他の所がflowstopするようならDUTチラーと入れ替えも検討(DUTの方はflowも調整できるっぽい優秀)
 
 
 LGAD関係 
 
-  同時読み出し試験に参加した 
-  atlasosci…オシロ画面右下のイベント数の表示が見れない、データは取れていそう
  -  cmsosci…データ数はほとんどHSIO2とconsistent、データも取れてそう
  -  ADC…能力的な限界までは頑張っている(1回暴走した)、データは取れていそう
 
 
  -  なんとなくアライメントした→オシロでPixelの信号らしきものが見えた!
  -  温度が30℃くらいになった
 
 
 FEI4/ROI/Scinti 
 
-  Scinti 
-  MPPC1とMPPC3があまりにもレートが低いのでクビ
  -  ビームに対してレコフレームが曲がっている=シンチ同士の位置のオーバーラップが取れていない→フレームを動かして調整
  -  ちゃんと2層でトリガーとれるようになった
 
 
  -  ROI 
-  G10への取り付けが誤っていた→修正
  -  固定して他を動かすことにした
  -  NIMが出ない問題は、変換基板を予備(以前使っていたもの)に交替して解決
 
 
  -  FEI4のアライメントをした 
-  0層目…WEST 10mm
  -  1層目…EAST 5mm / DOWN 5mm
  -  2層目…WEST 3mm / UP 10mm
  -  3層目…WEST3mm / UP 5mm
  -  みんなしっかり合うようになった!
 
 
  -  →オシロでPixelの信号らしきものが見えた!
  -  温度が30℃くらいになった
 
 
 MALTA 
  
 引継ぎ内容 
 
-  ITK関係
 
-  3台multimodule読み出しをきれいにできるようにいろいろデバッグしてもらえると助かります。tuningもしちゃってくれたら感謝です。(柳瀬)
  -  online monitor でなぜか動くはずのitkpix関係のプロットが描画されなくなったので,デバッグしてみてください atlaspc24:/home/atlasj/work/FNALtestbeam202302/home/yutahie/SiliconTBSoftware/に今まで使ってたのがあります(比江森)使えるrun Numberはspreadsheet をみてください
 
 
  -  チラー 
-  raspi温度定期的に見てあげて、LGAD・ITkに限らず温度が上がってきていそうなら、十中八九チラーが原因なのでチューブ動かして流れるようにしてあげてください。特にLGADは暑がりなので注意してあげてください。
 
 
 
 
 昼シフト(倉持,久郷) 
 Calibserver 
 
-  calibserverを走らせようとすると" *****Another instance of calibserver is already running. Exiting. " と言われ、cosmicGUIを立ち上げてもすぐに落ちてしまう
  -  ssh -l root rce0 reboot しても直らなかった
  -  kill $(ps aux | grep 'calibserver' | awk '{print $2}') で直った
  -  今はrootする必要がないので問題ない
 
 
 
-  3 module読み出しを行おうとするとパターンが見える 
-  1 moduleだけなら良好
  -  2 moduleでもパターンが見える
 
 
  -  ROIがnoisyなので、シンチだけでトリガーをかけてextriggerscanを行った  
  -  tel HV -130vに変更  
  -  Selftrigscanはできなかった
 
 
 夜シフト(北今村比江森柳瀬) 
 ITk/cooling 
※configfileの名前がFNALとfnalやらで混在してたのでいろいろ揃えました。若干名前変わってても気にしないでください。
 
-  3台multiになるといろいろ読み出し上手くいかない問題 
-  fnal_extrigger.jsonである程度dataがたまるとコアダンプする&eventを落としてしまう。 
-  noisypixelをmaskできていないのが問題、ただmultiでselftrigger maskingを長めに回してもうまくmaskingができない。(20m)。
  -  maskingを手動で行って再度fnal_extriggerとってみる。
 
 
  -  Threshold scanパターン状に汚くなる現象 
-  原因としてはglobal tuningが全くうまくいってないものがあること
 
 
  -  そして突然PreprodQ17chip3がcannot communicationになった。→trim15にしても変化なし。次のaccessで電源周り確認 
-  LV調整、trim,preamp調整、温度低かったので上げてみる、DPケーブル交換など試したが現状復帰不能。→connectivity fileからchip3をdisenableにしました。
 
 
 
 
 
 
 
-   
-  なんか読み出しに関して問題がいろいろ突然起こり始めてるので以下に改めて現状をまとめます。 
-  PreprodQ03...4chipともcommunicationは取れるがglobal tuneが4chipとも全く機能していない。→configを作り直したら正常に読み出せた。なぜ突然tuneできなくなったのか原因は不明。
  -  PreprodQ17...chip3が突然cannot communicationでchip1,2,4はloopが回らない→configの作り直しやDP交換、LV・trim・preamp調整などいろいろ試したけど治らなそう。とりあえずchip3はconnectivityからdisableにしてます。loopが回らない問題はきっとscript上の問題だからそんな深刻ではない。
  -  KEKv1.1Q14...全chipともcannot communication。PreprodQ17のデバッグするためのaccess後に読めなくなった。→DPケーブル指しなおしたら全部正常になりました。
 
 
 
 
 
 
  
  
 
-  チラーの入れ替え工事した 
-  結果としてLGAD+ITkteleは無事flowが流れるように、チラー設定は0℃くらいでどのモジュールも20℃付近にいくようになった
  -  DUTのchilerは枝分かれなくてもflowが完全には流れてないのでこのままではirradが冷える気がしない→DUTをirradに付け替えるときにチューブの長さを可能な限り短くする工事を行う(TODO)
 
 
  -  online monitor でmodule hit mapが見られるようにした。correlation (FEI4 vs. ITK)はこれから
 
 
 LGAD 
 
-  ROIを入れたらLatencyが300ns付近に来た、よさそう
  -  MPOD経由でよさげなIVをとれた-->Temporaryにoperation voltage 180Vを決めた
  -  LeCroy でデータが取れない(レートが悪い)-->Extのターミネートが違った
 
 
 ROI/FEI4/Scinti 
 
-  ROIがトリガーに参加した-->Latencyが220ns程度になった
 
 
 MALTA 
 
-  トリガーロジックにROIが入ったので,再度外部トリガー試験を行った 
-  scintiのみでトリガーを作った時と,それにROIを入れた時では,基本的には200 nsくらい遅れる。それに対応するため,malta2のソフトウェアの中身(maltaSW/Malta2/src/Malta2Module.cpp)の中で与えられている。m_malta2->SetReadoutDelay(80)の値を変えることでレイテンシを調整できる。ユニットは3.125 ns。
  -  デフォルトは80だったが,150(差分が大体219 nsの遅延)にすることで大体一致した。
 
 
  -  malta2のオンラインモニタで見られるヒットマップは,malta2を正面から見たとき縦方向の軸を中心として反転している(つまり,左右反転)。また,しんちを上に動かしてからヒットの位置も上にずれたので,ヒットマップはmalta2を後ろから見た時と対応していそう。
  -  大事なメモ:FPGAからトリガー信号が受け取られているかを確認する術がある。 
-  maltaSW/Malta2/Malta2Module.cpp にある cout << "FIFO2 word count: " << numwordsCurrent << " ( " << m_malta2->GetL1ID() << " ) " << endl;をアンコメントアウトすると,受け取ったL1のカウンタが増えるので,それで確認ができる。
  -  latencyの調整と,trigger が受け取られているかの確認,これが大事。
 
 
 
 
 引継ぎ 
 
-  ITk 
-  PreprodQ03 のmasking(tuningは完了してます)
  -  PreprodQ17 のchip1,2,4のloop回らない問題の解消→tuningとmasking(chip3のデバッグは余裕あったらで)
  -  v1.1Q14のtuningのmasking
  -  multiでもmultiじゃなくてもいいので上記3つをお願いいたします。最終的な目標は3台multiきれいに読み出すこと。
 
 
 
 
 02/26(Sun.) 
 ITk関連 
 
-  PreprodQ03 
-  tuning : 完了 (run 003214)
  -  digital scan : 汚かったが、sldotrimを8->12で良好になった (run 003224)
  -  analog scan : 良好 (run 003249)
 
 
  -  PreprodQ17 
-  tuning : chip3以外完了 (run 003206)
  -  digital scan : chip3とcommunication取れない 
-  config作り直してもダメだった -> OhioかDPの問題な気がします
  -  chip3をdisenableして実行したところ、良好 (run 003232)
 
 
  -  analog scan : パターンが見える (run 003250)  
 
 
  -  v1.1Q14 
-  maskを行ったらscanできた
  -  tuning : 完了 (run 003214)
  -  digital scan : 良好 (run 003243)
  -  analog scan : 概ね良好 (run 003244) 
-  maskingを行ったが、これ以上はあまり改善しない
 
 
 
 
  -  3module 
-  digital scan : 良好
  -  analog scan : 概ね良好  
 
 
  -  selftrig scan 
-  configでSelftrigEn 0 -> 1
  -  PreprodQ03 で行ったところ、成功した (run 003275) 
-  あまりヒットがないのは出ていたビームが120GeV protonではなく、もっとintensityの低いelectron/pionだったためです
  -  PreprodQ03 以外のmoduleや、120GeV protonでどうなるか試してみて欲しいです
 
 
 
 
 
 
 Run Data taking 
 
-  only ROI triggerでgbusy=1.3msでrun
  -  LeCroy がうまくデータをとってくれない、オンラインモニターもFEI4しか見れない
  -  cd LeCroyscope 
./bin/startrun #event
であってるはず??
  -  ADCのDT5242を走らせてCtrl+cで止まってくれない
 
 
 
-  フトからの引継ぎ(maskingとmulti) 
-  Maskingはscanの-mではマスクしきれなかったので、Mask_noisePixel.cppの解析を使って手動で行ったら3台とも完璧にできました。tuningも全module出来ていることを確認して、masking,tuningともクリアしました。
  -  v1.1Q14 selftrigger #003337
  -  PreprodQ03 selftrigger #003342
  -  PreprodQ17 selftrigger #003339
  -  3台multiはanalogまではしっかりできるがtuningに差し掛かるとやはり不安定になるのでとりあえず今後multiでtuningはやめることにした。同様に3台同時のmaskingもselftriggerも、変なデータが入ってきてしまうのでやめる。(KEKでうまくいったのは何だったんだろう...)→KEKで試したのは6台のchipのmultimodule external trigger scanなので倍ちかくある11chipだと処理しきれない可能性は考えられる…ような気がするけどどうだろう(倉持)
 
 
 
 
 
-  fnal_extrrigerでeventを落としてしまう(3台multiで500Hzのとき、1spillごとにバンバンeventを落とす) 
-  考えられる原因 
-  maskingが出来ていないnoisy pixelがeventが入るのを邪魔している→masking後にevent数えたが、落とす数に変化はなし
  -  3台multiで読むことにより何らかの原因で落とす→1台でやったら落とすeventを~10event位に抑えられた。spillを重ねてもついていけている。やはりtuningやmasking同様にmultiが関係しているっぽい
 
 
 
 
 
 
 
-  hit mapをみたところITktele downがずれてしまっていたので(最初から足場のねじ止め位置が違った)west 20mmにアライメント
  -  その後アライメントでさらにDUTを west:7mm up:7mmずらす。
 
 
 MALTA 
 
-  位置がなんとなくずれていたので,なんとなく動かした。完璧なアラインメントになった!
  -  Online Monitorのためのコーディングに着手した。基本的には.root を逐一読んでいくことになるが,どうやらscanが終わったあとにWriteしているようなので,ソフトウェアをhackして逐次ヒット情報を書き込むような形式にする必要がありそうなのでそうする
 
 
 引継ぎ 
 
-  ITk 
-  (yanase)multiはもう諦めたのでデバッグは余裕あったらで。(tuning回すと更新されちゃうし、いちいち前のconfigをまたコピーとかし直すのだるいと思うので)
  -  (yanase)トリガー収集だけはmultiでもいいと思います。(eventは落とすけどhitmapはしっかりしてるので)
  -  (yutahie)online monitor for itkpixを加筆しました(atlaspc24:/home/atlasj/work/FNALtestbeam202302/home/yutahie/SiliconTBSoftware/)。
module hit mapとかDUT itkpixとテレスコープ,テレスコープ同士のcorrelation plotが見られるようになっています
ヒット情報が書き込まれている状態でDetDetailを選択するとsegfaultする気がするので,デバッグしてみてください(pixelHit class周りで怒られている気がする)
devel-yutahieにひとまずpushしました これからMALTAの実装をここにしていくのでpullなりすることをお勧めします
 
 
  -  MALTA 
-  読み出しのための超クイックマニュアルを書きました:https://docs.google.com/document/d/1idQ8WjHADwBuAGTpOlev2x8YQKcBzM1w7tZ-nUmsDoI/edit?usp=sharing
加筆修正はこれからもどんどんやっていきます
 
 
 
 
 2/27(Mon.) 
 昼シフト(倉持、久郷) 
朝、ラズパイが調子を崩してしまい、温度モニターができない状態に。
i2c通信はできるが、全ての温度計から値が帰ってこない状態。
beam lineにcontrolled accessして確認した結果カプトンテープが貼られておらず、shortした可能性が高いのはADCの先にある分岐の基板.
裏面にカプトンを貼って再起動したが、状態は変わらず。i2c通信はできる。
再度のshortを恐れ、一旦ラズパイを落とす。
ラズパイかADC基板を交換する必要があると考えられる。
 ITk関係 
selftrigger_scanをとってみる
primary userの関係でかなりビームが弱い状態でビーム位置がわかりずらいmapに
v1.1Q14chip4が時々読み出せなくなったりする。調子が悪い。
と思ったらHVがかかってなかった。ちゃんとモニターを見ること。
夜ちゃんとselftrigger scan見てくれるとありがたいです。
 夜 
 ITk/cooling 
 
-  selftriggerでmapをみて再びアライメント→done
  -  maskingについては時間を空けると新しく特大noisypixelが僅かに発生していたので、余裕あったら都度MaskNoise_pixel.cppで追加maskingしてあげる
 
 
 
-  fnal_exttrigger.jsonがMultiでeventを落とす問題 
-  TimonさんによるとSkip Block?(落としたeventをskipしてくれる)ソフトウェアがあるらしい。
  -  1.3mmBUSY 500Hzビーム(multi3台)→1.5%/1spill落とす
  -  1.3mmBUSY 300Hzビーム(3台)→1.2%/1spill落とす
  -  3mmBUSY 300Hzビーム(3台)→0.9%/1spill落とす
  -  3mmBUSY 300Hzビーム(2台)→ついていくけど数event落とす
  -  3mmBUSY 300Hzビーム(1台)→ついていくけど数event落とす
 
 
 
 
※raw.dataを数え上げるとき、Chipを変えるだけで数え上げるevent数が異なっていた。2台multi、1台に関しては落とすevent数はおおよそ一定(あるいは無し)の為、数え上げ(デコーダー)の方に問題がある可能性が高い。 
-   
-  というわけでいったんmulti(3台)は諦め。2台で読み進める方針
  -  ITk同士ならcorrelationはあるが、FEI4とのcorrelationがみれない...。
 
 
 
 
 MALTA 
 
-  今日はオンラインモニターを頑張った。 
-  MALTAのオンラインモニターであるMaltaMlutiDAQはなんとスキャンを止めたときにしか.rootにデータが記録されないという仕様がある。
  -  そのため,定期的に書き込むことができないかということでソフトウェアをハックし,TreeをFillしているところで同時にWriteもしようとしたが,なんかうまくいかなかった…。
  -  ので方針を変えて,ソフトウェアの中でイベント情報をバイナリに書き出すように改造することにした。Malta2Module.cppのRunメンバ関数において実際にMALTAからやってきたデータの処理とかをしている。ここでデータを直接受け取って,ファイルストリームに吐き出すようにした。 
-  正直合っているかわからないが,一応スキャンの途中でもバイナリファイルに書き出されるようになった。
 
 
  -  次にやることはOnlineMonitor側でdecoderをかくこと。基本的にはエンコーダーと逆のことをすればいいはずなのだが,なぜか不思議なところでセグフォしてしまう。この原因を追求する必要がある。 
-  ちなみにその場所はMalta2EventData.cpp L30 なぜかfor でクラッシュする。。。
 
 
  -  一通りコードが出来次第,向こうの人に確認してもらいたいと思っている
 
 
 
 
 LGAD 
 
-  昼のLeCroyデータうまく取れない問題-->TCPIPではなくLXIで通信の設定をして解消
  -  pixelとStripをまぜたrunをとり続けている。@180V。
  -  ROIを狭くしたら50nsくらいトリガーからの時間が近くなった(320ns-->260ns)
  -  40000evtだと書き出しに atlasosci:3min cmsosci:5min+ くらいかかる
  -  ITkDUT とセンターをそろえて、ITk Telのhitmapをもとに調整-->そもそもほとんどビーム中心にいたらしい-->correlationが見えた!
  -  信号もいい感じに見えている
  -  PMTの信号関して、8Vを超えるイベントが散見される <--> LeCroy は1Vスケールx8マスしか表示できないので、+2V~-6Vで表示することにした。さちるイベントは解析で抹消する
 
 
 ROI/scinti/FEI4 
  
 温度計 
 
-  温度計が壊れた。前日朝方から読めなくなったものをアクセスして確認 --> 予備電源で5Vをくべてもダメ。CCに引っかかる-->ショート?
  -  外で予備ラズパイにつないで確認する-->正常には読めない
  -  ADCのアンプかICが壊れた?先端の温度計が箱の中でショートしたかも
  -  とりあえず冷やせていそうなので温度計なしですすめる
 
 
 2/28(Tue) 
 
-  LGADのRunを40000eventずつdata taking
  -  Maria moduleとKEK moduleに同時にtriggerを発信できるようTLUのfirmのデバッグを行なっている
 
 
 LBL setup関連 
Mariaからsetup PCの接続方法とgraphanaのアドレスを教えてもらった。
LV,HVのremote controlおよびITk pix each chipのVDDA&接続されたNTC(1ch)のmonitorができる。
詳細な使い方は 
http://atlaspc5.kek.jp/do/view/Main/FermilabTestbeam2023 に記載.
DAQ pc adress : 
pixel@192.168.5.27
graphana: 192.168.5.27:3000
user:admin
KEKとLBL moduleに同時にtriggerを送れるようにするためMariaがTLUのfirmのdebugをしている。
15:00くらいに書き換えたfirmからKEKのmoduleにtriggerが発信されなくなる。多分書き換えたFirmのどこかに問題がある
 夜 (北、今村、比江森、柳瀬) 
 Itk関係 
 
-  ITkのcorrelationが見えない問題 
-  とりあえずデータ集め。ROIやビーム条件を色々変えながら測定(詳しい時系列は下にLGADさんが書いてくれてます) 
-  いずれもmulti2台であれば、著しくeventを落とすことはない(ずっと追従していく)→デコーダーの問題の確立高まる。
 
 
  -  木曜以降Timonさんにfirmwareを修正してもらうように交渉。
 
 
  -  Maria setup読み出し 
-  中村さんがITkと同時にトリガー受け取れるようにfirmを焼いてくれた
  -  同時に測定成功。
 
 
 
 
 LGAD関係 
 
-  condition : Pixel100umE600 @180V
(上流)、Strip4045E600@180V(下流)
  -  channeling (Pixel) 
-  channel 2 3 4 5 6 7 8 9 10 11 12 13 14 15
  -  amp 5 7 1 3 6 8 16 14 11 9 15 13 12 10
  -  LeCroyNo (無印-->中村LeCoy、カッコ-->ChrisLeCroy) C3 C5 C1 C2 C4 C6 (C7) (C5) (C2) C7 (C6) (C4) (C3) (C1)
  -  EXTにTLUからの信号、C8にPMT240の信号をTで分けて入れた
 
 
  -  channeling (Strip) 
-  channel 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
  -  amp 9 10 11 12 13 14 15 16 8 7 6 5 4 3 2 1
  -  TR0にTLUからの信号を入れた
 
 
  -  ADCは1.3msBusyにしても10kで数個イベントを落とす-->LeCroyだけでデータをとることに
  -  ROIの追い込みまとめ(時系列ぐちゃぐちゃ ごめんなさい) 
-  コリレーションを見た感じChip2に
  -  Strip key353 
-  ROIのコリレーションから99-111, 370-590
  -  col 49-61, row 34-254以外を全部mask
 
 
  -  Pixel key355 
-  ROIのコリレーションから100-111, 525-555くらいだと思う
  -  Chip2をmask。49-60, 189-219-
  -  ROIの場所を合わせるために全部LGADを1.5mm下げた後-->47-62, 146-182をROIに。
 
 
 
 
  -  PixelのちっちゃいROIでは1spill1000Events来ないくらいが来る。
  -  いいかんじのTimewindow設定。
  -  LeCroy が途中でデータを書き出さない問題。。。 
-  40kのrunを回すとデータを書き出す前にすべて忘れてしまう問題が発生
  -  こわいので20kずつとることに。(1run約30分)
  -  STOPボタンで止めた後はプロセスが走っている可能性があるので、気になるなら再起動-->Timeoutの設定を忘れずに(Time~のタブ->Horizontal->Sequence->2つ目のたぶ)
 
 
  -  PMTの信号がさちる問題-->3Vまでの設定で帰結 
-  6Vまでの信号を取る-->まだまださちっているイベントがあるように見えるが、これ以上は仕様の都合で無理
  -  LGADSoftwareのなかのfitph3.Cで波高分布を作成-->x軸3V以上を積分/全体の積分=0.3-->つまり3V以上のイベントは全体の3%-->3Vで切る
  -  phvstimeを作るとなぜか3.5Vで切れる…デコーダー?
 
 
  -  DataQuality 
-  20000eventsのデータで波高分布を作成@fitph3.C…クロストーク含めて信号見えてそう。MPV=0.05~0.06くらい?
  -  0.04V以上のeventsの積分/全体の積分=0.018<--->LGAD面積/ROI面積=0.02...2%程度、ほぼconsistent
 
 
  -  Noise評価 
-  chごとのNoise Histがresultに出力されるように作成
  -  信号込み&かんたんなgaussフィット-->1mV程度…デコーダーのバグを考えれば2mV程度で普段の測定と大差なし
  -  chごとの違いもほとんど見えない
 
 
  -  PMT time window 
-  run73のPMT信号でphvstimeを作った
  -  0.8V以上@250ns-290ns積分/0.8V以上@全時間積分=0.95-->0.8V以上の信号のうち95%は250nsから290nsのうちに来ている-->-330ns~-230nsの窓でOK
 
 
 
 
 MALTA関係 
 
-  主にひたすらオンラインモニタを実装していた(が,未完成) 
-  MaltaMulriDAQ が吐き出すntuple.rootが不便すぎる話を昨夜していたが,エキスパートに尋ねたところイベントごとにヒットやl1idなどをまとめた.rootとして再構成してくれるスクリプトをいただいた。確かに大変便利なので,これを用いてほかテレスコープとのcorrelation plotの作成に取り組んでいる
  -  一点問題なのは,MaltaMultiDAQが吐き出されるのはスキャンを止めた後のため,run中にデータの様子をモニタすることが難しいことである(うまく元のsoftwareの中身をハックすれば可能になるかもしれないが…)すなわち,現状一度スキャンを止めてから手で前述したスクリプトを回し,それをsiliconTBsoftwareに食わせてプロット等を作成するといった流れを強いられている。
  -  ひとまずdata qualityの検証を行うため,yutahie/silicontbsoftwareのrawdataconverterにmalta2rootReaderの開発を始めた。これはスキャンを終えて前述スクリプトを走らせたのちに生成させた.rootをconfig.txtで指定し,それをイベントバイイベントに読んでいくクラス。現状としては,GetAnEventで実際に.rootからイベント情報を読み出すところがうまくいっていない(ROOT何も分からない)。イベントごとにヒット位置やtimingを含めた情報がstlのarrayとして書き込まれているのだが,それをうまく読み出すことができていない
  -  
 
 
 
 
 3/1夜(今村、比江森、柳瀬) 
0:00 ほぼぴったりにプライマリーユーザーの方が来る(1人)-->マネージャー待ちの間はビーム変えないのでデータとっていいよとのこと、とりあえず取り続ける
3:10 プライマリーユーザーの判断でビームを動かした、HitMap確認#322→ROIを開いてHitMapで位置調整(→horizontal 350.6 vertical79.9) TLU#323 
ステージ動かしたら1100~1300cnts/spill →1189cnts/spill になったので完璧
あとビームの音怒られたから消した
4:00 プライマリーユーザーのControl Accessで9000evtsほどで中止 TLU#325
ビームのレートを高くしたとのこと、1M個・?
4:20 ビーム見えないと思ってビーム動かした?ってprimary userに聞いたら動かしてないといわれたので見てみたらscintiがcurrent tripしてました。TLU#327
どうやらビームが来たタイミングでcurrent tripしている(beam rateが高いせい?)→voltageを55Vに下げた(tripしないぎりぎり)けど3cnts/spillしかとれない→シンチの限界?-->インテンシティが高すぎるのが悪い?-->ステージを動かしてビーム中心からあえて外してみる(ITk self trigger-->stage moving 10mm down-->stage moving more 5mm down-->stage moving more 5mm down)
→シンチ(58.5V)のcurrent tripさせずにtrigger rate(700~cnts/spill)に上げることに成功 これでやってみます TLU#330
#330 TLU connection error? --> #330のかぶり。上書きされると思うので、前の#330がゴミになるかも-->ゴミになりました-->
とったデータは生きてるのでTLUを解析に入れなければ使えるよ!byきたさん
 Itk関係 
 
-  夜飯前に走らせたrun(ITk#3653)でITk-FEI4にcorrelationが見えた
  -  これまでtele2台でのrunだったので#3654以降は基本的にDUT(PreprodQ17)で走らせる 
-  correlationが見えなくなった。。Chip1にnoisyなやつがいたのでそいつが原因?都合つくときmaskingをおこなう。→masking行ってもダメだった
  -  再度tele2台で走らせたらcorrelation見えたので、teleのcorrelationは偶然じゃなさそう#3660
  -  tele(上流)ーDUTで走らせたら、この2層間のcorrelationのdataがでてこない(kojin onlinemon)#3661 
-  yutahie onlinemonで走らせたらtele(上流)ーDUTのcorrelationは見えたけど、さっきまで見えていたITk-FEi4のcorrelationは見れない。
 
 
 
 
 
 
     <onlinemon> 
-   
-  yutahie onlinemon...tele-FEI4にcorrelationは見えないが、tele-DUTは見える
  -  kojin onlinemon...tele-FEI4にcorrelationは見えるときと見えない時がある、tele-DUTのcorrelationのデータそのものがない
 
 
 
 
      →ITkのcorrelation問題はonlinemonが原因の可能性もある
 LGAD 
 
-  夕ご飯まえに走らせた40Kevtsは取れていなかった模様…run93は夕飯後のデータ20Kのものに
  -  とりあえず180Vで20Kごとデータ取得開始
  -  HV scan 
-  190V-->low noise =almost the same for 180V
  -  200V-->Noisy? over 1.3mV 
  -  120V、140Vはいったん20Kだけ
  -  160V、170Vはそれなりに回した
  -  175Vはビーム移動などでまともに取れてない… 
-  ビーム中心からずらした後のデータを見てみると、信号が小さくてあんまり見えてない…?
 
 
 
 
 
 
 3/2昼(倉持、久郷、中村、北) 
引き継いだ時にrun回ってた。けどプライマリーユーザー回ってきたのでビームをほしい位置に移動。(夜から2cmレコフレームを上げた) intensityも下げた(3000くらいに)
10時ごろに他のユーザー(MT1?)がアクセスしたがってたのでいいよって言ったけど人がいないので結局まだしてない。(15:40現在)
 Itk関係 
 
-  Mariaのmoduleを2runくらいデータを取った
  -  一度sshしていた側のPCが落ちてしまい、HVコントロール不可に
  -  夕食から帰還後、HV power supplyへの命令ができるように
  -  100VのHVをかけて今晩は動かさないようにする
  -  Maria setupのremote LVをDUTに繋ぎかえた.
 
 
 
-  オンラインモニターは一度FEI4とITkとのcorrerarionがみえたが、daqを指定して読み込ませるようにプログラムを書き換えたところ再びコリレーションが見えなくなった。ちゃんと当たってるはずなのでおそらくデコードの問題。
  -  MALTAのオンラインモニターとITkのコリレーションが取れるブランチのmarge作業をぼちぼち進めているが使えるようになるのは明日以降になりそう……
  -  FEI4とのコリレーションを見たplotではInter ASIC部分のnoiseが大きい様子だった。
efficiensyも出せるようになりたいところ(どうやればいいのだろう…)
 
 
 
-  atlaspc24でFNALTestbeam202302直下にあるITkPixelディレクトリとmaltaディレクトリは直接pc26からハードマウントしていたのでシンボリックリンクに変更した.(すいません…) maltaは変更完了したがITkPixelがうまくいかない。
 
 
 LGAD 
 
-  昨日取れないと言っていたrunはやはりエントリー数(ヒット数)が少ない。-->これはたぶんPixelに当たってないと思う。。。
  -  時間分解能を調べてみた。各LeCroyで一番波高の高かったやつをmaxphとしてそれとPMTとの時間差を算出。 
-  20kイベントでガウス作れそうなのが数イベントしかない。
  -  20kを1runとして5runあれば無理やり作れるか。解析次第でどうにかなるかな。。。
  -  方針としては時間分解能vs電圧の作りたいやつは5run、詳細に知りたいやつはたくさんrun回すことにした
  -  らいくりふっどfitをしてみると大体100~120psくらい。クロストークも含まれているし解析でちゃんと出ると信じてとる。
  -  160Vは120Vと140Vと170Vのさがっている間だし時間もないので5run追加はしなかった。
  -  プラトーになるところは大体180~190V。なので195Vを5runついか。
  -  時間分解能位置依存性を見たいので180Vは取れるだけ取る
 
 
  -  とったまともそうなLGADデータはここにメモしてあります(https://docs.google.com/spreadsheets/d/1XRUbQSInpy4nGHU3PKRUtpUc-YjXKrPXJLe2ci1NKQY/edit#gid=0
)
  -  昼シフトまでで取れてるVscan(20kを1runとして)  Pixel100umE600 
-  120V 5run
  -  140V 5run
  -  160V 2.5run
  -  170V 5run
  -  175V 5.5run
  -  180V 13.5run
  -  190V 5run
  -  200V? 1run
 
 
 
 
 3/3夜(比江森、柳瀬、今村) 
 
-  引継ぎ時にアクセス、その後1run回したあとで再度アクセス
  -  Run中の問題 
-  TLU Numberの表示が268だったけど実際は269だったことがあった。HSIO2立ち上がりきる前にトリガーstartrunしたかも
 
 
  -  0:10 ビームのrateが1Mになったため、stageを15mmdown(→64.7)
  -  0:55 LGADに入っていなかったのでstageを5mmup(→69.5)
  -  1:10 LGADtrigger rateあげるためstageを5mmup(→74.6)
  -  1:30 LGADtrigger rateあげるためstageを5mmup(→79.7)
  -  1:40 accessとかで1h Beam停止
 
 
 LGAD 
 
-  Stripに変えてvoltage scan
  -  LeCroy がたまに時計を表示しないが、データは取れている模様
  -  ビーム中心動かしてからすごくノイジー。データ使えるか不安
 
 
 ITk 
 
-  Run自体はずっとtele2台で走らせてました。noisyなやついたので途中2台ともmaking挟みました。(なぜ時間経過でnoisyなやつが新規生成されるのか。。)
  -  MariaPC でPreprodQ17を動かして、最終的にはatlaspc26→tele2台、MariaPC→MariaQuad+ITkDUTの体制で読めるようにしたい 
-  atlaspc26に繋がっていたDPケーブル(PortB)をMariaPC(PortB)に挿した
  -  その後LVをPOR
  -  PreprodQ17config をatlaspc26からscpして回してみたが、cannot communication
  -  atlaspc26からscpしてきたconfig(PreprodQ17Chip1)とMariaQuadのconfig(0x130b6_L2_warm.json)のパラメータを比較して異なるところをまとめてみた(diffThとかTrimは除く)
  -  
   |   |  Maria |  KEK |  
  | cmlbias0 |  900 |  1000 |  
  | cmlbias1 |  400 |  200 |  
  | DiffLcc |  500 |  100 |  
  | DiffLccEn |  1 |  0 |  
  | preamp |  500 |   800 |  
  | FineDelayclk |  5 |  0 |  
  | InjVcalHigh |  343 |   413 |  
  | MonitorV |  34 |   63 |  
  | pixportal |  3325 |   56805 |  
  
  -  KEKパラメータをMariaパラメータに1つずつ変えてみたがやはりcannot communicationでMariaが振り向いてくれない。MariaQuadそのものは読み出せるので、考えられる原因は、 
 
  -  本命:MariaPCのportBが死んでる(MariaQUAD に繋がってるportAとかと入れ替れば確認できる。)
  -  対抗:別の正式なconfigfileの作り方がある(Gitとか見たけどどこにあるかわかりませんでした。もしなかったらMaria/Kehangに聞くのが早いかも。)
  -  大穴:PreprodQ17が急に読めなくなった(atlaspc26に戻せば確認できる) 
 
  -  夜はaccess初めのLVのPORの時しかできなかったので、config file周りしかいじれなかったですがもしaccessするタイミングあったら上記試してみてもいいかもです。 
 
 
 
 
 
 03/03(Fri.) 
 
-  pc24:work/FNALTestbeam202302/ITkPixel をシンボリックリンクに直した。
  -  DUTは動かないのでmaria moduleを動かしてdata taking
 
 
 3/3昼(倉持、久郷、中村、北) 
 ITk 
 
-  LGADのサンプル交換のControlled accessの際にMaria setup PCをいじってKEKPreprodQ17が動くかどうか調べた。
TLUが繋がっているportD以外の全てのportで"Can't establish communication"となった。(portA,B,C)
  -  pc26に再びDP cableを繋ぎ、scanすると以前のようにchip3以外はcomminication可能
  -  FPGAとLVのGNDが異なるのが原因ではないかと考え、Maria setupのLVに繋いでscanしてみたが"Can't establish communication"
  -  DUT PreprodQ17 はpc26に差し直している状態。今後はtelescope 1枚(PreprodQ03)とDUT 1枚体制(PreprodQ17)でdata takingを行う。
  -  Maria moduleを繋ぎ直したところ、comminicationはできるがscan Loopが回らない状態に。 
-  Controlled accessの時にfnal_extrigger scanを回しっぱなしにした状態で冷却用のファンの電源を切ってしまい、moduleが80度以上の高温になってしまった。その際にmoduleが壊れてしまった可能性あり。LVを切ってしばらく冷やして復活するかどうか待機中。 
 
 
 
 
 
 LGAD 
 
-  StripのVscan。 
-  120Vでるくろい画面をぼーっと見てると全然信号生えてこない。140Vなら生えてくる。-->最小のvoltageは140Vにしよう
  -  Vscanしたやつ:各4runずつとる 
-  時間分解能でるかの確認。
  -  見解:4runで出ることは出ると思うけどノイズでっかいのでよい時間分解能でる気はしない
 
 
  -  180Vでのデータをとにかくいっぱいとった。
 
 
  -  昼過ぎ:サンプルの入れ替え:pixel100umE600薄いやつ(上流)とchillted pixel 100umピッチ50um厚(下流) 
 
 
 
 3/3夜(今村、比江森、柳瀬) 
 
-  ~0:00 primary user来るまでEDMを流すことにした。作業効率爆上げ。
  -  0:20 BeamRate 上がった。 
 
  -  LGADのためにマスクをいろいろと変えて試していたところ、急にトリガーが出なくなる 
-  マスク動かしすぎ?-->ITkセルフトリガーでチェック、そんなことはなさそう-->ROI chip2をフルオープン-->やっぱりマスクは悪くなさそう
  -  PicoのAトリガーで見えていない-->シンチがダメかも-->S2Rでトリガー出すようにファームウェア書き換え-->やっぱりでない…-->シンチ濡れ衣
  -  ROIが悪いかも-->ROIのSELFTRIGGERみてみる-->355/352maskでは見える-->マスクで範囲広くしすぎるとダメ(ノイジーなのが入るから)と結論
  -  
 
 
 
 
 ITk 
 
-  Maria生存確認 
-  config fileをコピーして昨日変えなかったTrimを2,4,6,8,10,12,14,15にして読み出したがいずれもLoopが回らない。
  -  以前PreprodQ17でも全く同じ現象があった(そのときはconfigを作り直したら上手くいったらしい)が原因と解決策はわからない。。
  -  ただLoopが回らないのはChip configとかscan configとかの問題で、Moduleのダメージによるものの傾向ではない気がする。(勘) 
 
 
 
  -  ITkのcorrelation確認 
-  kojin onlinemon(3/3 23:00現在)をyanaseにpullして色んなRunのデータを確認 
-  TLU#249 3台multi 27001events→ITk間〇、ITk-FEI4間×
  -  TLU#253 3台multi 46231events→ITk間〇、ITk-FEI4間×
  -  TLU#262 tele2台 20548events→ITk間〇、tele-FEI4間 前半△後半×
  -  TLU#303 DUT1台 32001events→DUT-FEI4間 前半×後半〇
  -  TLU#307 tele(Q03)+DUT 22548events→ITk間〇、ITk-FEI4間 前半〇後半△
  -  TLU#321 tele(Q03)+DUT 17001events→ITk間〇、ITk-FEI4間×
  -  TLU#353 tele(Q03)+DUT 21001events→ITk間〇、ITk-FEI4間〇
  -  TLU#364 tele2台 25001events→ITk間〇、ITk-FEI4間 前半〇後半△
 
 
  -  以下まとめ 
-  ITk-FEI4間のcorrelationはFEI4(ly1)とはXY,YXで見られ、FEI4(ly5)とはXX,YYで見られる。
  -  ITk間のcorrelationは全て完璧に見れる。
  -  3台読み出しはそもそもevent落としてるし、ITk-FEI4間correlationは確実に見れない。
  -  2台以下の読み出しだと基本的にはどこかでITk-FEI4間もcorrelationは見えるが、ずっとはっきりしているケース、途中から出てくるケース、後半見えなくなるケースなど関連性は見られない。前から言われているようにITk側のデコーダーに問題がありそうなので、そのせいでskipしているeventがランダムに影響を及ぼしていると考えられる 
 
 
 
 
 
  -    
 
 
 MALTA 
 
-  引き続きonline mon の開発 
-  CORRELATION vs. FEI4 見れた!!!!
  -  その後,TLU#425 でITkとのcorrelationも見ることができた。最強のテレスコープの完成。 
 
 
 
 
 
 LGAD 
  
 03/04(Sat.) 
 
-  今日はMCRに他の人全然いない。おじちゃんひとりしか来なかった。土日はみんな休みなのか…
  -  15:38頃 LGAD動かすためにcontrolled access。tiltedが入らなかったのでレコフレーム3号車をちょっとだけ後ろにずらした
  -  何回かレコフレームの位置を動かしてますが最終的に元の位置に戻した。動かしてる最中の北メモはおそらくclass0になってる気がする
 
 
 3/3昼(倉持、久郷、中村、北) 
 ITk 
 
-  オンラインモニターを回してコリレーションの確認。うっすら見えるrunと見えないrunがある(ROIが小さいから?)
 
 
 LGAD 
 
-  tilted pixelのROI探し。 
-  夜からの引継ぎで今までのROIじゃ見えない+chip2を見ると信号はあるとの情報からとりあえずchip2のROIをフルオープンにしてデータtaking
  -  chip2のcol56-64, row104-134になんとなくそれっぽいものが集まっているのを発見。
  -  ここにいそう?-->いなかった…
  -  そもそもROIトリガーのデータがノイジーでコリレーションが見えない。
 
 
  -  ステージを動かしてビームの位置を変えつつセルフトリガーでるくろいを眺めることに 
-  chip2(右上):4events/spill
  -  chip3と4の間(下):7events/spill
  -  下の方にあるのか?
 
 
  -  
 
 
 3/4夜(今村、比江森、柳瀬) 
 0:00 ビーム1MHzになる
 2:00 イメチェンパパイヤcontrolled access 1h15m
 6:55 Triggerがでない-->busyがあがってる-->HSIO2コアダンプ-->192.168.1.10にpingが返ってこない-->DHCPサーバーが落ちている-->rootでsystemctl dhcpd.service-->pingが返ってこない-->nmcil connection modify HSIO2 ipv4 never default true-->pingが返ってこない-->中入って作業しないとダメでは…?-->GUIでぱちぱちしようとしてもHSIO2が出てこない…(選択肢が1つしかない、ささってない認識?)
 ITk 
 
-  onlinemonitorデータチェック 
-  @倉持、久郷  ./mkconfig [No.]でconfig.txtに引き渡される数字をあらかじめdetconfig.txtに入力してデータチェックすれば効率的と言ってたんですけど、それだと数字合ってるはずでもpreprodQ17のhitmapなぜかずれてたのでdetconfigはいじらずに毎回configの方いじるようにしてみてください。
  -  #303~最新まではとりあえず一通りチェック終わりました。所感としては、なんか前半の方がcorrelation見える確率が多かった気がします。
  -  TODOとしては、余裕あるときに、#303以前のチェックと、「データはいらん」って書いてあるところもう一回試してみてください。
  -  diffのコードかきましたby比江森(atlaspc24のyutahieのdevelにあります)
 
 
 
 
 LGAD 
 
-  ROIを1/4ごとに動かして探索 
-  0-40/0-168 (chip図左下) : 208,209,210 
-  correlation : 心の目で見ても見えない
  -  >50mV ratio : 0.07%~0.09%
  -  

 
 
  -  0-40/168-336 (chip図左上) : 211,212,213 
-  correlation : 心の目で見ても見えない
  -  >50mV ratio : 0.09%~0.1%
  -  

 
 
  -  40-80/168-336 (chip図右上) : 214,215,216 
-  correlation : なんとなく見えてる?
  -  >50mV ratio : 0.07%~0.09%
  -  

 
 
  -  40-80/0-168 (Chip図右下) : 217,218 
-  correlation : 1番見えてる -->x=60, y=? run218ではあまり見えなかった…
  -  >50mV ratio : 0.045%~0.05% <--correlationは1番見えてるけど、信号はあまり来てない…?
  -  

  -  

 
 
 
 
  -  ROIをChip図右下 & x=60だと信じて追い込み 
-  50-70/0-84 : 219,220 
-  correlation : 見えなくなった…?-->2run目では見えた!yはよくわからん
  -  >50mV ratio : 0.04%~0.06%
  -  

  -  

 
 
  -  50-70/84-168 : 221,222 
-  correlation : 見えなくなった…?
  -  >50mV ratio : 0.06%
  -  

 
 
 
 
 
 
 MALTA 
 
-  
 Maltaがなんかノイジー?なことに気づいた。
 最近までは見えてなかったように思うが… どうもIDB threshold が低い時によく見られるようなノイジーヒットマップがなんだか見られる。
 ・例として,ハイレートビームの場合での#TLU458 をあげる。ただ,通常にビームレート(300kHz)でのラン#TLU451 でも同様のパターンが見られていたので,少なくともここ最近現れたものっぽい。
 ・ひとまずIDB105 - > 110 とした。これで再度様子を見てみる
 ・もしかして最初から見られていたのか?ということで,昔のランをいくつか振り返ってみる
 ・run #TLU84 とても綺麗,ほぼノイジーヒットなし
 ・run #TLU200 ノイジー?なんかROI以外に当たってるヒットが多い
  
 IDB=110にした。  
 —> 現時点で最新のランである238だと特にノイジーヒットが多い…  
 Timing のベースラインが浮いているので,timingのピークの周り 190 ~ 220だけでカットを入れると,マップで見た時のちらほら存在するヒットが減った。やっぱりノイジーなのか。
  -  本当にノイジーなのかを確かめるためにnull runをやってみる(Beam なしでとるnoise scan) 
 
 —> 全くヒットなし(time window 1000 us, repetition 50 times)@IDB105~110。不思議。  
 -t 3000, -r 50 @IDB110
でのnoise scan, ちょうどbeam来たとき:low IDBの時に見られるようなパターンの傾向は確かに見える。が,ビームがいなくなるとhitも0にすぐさま落ちるので,threshold のばらつきみたいなものがhigh intensity beamに当たることで見えている?  
 low intensity で見てみたい  
 
 
 03/05(Sun.) 
 3/3昼(倉持、久郷、中村、北) 
 
-  朝 controlled access。 
-  HSIO2の通信を直しました。電源の抜き差しで
  -  下流側丸太が上にありすぎる。1枚座布団を抜いた。
  -  クラモチ、まりあLVにDUTLVをさした。遠隔でLVOnOffできますbyクラモチ
 
 
  -  10:30すぎ、ビームでなくなる。 
-  いつでるの?って聞いたらcouple of minitsって言われたけどもうかれこれ1時間でてない。
  -  かれらの言葉を信用しすぎてはいけません
 
 
  -  ROIの信号が長すぎるのが気になる。ROI見つけられない。 
-  短くしようと思って可変抵抗を変えてみたけどダメだった。10usから短くならない。
  -  新しく作った基板、壊れてたと思ってたけど実は壊れてなかったし可変抵抗こっちの方がまともなのでこっちを使うことに。
 
 
  -  15時過ぎ、LGADのROIが見つからないので色々やりました 
-  下流の丸太の座布団を1枚戻した
  -  EASTへ1cmずらした
 
 
 
 
 ITk 
 
-  PreprodQ17 (DUT)のLV電源をMaria setupのLVに変更した。リモートでpower-on-off可。
久郷さんがgraphanaでモニターできるようにしてくれた。
  -  代打の温度計ADC基板をテストしていたが一つはうっかり逆につないでクラモチが壊し、もう一つはそもそも動かなかった。
Maria setupのNTCのmoniter機能を使わせてもらおう。
  -  乾燥空気などのセットアップをToddに手伝ってもらいたいので照射済みmoduleの交換は月曜朝にやります。
  -  今日とったdataはほとんどcorrelation見えませんでした。南無。beamrateが高すぎたのが問題?
 
 
 correration 
 LGAD 
 
-  昨日とってもらったデータをconbineしてチェック。80mV以上をヒットと定義。
  -  ROI左下のみ(3run分):ROI左下全部がなる。コリレーションない。
  -  今村さんがしんじてる場所50-70/84-168(4run分):ROIにした部分がなる…コリレーションもあまり見えない。
  -  EXトリガーでいまむらさんのROIでオシロを眺めてみる。-->ない?
  -  色々がんばりました 
-  中村さんのC6にS0S1のAND信号、C7にROI、C8に吉田を入れて今村サイズのROIを動かして永遠書き続けるモードのC2トリガーでオシロスコープを見る 
-  トリガーから200ns後ろに生えてくるROIを眺めて一番多いところがそうだと判断することに
  -  168-252, 50-70:4本/5spill
  -  84-168, 50-70:1本/4spill
  -  0-84, 50-70:0本/5spill
  -  168-252, 50-70 (再現性の確認):1本/5spill
  -  168-252, 70-80:5本/4spill
  -  84-168, 70-80:4本/6spill
  -  
 
 
  -  これから84ー252、70-80にあればきっと入るだろうと思い測定を開始。
 
 
  -  丸太下流が入ってなかったので移動(-->最初のログ)
  -  
 
 
 3/6夜(今村、比江森、柳瀬) 
 
-  23:15 Controlled Access 
-  ITk chiller tube cut
  -  ITk DUT Maria Temparature connection
  -  MALTA upstream WEST5mm-UP5mm
  -  LGAD tilted --> 20um
 
 
  -  00:20ごろ beam position 移動といわれる-->ITk selfで見る限りそんなに大きく移動してなさそう?
  -  ROIが動かない…-->config fileがダメになったかも…-->#353にしてみる
  -  6:00すぎ triggerがでていないことに気づく 
-  picoを見る限りROIはなってそう(うるさそう)
  -  ROIがノイジーなせい?-->SELFTRIGGER : 最大14とか。ノイジーがないわけではないが、そんなに響くかな…という感じ
  -  trig beamをpicoのtriggerにしてみてみると、ROIはちゃんと働いてそう --> シンチ死んだ…?でも電流値電圧値は正しそう
  -  かにの生存確認を兼ねてfirmをRS0S2からRに焼き直してみる --> triggerでない、ROI Hitとbusyは死んでないのに信号でない…-->かにが悪い…?
  -  かに犯人を確定させるため、S0S2のfirmを焼く-->trigger出ない…
 
 
 
 
 ITk 
 
-  上記にもあるようにDUT chillerのtube cut・NTCをMaria setに付け替えてLV同様にmonitorできることを確認した。乾燥空気の準備が出来次第いつでも冷却試験可能な状態に。 
-  chillerは0℃設定でLV,peltierONでmodule15℃付近になるのでnonirradなら5℃設定位がいいかも。
 
 
  -  ITk データチェックをひたすら進める。 
-  #196以降は基本的にチェックした。(あとは随時Run走らせるのと並行して)
  -  #211以前のデータはcorrelationの欠片もないgomi(Run summary見るとITkが安定して走り始めたのは#219以降っぽいのでまあ妥当)
  -  今日のITkデータはほとんどcorrelation見えず。後から聞いたらbusyが10μmになってたらしい。そのせいでefficiency rateが高くなって落としたと思われる。
 
 
 
 
 LGAD 
 
-  ROI chip2 50-80, 168-252でひたすら測定...20k x 15run = 300k evts
  -  20um pix 
-  全ROIオープンで取ろうとしたらtriggerが出ない…とごちゃごちゃしているうちになぜか時計が出てきてLeCroy同士のrun numberがずれました
  -  02:30 編集しようとしたら、ROI chip3にいたるまでのすべての記録が消えていました… Onlinemonitorの結果だけ載せなおしておきます(.. )  
  -  とりあえずchip3と信じ込んでやることに  
  -  chip3の中でさらにいろいろ調べたが、とても当たっている気がしない。DUTはROIの外の右下にあるのではと予想。
  -  LGADSoftwareで解析した結果、50mV以上の信号がほとんどいない-->やっぱりKEK114とDUTはかぶっていない疑惑
  -  LeCroy 中村の画面でExt triggerでforever描きしてみてみる 
-  chip1 信号の芽すらいない
  -  chip2 信号の芽すらいない
  -  chip3 信号の芽すらいない
  -  chip4 信号の芽すらいない
 
 
 
 
  -  
 
  
 MALTA
  -  23時頃のcontrol access で位置を動かした後,上流maltaが全くヒットを残さなくなってしまった。
  -  FPGAとのコミュニケーションは取れているため,FMCより先で繋がっていない 
-  出る前に延長ケーブルが繋がっていそうなことは目で確認したが… コミュニケーションが取れることを中で確認するべきだったか。いずれにせよどこかのタイミングでprimary user に相乗りしてアクセスできそうならしたい。
  -  なんかわかんないけど、次のrunから普通に稼働するようになった。謎
 
 
 
 
 03/06(Mon.) 
 3/6昼(倉持、久郷、中村、北) 
 
-  トリガーはFirmwareを焼き直したあとにtrigenableすると普通にでた。よかった
  -  ROIのchip4枚を一度に動かすとトリガーが出ない。こまった-->ひとまず2chipずつで回した
  -  大体ROIのみトリガーでデータをとった。たぶんスプシにかいてある。
  -  ビームポジションscanのためにレコフレーム台を結構動かした。 
-  初期位置:(72.1, 356.4)
  -  最終的にはビームポジションが昨日と同じくらいになるように設定:(79.7, 356.7)
 
 
  -  11:23 lilacの関係でビームストップ。30分~1時間?。その間にcontrolled access  
 
 
 ITk 
 
-  DUTの冷却ボックスにホーム剤を囲い、冷却テスト。Toddに乾燥空気の使い方を聞いた。乾燥空気の欄のつまみは二つとも開けないとダメ。ただめちゃくちゃ流量が弱い。
チラーを-15度に設定して冷却テストしたが7度をピークにだんだん温度が上がっていく。測定中の発熱に耐えきれてない。
そもそもチラーが冷却できないのでIrradのtestbeamは断念
  -  timonさんからskip eventを確認するコマンドを教えてもらった。コマンドは以下の通り
$./bin/read-register -r configs/controller/specCfg-rd53b-16x1.json -c configs/connectivity/moduleconnectivity.json SkippedTrigCnt 
すると
0
0
0
0
done!
とskipされたevent数を各chipごとに出力してくれる。
  -  2moduleのrunをみてみたらskip eventは0。3moduleのrunを走らせる。
  -  3module runはやはりコリレーションがだんだん見えなくなってくる。しかしskip eventは0
  -  おそらくyarrのsoftwareとfirmwareに問題があると考えられる。
  -  timonさんに教えてもらい、yarrのdebugを行う。
  -  specRxCorr.cppの68行目に
SPDLOG_LOGGER_DEBUG(srxlog, "Read data to Addr 0x{:x}, Count {}", dma_addr, dma_count);
を書き足し、ターミナルにプロセスが出力されるようにした。
  -  yarrのコンパイルがオフラインでできないので中村さんのpcに落としてcentOS上でコンパイルする必要がある……centOSの仮想環境があればコンパイルできる…
  -  yarrのリコンパイル方法:yarrディレクトリ直下で
make -C build -j8 install
  -  teeというコマンドを使ってlogを出力
./bin/scanConsole いつものfnal_extriggerscan.jsonのコマンド -p -m 0 2>&1 | tee -i log_hoge.txt
でlogが出力できます。
  -  久郷さんのBare ITkpix telescope PCBがベリーズとかいう得体のしれない国に送られそうになっている。現在地フロリダなので行く気まんまんで怖い
 
 
 LGAD 
 
-  PixelのROIが見つからない…
  -  麻のcontrolled accessの時に当たらなさそうだからLGAD本体を上に5mm、右に5mm?(初期位置に)動かした。
  -  ROIだけトリガーにして見たけどchip1,2,3,4それぞれで見てもセンサーが見つからない。-->ROIの外にあるのか?
  -  ビームポジションを動かして(=レコフレーム台を動かして)セルフトリガーで一番鳴るところを探す。 
-  初期値 (72.1, 356.4)
  -  縦方向scan:72.1から動かした経緯、1spill大体いくつ見えるかをカッコに書いた 
-  80.0(0)-->90.0(0)-->60.0(1)-->50.0(0)-->55(1)-->65(3)-->70(3)-->75(2)-->72.3(1)-->65(4)
  -  65にあるのか?
 
 
  -  横方向scan:356.4から、1spill大体いくつかをカッコに書きました。縦方向は65でscan。 
-  376(0)-->371(1)-->366(1)-->361(0)-->356(5)-->351(5)-->346(5ちょい?)-->341(4)-->336(3?)-->331(1)-->326(0)
  -  356-336にある?-->中心は350くらい?
 
 
  -  結論(65, 350)が一番ビーム当たってそう-->LGADはこの位置にある=ROIchip2の上の方
 
 
  -  LGADを下に7mm、左に6mm動かした 
-  左に動かすのはメモリが全然見えなかったので目分量で動かした
 
 
  -  ビーム位置を初期位置(72.1, 356.4)にもどしたけどビームがちょっと上すぎたので(74, 351)に移動
  -  chip2でデータをとる 
-  chrisのC1C4C5C8がnotactiveに。こまった。
  -  本人に助けてもらったけどだめでした。
  -  D/setuosの設定ファイルを消すとなおった。 
-  DC50Ohm にしたり、通信をTCPIPから違うやつにしたり、保存ファイルを指定したり…色々やり直した。
  -  保存されるファイル名がTraceXX--00000にかわった。なんなんだ
 
 
 
 
  -  chip2でとった中村さんデータを見るになんとなくROI100-120、490-525にありそう。
  -  chip2のmaskを40-60、149-189に設定。とりあえずデータをとり始める。
  -  ほんとうにごめんなさい。しばらくカニアンプ6Vをかけ直した。
 
 
 03/07(Tue.) 
 3/7夜(比江森、柳瀬、今村) 
3:10 Magnetの関係でbeamが止まる(20m)
 4:45 Preimary Userの指示でbeamが若干eastに。ただ動いたのは1mmくらいだったのでフレーム位置は変えない。
 ITk 
 
-  coolingについて 
-  23:30頃controlled access
  -  断熱スタイロフォームをしっかり密閉&チューブをウレタンを簡易的に断熱した。
  -  上記の作業中に力が加わってしまい、チューブから不凍液がほんの少し漏れた(10mlくらい?)ので再補強。
  -  その後、チラーがエラー(flowが足りない)を吐いて止まってしまい、LV止めたが、ペルチェのせいで徐々に温度上がり始めてしまったので、1:30頃primary userに頼んでaccessしてペルチェだけ止めに行く。(accessしていた5~10分間くらい8:00以降延長してほしいといわれたので延長すると思います。)
  -  エラーの内容↓
  -  
  
  -  PreprodQ17 のデータが取れない分、teleupをDUTにしようとしたが、墓標のため、位置を動かせず、夜はDUTのデータを取ることを断念。→tele2台で走らせる。
  -  朝LGADのaccessと同時に、チラーに水を足して昼にPreprodQ17のデータを取れるようにする。(irradは諦める)
 
 
  -  データチェック 
-  チェック終わっていないデータのcorrelationを見ていたら、昨日昼シフトでyarrのdebugをしてる時?に回してくれていた3台multi読み出しいくつかのデータでcorrelationが見えていそうな気がする(3台で見えるのは初めて)。。何かしらは改善されているようないないような
  -  でもtele2台で回してたらほとんどcorrelation見えず(全部最初は見えているが、だんだん見えなくなる)。やっぱりDAQまだだめっぽい。
 
 
 
 
 MALTA 
 LGAD 
 
-  Data taking w/20um Pixel @110V
 
-  run 283(N)~285(N) : 1000cts/spill くらい 
-  noise : ~1.1mV / over 50mV events ratio : ~0.2% -->DataQuality : OK
 
 
  -  run 286(N)~293(N) : higher beam intensity...2000cts/spillくらい 
-  noise : ~1.2mV / over 50mV events ratio : ~0.2% -->Data Quality :OK
  -  292(N) : 7k due to Controlled Access
 
 
 
 
  -  Data taking w/20um Pixel @115V
 
-  run 294(N)~299(N) : 2000cts/spill くらい 
-  noise : ~1.2mV / over 50mV events ratio : ~0.9%? <--信号大きいのかノイズ大きいのか
 
 
 
 
  -  Data taking w/20um Pixel @120V
 
-  run 300(N) 
-  
  -  Data Quality --> NG :とりあえず1runで辞めました
 
 
 
 
  -  Data taking w/20um Pixel @105V
 
-  run 301(N)~311(N) : 2000cts/spill 
-  noise : ~1.1mV / over 50mV events ratio : ~0.15% --> Data Quality : OK
  -  run 306(N) : manually quitted due to MALTA problem
 
 
 
 
  -  Data taking w/20um Pixel @65V
 
-  checking by selftrigger with osciloscope screen beforehand --> crirtical voltage is 65V
  -  run 312(N) : forgot adding Yoshida(8ch) --> stop and retake
  -  run 313(N)~ : 1500cts/spill 
-  noise : ~1.1mV / over 50mV events ratio : 0% / over 30mV events ratio : ~0.03%