各種の情報

以下の情報は XOOPSから取得のこと。

運用室のキングファイル(「ひので運用マニュアル」)に以下のマニュアルが用意されている。
 ○地上局スケジュール担当(GCC)のお仕事マニュアル
 ○各地上局のスカイラインデータ
 ○指令電話情報
 ○SLE GateWay操作マニュアル

===========================================================================

Real Time Tohban マニュアル

<RT Tohbanの作業項目> (2006/10/14)

0:勤務開始時の作業
1:パス運用中の作業
2:パス運用終了後の作業 ... 2006/11/13 
3:運用レポート作成
4:Daily meetingにおける運用報告
 A):管制卓の使い分け
 B):ヘッドセットの使用ルール


===========================================================================

<0:勤務開始時の作業>

[0-1:運用チェックシートの確認]

○Chief Planner(CP)より当日及び翌朝使用する運用チェックシートを受領し、各種確認
 事項(運用内容とコマンドシートの整合性、TLM及びCMDのAOS/LOS時刻等)に誤りがない
 か、Daily event page及びパスリスト(下記url)と比較して確認する。
PASSLIST:http://www.isas.jaxa.jp/home/solar/hinode_op/archives/passlist/passlist_latest.txt
Daily Event Page:http://www.isas.jaxa.jp/home/solar/hinode_op/hinode_daily_events.php


[0-2:運用チェックシートのFAX送信]

○夕可視帯最初のパスのAOS1時間前もしくはJST15:00までに、CPより受領した運用チェック
 シートの内、翌朝までのUSCパス分のみを以下の番号にFAXする。
  ・20/34m 0994-67-3193(すざく運用室内のFAXを使用。短縮1番を押下)


[0-3:運用チェックシートのコピーと提出]

○夕可視帯最初のパスのAOS1時間前もしくはJST15:00までに、パス運用に誰が参加する
 のかを運用チェックシートの運用項目を元に割り出し、人数分の運用チェックシート
 のコピーを用意し、参加者に配布する。また、、原紙をコマンダーに提出する。

[0-4:Battery check]
○日陰期間中のみに実施する。
 JST12:00以降にバッテリ状況の調査を行う。実施内容は「日陰期間Hinode電源系状態監視」
 を参照する。


===========================================================================

<1:パス運用中の作業>

[TLM-AOS10分前]

※新GN局運用室とOKI OIS端末ch.1で、USC34mとOKI OIS端末ch.7で、USC20mとOKI OIS端末
 ch.8で直接上位ビットがインタフェースを実施する。
 ただし、新GN運用時にOIS端末が他衛星運用で使用できない場合、3階運用室内の固定電話を
 用いて対向通信にて運用を実施する。
  ・新GN運用室 050-3362-2787

※TLM-AOS5分前までにOIS端末での呼び掛けを実施しなかった場合、新GN運用室からB2
 運用室に電話連絡が入る取り決めになっているので、時間厳守を徹底すること。

【USC局/新GN局 共通】
○共通QL前に着席し、インカムを通じて準備確認・点呼を実施する。
 - 共通QLの設定はコマンダにより事前準備が完了している。
 - 運用チェックシートを用いて運用要員の点呼を取る。
○コマンダーにパス番号とmain計画番号を問い合わせる。
○運用チェックソート上の運用項目を元にパス概要を説明する。


【USC 34m/20m局】           【新GN局】
※天頂回避のあるパスは、正確な回避 ||○AOS/LOS時間及びキャリアアップ・ダウン
  時刻をANT担当に問い合わせる。    ||  ELを問い合わせ、結果をチェックシートに
                                  ||  記入する。(この値が一番正確)  
------------------------------------------------------------------------------

[TLM-AOS5分前]                      

【USC 34m/20m局】           【新GN局】
●局運用管制から接続を知らせるWSが ||
 鳴る。              ||
------------------------------------------------------------------------------

[TLM-AOS4分前]   
【USC 34m/20m局】           【新GN局】
                  ||○コマンダに対し、TLM/CMDセッションの
                  ||  接続を依頼する。
                                   ||
                      ||●新GN運用室よりセッション接続結果の報
                                   || 告を受ける。(報告が無い場合は新GN運用
                                   || 室に対して確認を行う)
                  ||
                  ||○新GNユーザ端末を立ち上げる。
                                   ||  (立ち上げ方法は端末付属のマニュアル
                  ||  を参考にする)
                  ||
                  ||※セッションの接続が確立出来ないと新GNの
                                   || 運用は実施出来ない
------------------------------------------------------------------------------

[AOS1分前]

【USC局/新GN局 共通】
○TLM-AOS1分前をアナウンスする。
------------------------------------------------------------------------------
[AOS]
【USC 34m/20m局】           【新GN局】
○局管制がAOSと共にAOS時間をアナウ ||●新GN局からTLM-AOSの報告を受ける。
  ンスするので運用チェックシートに ||
 記録する。            ||
                   ||
●局管制からS-DEMOが問題ない旨の報 ||
  告受ける。                 ||

○共通QLにてTLM受信を確認した旨をアナウンスし、モードチェックの実行に移行する。
------------------------------------------------------------------------------
[入感モードチェック]

【USC局/新GN局 共通】
○入感モードチェックは以下の通りに行う。
 1:「テレメトリーが来ましたので、モードチェックを開始してください。」
   (コマンダーがOK/NGをアナウンスするので、異常有り/無しにチェックする※1※2)
 2:「読み上げをお願いします」
   (コマンダがTLM計8項目を読み上げるので、運用チェックシートに記録する)
 3:「サブシステムの確認をします。(以降サブシステム担当に呼び掛ける)」
   (サブシステム担当に確認を行い、運用チェックシートに記録する)

※1 異常が発生した際は、発生した項目をコマンダに読み上げてもらい周知事項であるかを
   確認する。
※2 モードチェックで監視しているTLMが長期的に変更された場合には、担当機器に確認した
   上でモードチェック項目の登録内容を変更する。
     コマンダーにチェック項目の変更を依頼し、結果を印刷する。印刷したシートは
    「ひので運用マニュアル」ファイル内の「モードチェック変更履歴」にファイリング
   する。(変更の要旨を朱書き等で強調すること。)

------------------------------------------------------------------------------
[コマンド運用]

【USC 34m/20m局】           【新GN局】
●局管制よりuplink開始の報告を受け ||●新GNより、キャリアアップ開始の報告を受ける。
  る。                          ||
                                   ||
●COM画面にて SQ_ON/OF ON => OFF  ||
 を確認し、衛星側受信機ロックを   ||
 アナウンスする。                 ||
                  ||
●局管制よりuplink完了及びQPSK完了 ||
 の報告を受ける。               ||
                                   ||
                                   ||●(数十秒後)新GNよりコマンド送信準備完了の
                                   ||  報告を受ける。 

【USC局/新GN局 共通】
○最初に Dummy Command を送信する。正常に送信されなければ第一に地上系の設定ミスを
 疑い、コマンダに設定の確認を依頼する。
  正常に送信されればパス運用手順に進む。

【USC 34m/20m局】           【新GN局】
●                 ||●Dummy Command送信後COM画面にて 
                  ||  SQ_ON/OF ON => OFFを確認する。


○手順書に従いコマンドの実行を指揮する。

○予定されたコマンド送信が完了した時点でコマンド運用終了をアナウンスする。
------------------------------------------------------------------------------
[消感モードチェック]

【USC 34m/20m局】           【新GN局】
●EL<10°をアンテナ担当より報告を受||○CMD-LOS1分前になったら消感モードチェック
 ける。                 || の実施をコマンダに指示する。(実施方法は入
                                   || 感時と同様)
○消感モードチェックの実施をコマン ||
 ダに指示する。(実施方法は入感時と||●CMD-LOS時刻になると新GN運用計画に基づき自動
 同様)                          || 的にキャリアダウンが実行され、その旨新GNより
                  || 報告を受ける。
○消感モードチェック終了後、局管制 ||
  に対しuplink終了を指示する。   ||
------------------------------------------------------------------------------
[LOS]

【USC 34m/20m局】           【新GN局】
○局管制がLOSと共にLOS時間をアナウ ||●新GN局からTLM-LOSの報告を受ける。
  ンスするので運用チェックシートに ||
  記録する。              ||○新GN局にAOS/LOS時刻及びMax Elを確認し、
                  ||  運用チェックシートに記録する。
○アンテナ担当にMax ELを確認し運用 ||
  チェックシートに記録する。       ||
                                   ||
------------------------------------------------------------------------------
[運用終了]

【USC局/新GN局 共通】
○運用終了のアナウンスを宣言し、当該運用局の次パス情報をアナウンスする。
 「以上で「ひので」運用を終了します。次回運用は、UT??時??分、受信局は
  ???です。お疲れ様でした。」

【USC 34m/20m局】
○DRの再生時間を運用チェックシートに記録する。
------------------------------------------------------------------------------
==============================================================================

<2:パス運用終了後の作業> ... 2006.11.13 追記

[MDP Error countの確認]
○MDP error log dumpを実施したパスの後に、error log codeの後解析を実施する。
 実施内容は「運用前のお仕事」を参照する。


==============================================================================

<3:Operation Report作成>

○パス運用終了後の作業を終えたら、以前までのレポートを参考に運用レポートを作成す
 る。以下に運用レポートの記述項目を示す。

[Operation Reportの記述項目]

・レポートID:その当番の担当時間帯の最終日時をUT+レポートのバージョン番号でID化
       する。[YYYYMMDD_hhmmUT_VV]

・ファイル名:HINODE_RTrep[rep_ID].txt
  ※レポートIDと編集最終日時をレポートの最上部に記入する。

・大項目として、《運用実績》・《概要》・《気付き事項》・《引継ぎ事項》・
 《今後の予定》がある。以下に詳細を示す。

 《運用実績》:各パスでのStation、PASS_ID、AOS(UT)、Operationを記入する。

 《概要》:上記の運用実績(一行)では説明しきれない事象について、運用内容を記
            述する。

            DR 再生の PT1, PT2共に完了した場合
            モニタのみのパスにおいて異常が見られなかった場合は
            概要にパスごとの記述はせず、一括して
            「異常なし」のみと記載することとします。

 《気付き事項》:その当番で判明した気付き事項。基本的に次の当番に引継ぎしその後
         フォローすべき項目を記入する。フォーマットを以下に示す。

         [[サブシステム名]]
                   ○気付き事項表題
           (気付き事項発覚パス)
           原因:
           対処:
           現状:

          Closeした項目であれば、気付き事項表題最後に[Close]と
          記入し、つぎのレポートから削除する。
          Closeしなかった場合、原因・対処はコピーせず、参照
          すべきRepIDを記入。
 
 《引継ぎ事項》:気づき事項以外の引継ぎ事項を記述する。

 《今後の予定》:翌朝パスのStation、Pass_ID、AOS(UT)、Operationを記入する。
 
・運用レポートは、solar-b_operep@solar.isas.jaxa.jp に送る。
・現状は、初期フェーズを想定したメンバが含まれている
 (学生は含まれていないので注意)

・メールの件名には operep: を「含めない」こと。

・無用な誤解を招くのを防ぐため、本レポートの再配布は不可とする。

・記載内容に誤りが発見された場合、修正したレポートを配布する。その際、元のタイ
 トルの末尾に - errata をつけ、Re: などを含めないこと。

===========================================================================

<4:Daily meetingにおける運用報告>

○Daily meeting は、朝10:30 JST に 新A棟7会会議室にて実施する。
○運用報告は運用レポートに基づきChief Plannerが行なうが、異常事象
  が発生した場合は会議に可能な限り出席して報告する。出席できない
 場合はあらかじめchief plannerに情報をインプットすること。

===========================================================================

<A):管制卓の使い分け>

SSOC B棟3階の管制室には、コマンド・状態監視の卓が2セットある。
装置に向かって右側の卓には34m局運用管制モニター、左側の卓には20m
局運用管制モニターがあわせて設置されている。

USCで20mアンテナ運用を行なう可視帯(夕可視等)では基本は左側の
卓を使用し、34mアンテナ運用を行なう可視帯の場合は右側の卓を使用して
運用することをベースとする。また、新GNの運用については、新GN
運用と同じ可視帯で行なわれるUSCがどちらのアンテナを使用するかで
使用する卓を選択すれば、「あかり」と使い分けが可能となる。
あかりと運用時間が近い場合は特に注意すること。

===========================================================================

<B):ヘッドセットの使用ルール>

○新GN運用時:OKIのch.1のみを使用。
○34m運用時 :34m対向装置を使用。回線不具合次はOKIのch.7を使用。
○20m運用時 :20m対向装置を使用。回線不具合次はOKIのch.8を使用。

管制室のヘッドセット (20m対向装置)の中に、非常に聞き取りずらいものがある。
根元の2本足の部分で組み合わせを変更した所、感度の向上が確認できた。
( 恐らく刺し直したことが効いたと思われる。)
===========================================================================

異常時の対処について (2006.11.27新規)

 「緊急連絡先」情報はひので運用マニュアルのファイル内にある。

1. 重大異常の対処

 入感/消感モードチェックにおいて下記TLM項目(モードチェックファイルの上から
 3項目)がエラーの場合は、緊急連絡先にもとづき、プロジェクト運用全般担当、
 AOCS担当者、MELCOシステムへ至急電話して、関係者を招集・指示を仰ぐこと。

  ・HK2_CNT_MODE
  ・HK2_RQOG_CODE
  ・HK2_RQOG_STS

2. AOCS関連エラーの対処

 重大異常ケース以外のAOCS関連エラーが検出された場合は、エラー箇所のテレメ
 トリ名称とステータスをAOCS担当者へ電子メールにて知らせること。

  電子メール送付先:solar-b_aocs@solar.isas.jaxa.jp 
               (Subjectにaocs:を含めること)
                     sb-aocs@nas.jp.nec.com

3. MDPエラーの対処

 「MDP既知のエラー」(上位ビットマニュアルに綴じられている)に従って処置をす
 ること。

4. 観測機器関連エラーの対処

 観測機器関連のエラーが発見された場合は、エラーの内容に応じてSOT, XRT, EIS
 に連絡して指示を仰ぐこと。

5. 20m運用時のX-bandアンテナ切替えについて

 20m局運用管制では、X-bandのAGCの現在レベルは分かるが、プロットが出せないので
 AGCレベルをモニタしながらAB切替のタイミングを計ることはできない。20m運用では
 プロジェクト側から切替タイミング予報値を出し、それに基づいて切替えている。

6. 34m運用時のアザーアンテナによるUplink時刻の短縮について

 34mアンテナ運用で、特定のAZをLOS時に通過するパスにおいて、Uplink時刻の短縮が
 発生する。LOS時の方向に20mアンテナがあり、計画より約2分程早くUplinkを終了する
 必要がある。
 本件に関する事前情報は、運用10分前にコマンダーよりなされる。

7. 新GN の AOS/LOS(2006/10/13 清水追記)

 新GN局のAOS/LOS時刻およびU/L・D/L時刻について以下に示す。

 (※passlistへは新GN運用計画ファイルから本情報が取り込まれており、また
   運用チェックシートの時刻もこの情報が記載されている)

 1、AOS/LOS時刻 : skylineは考慮されておらず、El=0°の時刻である。従って
          skylineがある場合は時刻がずれる可能性がある。

          ※passlistにAOS/LOS時のAZ情報があります(右端)ので、
           「ひので当番マニュアル」にあるスカイライン図と比較すれば、
           事前に感触を掴む事は可能。

 2、U/L、D/L時刻: trip zoneを考慮したキャリアアップ/ダウン可能時間帯の
          始めと終わりの時刻である。(passlistではEl>5に記載された時刻)

            ※PRT夕可視ではEL20°の鉄塔方向を通過することがあるのでU/L開始
           までに非常に時間を要す。
          ※U/L可能時間帯をtrip zone考慮で決めているのでほぼ予定時刻で運用
           が可能。ただし、U/L時はRNG設定等で経験的に60-90sec程度は遅れて、
           コマンド送信可能状態とる。
          ※新GNは自動制御なので、trip zoeに一時的に入る事があり、その場合
           はU/Lの複数回実施が発生する。

8. レンジング

 Max.El>75°のパスではレンジングを行わない。

 打上げ直後は可能な限りRNGを実施する意図から、毎USCパスでRNGを実施しており、
 Rev.187/USCのパスもRNGを行なったが、当該パスのELが高かった(81°天頂通過)
 為、途中でRNGが外れる事象が発生した。
 「すざく」・「あかり」ではMax.EL > 75°のパスではRNGを実施しない方針なので、
 今後は「ひので」もこれに倣い同じ基準を採用する。

9. Java QL のマニュアル

 Health Check Reformatter の /home/com/doc/ の下。

10. 周知事項

NSAS制御使用時の姿勢の一時的な変動(X軸周り、Y軸周り)

 Rev.114/SNT1可視中に、姿勢決定値(ATT値)がX軸まわり方向に-6度ほど
 ゆれ、NSAS/UFSSセンサ出力がプラス方向に振幅する現象が見られた。
 何らかのノイズが入り姿勢決定値をずらしたように見られる。[一旦close]
   サンチャゴ付近で発生しているので、SAAによりNSASにノイズが入ったと
 思われる。NSASとしてはすざくNSASで発生した事象と同様なことが起きて
 いると思われる。ひのでの場合、初期運用でNSASのみ使用の場合このよ
 に姿勢変動と現れるが、通常運用となるとUFSS使用となるのでこのよう
 は変動は発生しない。今後もモニターする。

FPP QL の黄色 (OP ヒータ使用前)

 PIがモニターしているFPP QL画面で、FPP_CT_CCD_TEMPが赤字になることがあるが、
 これは現状、例外扱いとして、問題発生のアクションをとる必要はない。
 (LMからの確認文書の到着を待って処置する。)

MDP bit エラーの対処 (2006.11.13 改定)

以下の項目がモードチェックに組み込まれてる。

MDP_FPP_ST_ECC2_CNT = 0
MDP_CTM_ST_ECC2_CNT = 0
MDP_XRD_ST_ECC2_CNT = 0
MDP_XRE_ST_ECC2_CNT = 0
MDP_EIS_ST_ECC2_CNT = 0
MDP_TLM_ECC2_CNT = 0
MDP_PST_ECC2_CNT = 0
MDP_CPU_BF_ECC2_CNT = 0

MDP_FPP_ST_ECC_CNT = 0
MDP_CTM_ST_ECC_CNT = 0
MDP_XRD_ST_ECC_CNT = 0
MDP_XRE_ST_ECC_CNT = 0
MDP_EIS_ST_ECC_CNT = 0
MDP_TLM_ECC_CNT = 0
MDP_PST_ECC_CNT = 0
MDP_CPU_BF_ECC1_CNT = 0
MDP_CPU_WK_ECC_CNT = 0

これらの値が変化した場合は、MDP 担当の松崎・小山両名にメール連絡を入れ
るとともに、モードチェックの設定値を更新する。

# リアルタイム当番 => MDP
  メール先: solar-b_mdp@solar.isas.jaxa.jp
                 (Subjectにmdp:を含めること)

これらの値はカウントアップしてもMDPの動作に問題はないが、発生頻度が高く
なるようであれば、対応の見直しを行う。

AOCSメモリ運用直後のHK2_BFM_SUMエラー点灯

  AOCSメモリ運用(ロード、ダンプ)実施直後(およそ30秒)に消感時モード
 チェックを実施した場合、HK2_BFM_SUM = 0という赤字エラーが発生する。
  (2006/11/23 Pass2発生)
  AOCS搭載S/Wは、メモリロード・ダンプ実施中を除いて、搭載S/W格納メモリ
 エリアに対してサムチェックを定期的に実施している。チェックサム結果
 (HK2_BFM_SUM)は現在の搭載S/Wでは13である。メモリロード・ダンプ実施中
 は格納メモリエリアに対して書き換え等操作を行なっている場合がありうる
 ので、サムチェック計算処理を一時停止させるようになっている。メモリロー
 ド・ダンプ完了後、サムチェック計算処理が再起動開始され、1回目のサム
 チェックが完了するのにおよそ30秒ほど要する。この間はチェックサム結果が
 0と示される。

AOCS Upload Pointing Tableの差分バイト数 (2006.11.18追記)

 Pointingのtracking curveを変更しなかった場合、Upload pointing tableの差分
 は0となる。この場合、ram-150展開からDHU_MODE_CHNGまでをキャンセルする。

OP/OGメモリダンプ時の注意事項 (2006.12.6追記)

 DHUのメモリダンプを行う場合には、
   1) DHU_DMA_DMP_PRM_SETでダンプアドレスをセット
   2) DHU_MODE_CHNGでダンプスタート、
 と必ず2コマンドセットで実行すること。

  ダンプアドレスのセットコマンドの実行をせずに、ダンプフォーマットへ
 モードチェンジコマンドを送出した場合、繰り返し数の設定(HK1_DMP_REPEAT_NUM)
 が"7"(=8回)の状態になっており、(ダウンカウンタで"0"→"7"のときのキャリーア
 ウト信号で停止する仕様)このため、8回分ダンプを実行してしまう。

  ダンプを中止し別のフォーマットに移行する場合には、DHU_BUS_ACC_DISコマ
 ンド(DHU-PIM DMAを無効化)を実行する。そして、DHU_MODE_CHNGコマンドで
 移行すること。

 ダンプ中にダンプアドレスを設定しても、設定されずに保留される。

(2006.11.23のメモリダンプにおいて事象発生)

OP/OGメモリダンプ時にフレーム抜けが発生した場合の照合動作と対応 (2006.12.6追記)

 衛星管制装置のDHU(DMA)経由のメモリダンプの場合は、メモリダンプデータ
 収集中に、収集エラー(メモリダンプアドレス不連続をメッセージ表示)
 が発生すると、照合処理は実施しない。

 そのため、照合確認を行なうために、
   1) DHU_DMA_DMP_PRM_SETでダンプアドレスをセット、
   2) DHU_MODE_CHNGでダンプスタート、
 と必ず2コマンドセットで再実行する必要がある。

UFSS/NASA性能維持温度の上限 (2006.12.25追記)

  打上直後から、IRUタワー上部の温度がシステム熱設計予想に比べ温度が10度
 以上高いことが判明している。センサ周辺部の熱計装のPEIのαの見積の不確か
 さ及び一部ネジ類の宇宙への露出によって、大きく高温側にずれたと推定してい
 る(大西先生)。

  太陽光強度がMaxとなる1月初旬まで温度上昇を続け、その後温度が下降傾向に
 なると推定(期待)している。2006/12までは凡そ1.7℃/月の割合で上昇して
 きている。IRUタワー上部に置かれたNSAS, UFSS-Sとも温度に関する上限温度
 の仕様は下記になっていまる。

  性能維持温度: 50℃
    機能維持温度: 60℃
  ターンオン温度: 60℃

  従って、さしあたりは問題ないと思われるが、定常的な温度監視が必要である。

 ※モードチェックは5℃マージンを設定して45℃でトリガーをかけるようにしてある。
  (2006.12.25現在)

 上記事情ゆえに、しばらく夕方のリアルタイム当番は下記の温度ステータス(1パス目
 の温度)を記録し、日報に報告として記載すること。

  HK1_NSAS_TEMP
  HK2_UFSS-SA_TEMP
  HK2_UFSS-SB_TEMP
 (共に共通QLのHKU1画面左下付近にあります)

 ※運用室北東におかれ試験運用中のISACS-DOC端末でも、45度を超えると注意警告メッセ
  ージが表示されることになっている。また姿勢制御系を選択すると温度グラフも見れる。

DR再生自動終了時VC4 ON/OFFステータスONのまま、及びHK1_REPSEGERR_CNTのアップ (2007.6.30清水追記)

 1)DRのPT1再生において、読み出しポインタが書き込みポインタに追いついた場合に再生が
   自動停止される(というモードで運用している)。
   通常再生が自動停止した場合は、VC4 ON/OFFステータスはOFFに切り替わるが、希にONのまま
   となる場合がある。(2006.12.28発生)
  
 2)また、その後にPT2の再生を開始した際には、HK1_REPSEGERR_CNTがカウントアップする。
    (2007.02.24発生)(※再生開始時外のカウントアップは本件と異なり調査が必要)

 共に動作上問題はない。発見時の処置としては、1)についてはOPから発行されるDR再生停止OG
 (LOS前やアンテナ切替前)にVC4 OFFがダメ押し用としてコマンド実行されているので、特に処置は必要ない。
 2)については、モードチェック数値を更新すると共に、日報に記載すること(清水がNEC担当には発生を
 インプットしています)。

 ※本現象の発生は、DRからREP END信号が出力されず、DHUの再生ON/OFFがOFFにならないためで、ASTRO-F地上
  試験で発見され水平展開されたFPGAロジック誤りによる不具合で、運用対処で処置することとなった項目。

 ※PT1⇒PT2の再生では、DHUは再生ON/OFFステータスがOFFとなることで、PT1とPT2の区切りを知ることになります。
  しかし、DHUの再生ON/OFFステータスがONのままだと、DHUではPT1とPT2を連続したデータとして扱うこととなり、
  セグメントヘッダの不整合があると、HK1_REPSEGERR_CNTをカウントアップすることとになります。
  尚、再生開始時はDRにて、8セグメント分バックして再生を行いますので、再生開始時のセグメントエラーについては
  前回の再生時に取得済みのデータですので、データの欠損には至らない。(パケット最大長2044バイトで4セグメント)

HK1_CM_1BERR_CNTの発生 (2007.6.30清水追記)

 DHU共通メモリ領域の1ビットエラー訂正の発生。1ビットエラーの発生で訂正動作が実施されたことを示すカウンタで問題
 ない。モードチェックの数値を改訂し、日報に記載すること(清水がNEC担当には発生をインプットしています)。

 発生例は2007.4.6や2007.6.23。