List of tools to analyze the SiW ECAL Beam tests

Indico agendas for Analysis meetings:

Analysis Topics

  • Check pedestals and stability, dependency on rates and < adc >.
  • Put threshold of < adc > to distinguish in-beam and out-of-beam acquisition.
  • Calibration
    • High gain and low gain
    • Linearity between MIP position and , pedestals and
    • Check linearity between in-beam and expected response
  • Anomalous readout: Check error rate for misbehavior.

Arbitrarily selected entries from e-log

Eg. for entry 958: visit

958 - peak at 1350 for parallel beam

933 - S-curves, 49 degrees, for threshold=230, 270, 310, 350

882 - 4 channels of chip 12, dif 1, MIP for threshold = 200 and 230.

832, 786, 113 - reduced occupancy in central chip, triggers leak from BX to BX+1

762, 767 - problem with Zedboard <-> CCC cable

641, 618 - chip 15 reading out problem, solved by switching from 5 Hz to 4 Hz spill rate; from my memory: at 10 Hz half of chips was not read out

382, 447 - switch from 10 msec of spill dead time to 50 msec, 10 msec resulted in data corrupation

181, 392 - violin plot: MIP drops with total chip charge, pedestal is fixed (corresponds to average charge), the effect may be due to pedestal baseline negative shift with the total chip charge. Note, at this moment the effect of trigger shift from BX to BX+1 under load (described in entry 832) was not known.

153 - higher noises in DIF2 -> more "pedestal"-like triggers and retriggers, eg. in run 103

100 - fix threshold at 230

91 - dif0 removed from configuration, dif1,2,3 -> dif0,1,2

33 - dif order

27, 32 - first look at data: MIPs, N triggers in XY, retriggers, pedestal RMS

First (late) meeting

IMG_20151113_180945.jpg IMG_20151113_181035.jpg

Data Access, Run Summary and Configuration

Root framework

Analyze root online

1. What does an event refer to in this case, we see that acqNumber and Event number changes at same time. It is just a just a counter when acqNumber changes ?

This is a bit complicated by the historic labelling:
An «event» is in fact one readout, or an acquisition spill (≠from SPS spills).
If I am no mistaken «event number» refers to the readout «by DIF», where as AcqNumber is a global numbering of readouts allowing to synchronise the differents DIF's (boards).

2. What is bcid ?

This is the Bunch Crossing ID (number). i.e the clock cycle number since the biginng of the spill (readout), modulo 4096 (2^12).
The clock frequency is 2.5MHz (400ns). The counter can cycle if the spill length is longer than 1.6ms.

3. What is SCA or Columns.

Those are the nicknames of the chip's memory. Chip by chip the self-triggered events (≠readout) are stored in the memory with a BCID.
Synchronisation of a board (and between boards) should be done using the BCID, as noise/cosmics/particle can fill some some Columns in a chip and not the next one.

4. We see that size of chipid is 16, so it has information about one layer. Where is information for other layers stored ? Does different files have different layer information ?

Well... the chip has effectively 16 memory cells. But the first one is filled by noise at the chip start (at the beninning of every spill).
So practically it should be 15. Can you e.g. check if the BCID[0] is the noise or a real event. If is is noise it should have a BCID*400ns≤~1ms.
The information for differents layers (boards) is in different files (DIF0,1,2).

R Framework

The online_monitor program is written in R language (please, see For those not familiar with R, it can be used as a GUI tool with a predefined list of distributions and a "Help" page with explanations. For people who know R, it may be used as a working environment to make a full analysis (both online and offline).

The code and installation instructions are available at

If you have any questions, please, do not hesitate to contact Vladik Balagura ( Learning R may be difficult in the beginning, but I am sure that if you know it, you'll love it. To me, in a physics analysis it is more efficient than C++ and even python (that's why I've selected R for online_monitor).

The raw/ subdirectory contains raw*{C,hh} files written in C++ and an executable "raw". They give an example of decoding the raw data into several ASCII formats which are then "pipe'd" to the online_monitor.R code. This is done in the load.raw(file) function, which provides an example of raw data analysis in R.

If you want the simplest R environment without any online_monitor graphics, you may start R and copy-paste the following commands:


pedestal.suppression = 0.05
online.monitor.dir = "type here your directory with fev10_chip_channel_x_y_mapping.txt file and raw/raw executable"

map <- fread(paste0(online.monitor.dir,'/fev10_chip_channel_x_y_mapping.txt')) # data.table with chip:channel <-> X-Y mapping

load.raw <- function(file) {
  ... copy-paste the load.raw() function from online_monitor.R ...

After calling load.raw('some raw file'), you should be able to see


ntuples (data.tables in R terminology) with the data.

Basic information on SKIROC2 & DIF data structure

Original from from Vladik's slides (

  • ILC timing: bunches in 1 msec bunch trains, then 199 msec idle time

  • In prototype, bunch trains are emulated by “spills” (eg. 4-5 Hz), every period is split into data taking (also called spill) and readout (“dead” time). Eg. for ILC scheme: 1 ms + 199 msec. To increase an event rate at SPS we used much higher duty cycles (eg. 50 msec instead of 199 msec). Note: spill signal is inverted: during data taking the spill generator signal = 0 V, “dead” when =4 V.

  • One BX takes 400 nsec (2.5 MHz). BX counter in SKIROC has only 12 bits,after 4096 BX it is recycled to zero. Therefore, only about 1.6 msec can be coded uniquely. Also, the very first BXs are not sensitive. In some runs we were running with such “unique” very short spills.

  • SPS spill signal was not used, so both data in AND out of SPS spills have been always accumulated.

  • Acquisition number = spill number = spill counter. The spill frequency and duration is available in run configuration *.xml files.

  • In SKIROC there are 15 memory slots, called SCA's (or columns), all are used and working well. They are filled in the following order: 1, 2, 3, ... (up to 15). The memories are implemented as capacitors (analog memory). In the previous prototype it was checked, that there is no visible charge dissipation, the response to charge injection is linear with the same linearity slope for all SCAs (including the 1st, which keeps the charge the longest). The only “bad” effect which should always be taken into account: pedestals in different SCA's are different.

Data format

ACQid: number of the spill, increments on start acquisition

CHIPid: number of the chip sending data, increments on transmitON falling edge

nCHIP : total number of chips sending data

SIZE : total number of 16-byte data words

MSB - the most significant word

LSB - the least significant word

section subsection word hex ascii
SPILL header   marker FFFC  
ACQid MSB    
ACQid LSB    
  5053 SP
  4C49 IL
blank space 2020  
N times CHIP header marker FFFD  
FF+CHIPid FF..  
  4843 CH
  5049 IP
blank space 2020  
CHIP trailer marker FFFE
FF CHIPid FF..  
blank space 2020  
blank space 2020  
SPILL trailer   marker FFFF  
ACQid MSB    
ACQid LSB    
00 nCHIP 00..  
blank space 2020  
The SPILL header is written when a fast command startSPILL is received. The SPILL trailer is written when the signal end_readout from ROCs is received by the DIF. The CHIP header and trailer correspond to the falling and rising edges of "transmitON", respectively.

CHIP DATA is specific to SKIROC and is described in the following picture. skiroc_data.png

Note, that, in fact, this is a picture from a SPIROC (not SKIROC) documentation. Both chips have the same data format, except in SKIROC there are 15 SCAs and not 16 as shown in the SPIROC's picture above.

Also note: the Chip ID (8 bits) may be duplicated in the end of the data block (but may be not).

Connection of pixels on FEV10-11

* fev10_chip_channel_x_y_mapping.txt: Table with X-Y chip:channel correspondence. Every chip serves one square, (x0, y0) are the coordinates of its center. (x,y) are the pixel center coordinates. See an example of use in online_monitor.R where this file is converted to the "map" R-table. FEV10_mapping.png

The Team after the first analysis meeting

IMG_20151113_181020 .  

Created by VincentBoudry - 2015-10-27

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng FEV10_mapping.png r1 manage 490.6 K 2015-11-03 - 18:16 VladislavBalagura  
JPEGjpg IMG_20151113_180945.jpg r1 manage 1097.1 K 2015-11-13 - 19:15 VincentBoudry Tableau1
JPEGjpg IMG_20151113_181020.jpg r1 manage 953.9 K 2015-11-13 - 19:15 VincentBoudry  
JPEGjpg IMG_20151113_181022.jpg r1 manage 1072.6 K 2015-11-13 - 19:15 VincentBoudry  
JPEGjpg IMG_20151113_181035.jpg r1 manage 1152.6 K 2015-11-13 - 19:15 VincentBoudry Tableau2
Texttxt fev10_chip_channel_x_y_mapping.txt r1 manage 29.0 K 2015-11-03 - 18:21 VladislavBalagura Table with X-Y <-> chip:channel correspondence
PNGpng skiroc_data.png r1 manage 200.5 K 2015-11-05 - 11:32 VladislavBalagura  
Edit | Attach | Watch | Print version | History: r21 < r20 < r19 < r18 < r17 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r21 - 2017-04-20 - VincentBoudry
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CALICE All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback