SELF_NOISESCAN下の方に筋状にノイズがひろがる

→以前から見られている問題を再現した。

原因はなんだろう。

１、レギュレータ

２、エンコーディングが悪さをしてたり・・？　　→　今日調べてみる

３、フレックス固有の問題？　→　正月明けにフレックス以外のモジュールでレギュレータを使ってみたりいろいろ。

マンチェスターエンコーディングの部分をコメントアウトして再度コンパイルしてみる。→まったく関係なし（コードは戻した）

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のままになっていた（正１２４３）Digital Analog ...ok key=26,27

tuning ...ok th key 47

fnalのconfig fileを調査KEK115 RJ4のGAが６になっていた。

• SVX
  ・冷却器以外全部。
  参照：持ち物リスト　 https://docs.google.com/spreadsheets/d/16LxTLwdshbWzZ36rONitM8Lx8_qjKItqFMtqScNHAyc/edit#gid=0
  理由：
  ①壊れた？SVXの検証のため必要
  ②SEABAS2を、EEPROMに保存されているIPアドレスで通信できるようにさせる

• 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に戻ってください。

TLU Ev_Num =

Run_number = 000023 / 11時頃 21/12/2016

TLU Ev_Num =

TLU

HSIO

SVX

• タイミングスキャン無しではやはりβのヒットは見えなかった。当然と言えば当然。

片付け

各グループ持って帰るものリスト

• a
• b
• c
• SVX
  ・冷却器以外全部。
  参照：持ち物リスト　 https://docs.google.com/spreadsheets/d/16LxTLwdshbWzZ36rONitM8Lx8_qjKItqFMtqScNHAyc/edit#gid=0

17:35 TLU run_number = 000008

17:45 Run_number = 000009

17:50 Run_number = 000010

17:54 Run_number = 000011

18:06 Run_number = 000012

18:22 Run_number = 000013

18:40 Run_number = 000014

ゴミ。

18:44 Run_number = 000015

18:56 Run_number = 000016

19:06 Run_number = 000017, TLU Ev_Num=103278

とりあえず動くDAQはできた。とりあえず。

MPPC

一番下流側は死んでいた。3枚線源を当てて生存確認。

TLU

HSIO

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引数：出力関係
  
  間違ったアドレス空間を読んでいたので、後日やり直しする。
  そもそもなんで記録されていないんだろう。
  
  

• UDP通信でEEPROMにアクセスできるので、書き込まれている値を見に行く事ができる。
  →Software側、SVXTools/tele_soft/src/util.cppに以下のように追加して確かめる。
  

  MAC ADDRESS: ff:ff:ff:ff:ff:ff
  IP ADDRESS: 192.168.10.111
  
  MACアドレスはおかしい。IP ADDRESSの値はそれっぽいが、実は昨日SiTCP utilityで書き換えした値で、元々は255.255.255.255だったもの。
  
  

• J7ジャンパーピンを抜くことで、Default Mode(MACアドレス:02:00:C0:A8:00:10、IPアドレス:192.168.10.16)からEEPROMに書き込まれている情報を使うモードを切り替えられる機能がある。

• EEPROMの中身が壊れている可能性。
  →解決策としては、EEPROMを書き直す。
  　SiTCP utilityでIP address、TCP Port、UDP Portは書き換えられる。
  　MACアドレスは簡単には書き換えられない。ただ、書き換えられる方法はある。
  　購入したMACアドレスが保存されたbinaryファイルとBeeBeansがCDで配布しているソフトウェアを使えば書き換えられる。j-tagじゃなくてEthernetで。
• 20日朝からMACアドレスを書き込むテストを行ってみる。

• [Remain Task]

  • SVXconverter.hhにsvxの情報のみを持ったクラスを付け加える。
  • 死んだNo.2 SVX Telescopeの原因調査→阪大で
  • 解析プログラムTestBeamAnaの改良→阪大で

13:00〜14:00 FNAL打ち合わせ

15:00〜17:30 g-2、D0の測定器見学

SVX

• SVX4に使っているSEABAS2の固有MACアドレスとIPアドレスは何だろう問題
  (発端は、TLUのSEABAS2とIPアドレスが被っている事による。KEKのSEABAS2はデフォルト)
• まず、J7ジャンパーピンを抜くことで、Default Mode(MACアドレス:02:00:C0:A8:00:10、IPアドレス:192.168.10.16)からEEPROMに書き込まれている情報を使うモードを切り替えられる機能がある。
• 以下、SEABAS2とPCはダイレクトで接続されている状態での話です。
• SEABAS2のJ7ジャンパーピンを抜くと、PCとSEABAS2との間のコネクションが取れなくなる。Linuxから見えない。Ethernetに何も挿さっていないように見える。
  ・PC側のネットワーク設定が間違っているから見えないということが原因では無い。
  ・SEABAS2の赤色LED(通常TCP通信ができていると早く点滅(0.5Hzくらい？))が遅い周期(1Hzくらい)で点滅。
  　SEABAS2がそもそもEthernet通信をしようとしていないとの小野さんの見解。
  ・ジャンパーピンを抜いた状態では、LVカレントが1.819A〜1.751Aの間を1Hzくらいで振動している(@LV=3.3V)
  　ジャンパーピンを挿した状態では、2.37A程度で安定している。
  　この時、DaughterBoardのLVカレントは3.45Aでジャンパーピン挿していない状態と同じ値で安定(@LV=3.3V)
• ジャンパーピンを挿した状態に戻す(DefaultMode)と、通常通りコネクションが取れてDAQも走る。
• SOIグループのSEABAS2を使用してSiTCP utilityで正しい情報が読めるかのテスト(12/17でSiTCP utilityの返す値が正しいかの確認)
  設定したIPアドレス、MACアドレスにアクセスできるので、ソフトウェアは正しい。EEPROMの中身もきちんと見られる。
• SEABAS2のEEPROMの中身が何も書き換わっていない疑い、あるいは誰かが何か設定してしまった可能性？
• EEPROMの中身が壊れている可能性。
  →解決策としては、EEPROMを書き直す。
  　SiTCP utilityでIP address、TCP Port、UDP Portは書き換えられる。
  　MACアドレスは簡単には書き換えられない。ただ、書き換えられる方法はある。
  　購入したMACアドレスが保存されたbinaryファイルとBeeBeansがCDで配布しているソフトウェアを使えば書き換えられる。j-tagじゃなくてEthernetで。
  　方法はSiTCPを知っている人に聞けば良い。

• 実働時間2時間ほど

SVX

• SVXconverter.hhの整備をした。

• 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引数：?
  
  間違ったアドレス空間を読んでいたので、後日やり直しする。
  そもそもなんで記録されていないんだろう。
  
  

午後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を直接つなぐ構成はやはりやめたほうがよさそう。

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を表示できるようにした。
  
  
• ネットワーク接続問題は何もできていない。

Gas flow

流量とタンク残圧に関するまとめ。更新しました。

gas_tank_summary

Cooling box 環境

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

cooling_enviroment

• 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の改良。

• 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の不具合。他のDAQによる通信が同じSw-Hubを経由して行われていることも考えられるか。
  また、SOIグループではSEABAS2をSw-Hub経由でDAQ PCと通信しているが、このような通信の不安定性は見られないという。
  ファームウェアの問題かもしれないが、これは調査に知識と時間がかかる。
  何が問題かはもう一度阪大で精査する必要がある。
• [回避策]
  SEABAS2とSCTJDAQ PCは直接イーサネットケーブルで接続するようにする。

FE65

Gas flow

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

gas_tank_summary

Cooling box 環境

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

cooling_enviroment

SVX

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

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

beam status

TLU

HSIO

FE64

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できるようなメソッドを実装する。これが結構難しいというか面倒な部分。

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

beam status

TLU

SVX

SVX

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

FE65

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

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

500eでtuning成功

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

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タンクの残量が変わっていないことが疑問である。

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

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

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

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

• (17:30)ビームラインへ伸びていたNo.2 TelescopeへのHVケーブルの先は養生テープで覆って使用不可能にした。もうHVをかけて使わないので。
  * 残り3枚のTelescopeのHV Currentをチェック。HVケーブルには保護抵抗が入っている。
  Current Limitは10μAに設定。

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をかけるようにした。

• (17:30)ビームラインへ伸びていたNo.2 TelescopeへのHVケーブルの先は養生テープで覆って使用不可能にした。もうHVをかけて使わないので。

• (17:30)ビームラインへ伸びていたNo.2 TelescopeへのHVケーブルの先は養生テープで覆って使用不可能にした。もうHVをかけて使わないので。

• (17:30)ビームラインへ伸びていたNo.2 TelescopeへのHVケーブルの先は養生テープで覆って使用不可能にした。もうHVをかけて使わないので。

山元より

Cooling BoxとSVXのGas flowについて

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

• (17:30)ビームラインへ伸びていたNo.2 TelescopeへのHVケーブルの先は養生テープで覆って使用不可能にした。もうHVをかけて使わないので。

• テレスコープ3枚でDAQを走らせることが可能に。死んだと思われるNo.2 Telescopeは調査できるようになった。
  解決はsctjdaq/inc/

• 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

• 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のフラットケーブルの位置を変えても同じ。

TLU

HSIO2

SVX

TLU

HSIO

SVX

セットアップ

• ネットワーク環境
  ビームラインの隣にSw-Hubを設置し、各FPGAを接続。イーサネットケーブルはビームラインの隣の壁面状のPatch Panelに接続(P1Q1)
  Control Roomへ繋がっており、室内のPatch PanelからSw-Hubへ接続。このSw-Hubから各DAQ PCへと繋がっている。
  IP Adress

HSIO

SVX

Summary

HV settings

LV settings

TLU Trigger Logic

Signal	Connector <-- -->	comment
LVCMOSout1	LVCMOSout1
LVCMOSout2	LVCMOSout2	picoscope A
LVCMOSout3	LVCMOSout3	picpscope B
LVCMOSout4	LVCMOSout4	picoscope C
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

HSIO

SVX

TLU

HSIO2

SVX

TLU

HSIO

SVX

セットアップ

• ネットワーク環境
  ビームラインの隣にSw-Hubを設置し、各FPGAを接続。イーサネットケーブルはビームラインの隣の壁面状のPatch Panelに接続(P1Q1)
  Control Roomへ繋がっており、室内のPatch PanelからSw-Hubへ接続。このSw-Hubから各DAQ PCへと繋がっている。
  IP Adress
  Main Desktop PC : 192.168.7.15
  SVX PC : 192.168.7.22
  Raspberry Pi : 192.168.7.35
  KEK-Silicon3 : 192.168.7.43

HSIO

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

TLU

HSIO

SVX

• HDDの容量が残り少ないので,外付けHDDに一部データのバックアップを実行。

12/9

12/10

12/11

12/12

12/13

12/14

12/15

12/16

12/17

12/18

12/19

12/20

12/21

12/22

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

12/7

セットアップ

• ビームテストに必要なものをビームラインへ移し、組み立てた
• inspectionが行われ、受理された

HSIO

• HSIOの番号の対応

• 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

• リモートコントロール環境が整った

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

• SEABAS2に入れる、TLUからのタイムスタンプ用のクロックはNIMの100kHzクロックにする。
  この際ズレることは考えられてはいない。

• SVXへNIMレベルの疑似Triggerを1Hzで配り、イベント収集に取りこぼしがないか確認。→7分の1位lossしている。
  矢島さんに相談。
  結局、Triggerのレートを上げることでこの問題は解消した。

• 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矢島さん)

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

TLU

HSIO

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

SVX

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

12/6

-- Atlasj Silicon - 2016-12-06

Comments

<--/commentPlugin-->