RDF
RDFのフォーマットについての説明は https://ribf.riken.jp/~baba/acquisition/system/dataformat.html に記載されていることになっているが, ここに書かれていないことも多い... (RDF Decoderを作るときに困った)
NBBQが吐き出したRDFを見てWebページに書かれていなかった部分を補足しているので, RDFのルールというよりNBBQのルールかも.
構造
RDFは16kB = 16384byteのBlockというかたまりで構成されており, Blockには次の3種類がある.
- Header Block : Run Number, Runのスタート時刻, Headerなどの情報が書き込まれている.
- Ender Block : Run Number, Runのスタート時刻, ストップ時刻, Enderなどの情報が書き込まれている.
- Event Block : Event Data.
Blockの最初の1wordがBlockの種類の識別子となている. なお1word = 2bytes である.
- Flag of Header :
0001
- Flag of Ender :
ffff
- Flag of Event :
0000
Header Block
word | |
---|---|
0 | 0001 Flag of Header Block |
1-9 | nul 0000 |
10-13 | Run Number (ASCII 8char) RUN-0000 |
14 | space x2 (ASCII 2char) 2020 = sp sp |
15-23 | Start Time (ASCII 18char) START => 12:58:56 |
24-32 | Stop Time (ASCII 18char) STOP => XX:XX:XX |
33 | space x2 (ASCII 2char) 2020 = sp sp |
34-42 | Print Time (ASCII 18char) Print -> XX:XX:XX |
43-47 | Print Date (ASCII 10char) 22-Mar-23 |
48-49 | nul 0000 |
50-89 | Header (ASCII 80char) |
90-129 | Ender (ASCII 80char) nul 0000 |
130-16383 | nul 0000 |
Header Block と Ender Block は同じ構造のため, Stop Time, Enderなどがあるが, 意味のない値が詰まっている.
- Stop Time は
STOP => XX:XX:XX
- Print Time は
Print -> XX:XX:XX
- Enderは nul
Ender Block
word | |
---|---|
0 | ffff Flag of Ender Block |
1-9 | nul 0000 |
10-13 | Run Number (ASCII 8char) RUN-0000 |
14 | space x2 (ASCII 2char) 2020 = sp sp |
15-23 | Start Time (ASCII 18char) START => 12:58:56 |
24-32 | Stop Time (ASCII 18char) STOP => 09:00:00 |
33 | space x2 (ASCII 2char) 2020 = sp sp |
34-42 | Print Time (ASCII 18char) Print -> XX:XX:XX |
43-47 | Print Date (ASCII 10char) 01-Jan-70 |
48-49 | nul 0000 |
50-89 | Header (ASCII 80char) |
90-129 | Ender (ASCII 80char) |
130-16383 | nul 0000 |
Stop Time, Print Time, Print Dateが書き込まれるはずだが, NBBQでデータを取ると, おかしな値が詰められる. 32bit OSのせい?
- Stop Time は
STOP => 09:00:00
- Print Time は
Print -> XX:XX:XX
- Print Date は
01-Jan-70
Event Block
Event Dataが詰められているBlock.
さらにEvent DataにはSegment Dataが詰められており, 次のような入れ子構造になっている.
Event Block
├── Event Data 1
│ ├── Segment Data 1
│ ├── Segment Data 2
│ : :
│ └── Segment Data M
├── Event Data 2
│ ├── Segment Data 1
│ ├── Segment Data 2
│ : :
│ └── Segment Data M
: :
└── Event Data N
├── Segment Data 1
├── Segment Data 2
: :
└── Segment Data M
Block Header
Event Blockの最初の4WordはEvent Blockであることを示すFlag.
word | |
---|---|
0-3 | 0000 Flag of Event Block |
4- | Event Data |
Event Data
4 word以降はEvent Dataが詰められている. Event DataはいくつかのSegment Dataから成り, Event Dataの構造は次のようになっている.
word | |
---|---|
0 | Event size. word単位. このwordを含む. 下位12bit がEvent size, 上位4bitは 1000 で固定. |
1 | Fragment ID. 0001 で固定 |
2 | Event ID. Block内で何番目のEventか |
3- | Segment Data |
Segment Data
word | |
---|---|
0 | Segment size. word単位. このwordを含む. |
1 | Segment ID |
2- | Segment Data |
https://ribf.riken.jp/~baba/acquisition/system/dataformat.html では, 3word以降がDataとなっているが, 多分間違い.
EOB
Event BlockのどこまでEvent Dataが詰まっているか, End Of Block(EOB)はどうやって知るのか? どこにも書かれていないが, NBBQが吐き出したRDFを読み解くと, Event Blockの最後のEvent Dataの直後に
ffff ffff
というwordがあり, これはルールに則ると Segment size = ffff
, Segment ID = ffff
を意味している.
つまり, Event IDが ffff
であり得ないほど大きいサイズ( = ffff
)のEvent DataをEOBの合図としているらしい.
どこにも書いてない...
Scaler
ScalerをBlock毎に読み出している場合, Blockの末尾にScalerの情報が書き込まれている. この情報は Event Dataのようなフォーマットはなくベタ書きされており, raw dataが唐突に始まる.
V560を使っている場合, Scalerのチャネル数 x 2word(=32bit. Scaler のデータサイズ) の分, 末尾から引いたところからデータが書き込まれている. つまり, Scalerのデータの末尾 = Event Blockの末尾.
これもどこにも書いてない.