DAQ setup

Generic setup:


Computer and network setup

Beamtest networking

The minimum software needed to take data is:

  • Labview - needs a windows PC
  • Eudaq - windows build is unstable, use Linux (can be in virtual machine)

Additional PCs:

  • DQM4HEP comptuer
  • Quasi-online monitoring
  • Copy-to-dcache
  • Remote desktop PC

The data locations are usually mounted via sshfs (search in the bash history or elog). SSH server is running on all machines, including the labview PC.

DIF Firmware

The DIF blinks out the firmware code. The number corresponds to the consecutive number of short blinks. Zero is represented as loong pulse. Recent firmware code is 20180511

If unsure of the firmware, xilinx SDK version 2015.4 is needed (works both in windows and Linux). Any Zynq project needs to be loaded (few are here http://www.desy.de/~kvas/DIF2/). Before the programming is executed, bitstream file can be put in manually.

DIF needs to be powered during programming, but doesn't have to be connected to the LDA. DIF needs a power cycle after reprogramming of the flash.

Functional test

The purpose is to check, that the ASIC gets programmed correctly and is responding with data.

If something is not working, the usual troublemakers are:

  • flexlead, 
  • power cable 
  • hdmi cable
  • ASIC soldering
  • DIF board
  • wrong LDA port being used

  1. Make sure, that CCC and LDA are switched on in following sequence: 1) CCC, 2) LDA
  2. Make sure, there is a HDMI cable between CCC and LDA
  3. Make sure, that both CCC and LDA are connected to the ethernet
  4. try to ping them: ping (ccc), (mini-lda), (wing-LDA) (second wing-LDA).
  5. Labview: fill the IP address in the LDA configuration
  6. Enable desired port on the LDA. Don't forget to hit "Configure x-LDAs". mini-LDA >A< Config light should go green
  1. Make sure, that LDA and CCC are running correctly.
  2. Enable desired port on the LDA. Don't forget to hit "Configure x-LDAs", mini-LDA >A< Config light should go green
  3. The DIF should answer to the commands. Simplest test is to turn "A) VDAC Power" on. If Ack goes green, communication is working
  4. If Ack doesn't go green, try once again
  5. If Ack still doesn go green, continue with power=on sequence A), B), C) and D)
  6. Check if the red LED on calib board is blinking. If yes, there is a problem with data line (DIF → LDA), but (LDA → DIF) direction is working.

Communication test can be done with many layers at once. The green Ack light is an AND of all modules. If there is an error, one can go through the Ack array to see, which layer is missing. The array index translate to the index of enabled layer, sorted by the port number.

Even without flexleads, the HBU will not report any error until acquisition and readout is started
  1. CCC mode has to be in "Standalone, no spill" mode (or "HGCAL independent" for CMS-HGCAL CCC firmware)
  2. power on (AHCAL swiching on/off), load slowcontrols (no matter whether AT or ET) and do the calibration settings. No special calibration setting is needed. It will be overwritten by next step.
  3. set the mode to TESTBEAM mode with 16 dummy triggers:
  4. switch OFF temperature compensation (the configuration is not yet probably done, or is wrong)
  5. start the run
  6. switch to the expert tab and switch on the Occupancy map:
  7. Check, that all ASICs are represented by a red square: X is the module number (given in the configuration tab). The Y is the chipid from the slowcontrol (range 0-15): (CHIPID-1)%16
  8. If whole slab is missing, check flexleads.
  9. Current on the power supply can help identify possible problem (jumped power flexleads)
  10. If only 1 or few asics are missing, try to reload the slowcontrol in the expert tab

Trigger setup

With older spiroc2b HBUs we used the trigger to promptly validate the event in the SPIROC via a dedicated "trigger" line in the HDMI (CCC->LDA->DIF->ASIC). This scheme is called "validation". With SPIROC2E, the noise is not a big concern, therefore we don't use trigger to validate the event in the ASIC (The DIFs are configured to not pass this signal: this is done in the labview configuration by the "Validation" button). However, the trigger is still needed to go the LDA to get an absolute timestamp information. Later in the EUDAQ, the events are built according to this trigger information.

Trigger setup from out own scintillators:

Nim trigger setup

We usually setup the trigger via a

  • Two trigger scintillators ("finger scintillator in a cross configuration)
  • NIM crate (Check, that the power supply supplies correctly all voltages!)
    • HV power supply (either AHCAL CAEN rack power supply, or the onve provided by the TB)
    • amplifiers (usually not needed, unless discriminators have problems)
    • discriminators (check the threshold level by a multimeter)
    • coincidence (check the pulse lengths)
    • gate generator(pulse generator to generate ~200 ns pulse (to suppress after-pulses from PMT)
      • ttl output goes to CCC
      • NIM output goes to the BIF

It is very useful to use an oscilloscope and check, that the signal is as expected at each point (starting from the PMT direct signal!)

Trigger setup from external source (TLU,Sync board)

The trigger signal comes from the hdmi port from external device. In this case, make sure, that the trigger is configured correctly in the ccc (passed all the time). The lemo trigger input of the CCC is then not used, but it is a good idea to disconnect the trigger


Before the testbeam

  • Are the computers connected to internet reasonably updated? It is a good idea, that all software still works after an update. The functionality is  a known problem, that can require few weeks of time to solve
  • Is there enough hard drive space?
  • Are the data directories free from data from previous testbeams?
  • Labview: create a new directory with a copy of the labview project, slowcontrol folders, temperature compensation folder and data folder. Is the labview AHCAL program the latest?
    • prepare the temperature compensation values
  • EUDAQ:
    • Is the event building scheme decided? Are the startup scripts and configuration files relevant, or new have to be written?
    • EUDAQ Online monitoring needs a new mapping every testbeam (it is in the converter to stdplanes)
  • Slowcontrol settings for asics and module numbering should be decided and fixed

Testbeam setup and running

  • Each time a trigger path is changed, LDA and BIF offsets have to be calculated and configuration files updated.
  • Data should be copied to grid on the flyt, because the speed is usually very slow (1~8 MB) and last day is usually not sufficient to copy everything
  • Documentation:
    • the setup (at least elog, confluence)
    • which version of labview, eudaq, dif firmware is used
    • which layer is connected to which LDA port of which LDA and which power supply channel;
  • measure the distances in the beam area (even upstream) - important for later simulation
  • Labview:
    • writing to txt file enabled/disabled?
    • Temperature compensation is enabled
    • Temperature reading is enabled
  • Monitor the temperature of the modules (especially DIF and POWER)
  • Lubricate the moving stage
  • Temperature compensation: ensure correct values are given to the correct LDA port number
  • check the noise level in the labview. High noise is cause by a first module startup (sometimes needs a power cycle (question) ), bad slowcontrols, bad bias voltage adjustment or light leak. Typical noise is 0-2 hits in the asic.  

Run checklist

Following information must be clear from the logs:

  • what is the run number and whether it is a valid run
  • beam conditions
    • particle type, energy
    • beam rate
    • spill length and duty cycle
  • Slowcontrols loaded in the ASICs
  • Power-pusing enabled or not?
  • Voltage compensation is enabled? when did it perform it?
  • what eudaq configuration file was used (configuration can be retrieved from the eudaq log files, but it is a lot of work to dig it out later)

  • No labels