TIM configuration parameters (as they can be setup by RunConfigEditor tool)

TIM Running mode

Below all configurable TIM operation modes are listed in the relevance order. Description of configuration parameters is omitted if irrelevant for this mode.

• EXTERNAL_LTP TIM is in transition mode. Necessary for data taking in the pit while running with ATLAS or standalone with more than one crate. All Timing Trigger and Control signals coming from the TTC crate through the fiber are transferred to a ROD with minimal latency. Optionally trigger signal can be delayed (4-259 BC effectively) which is useful e.g. for taking cosmics. BCID offset has to be applied in order to shift forbidden BCIDs into the long gap.
• INTERNAL Default mode of operation, but only useful when data are taken with one ROD crate. TIM generates trigger pulses with a constant frequency in the range 40000kHz-0.0000001kHz controlled by a parameter triggerFrequency (in KHz). Default value now is 10kHz, which might be too much if noise occupancy is large. Trigger delay (triggerDelay) can be also be adjusted in the range 0..255 (effectively 4..259) bunch crossings. ECR frequency is not used at the moment. TIM sends its internal 40.08 MHz clock to RODs/BOCs. Trigger type (triggerType) can also be specified to track the data files. This operation mode is useful for taking random noise data on one crate.
• CAL_INJECT TIM generates a CAL pulse followed by a trigger pulse after a programmable delay (Delay between CAL and TRIG in active TIM, CAL_INJ mode). To generate the sequence TIM uses internal sequencer (pattern generator), which is triggered either externally (EXTTRIGSEQ) by a pulser or internally (INTTRIGSEQ) by an internal trigger source. It is not possible to use triggers from TTC to trigger the sequencer! The triggering mode of the sequencer can be chosen by a parameter (Sequencer triggering mode). Sequencer outputs only CAL, trigger and BCR signals to a ROD. In the EXTTRIGSEQ mode BCR and clock signals are taken from LTP crate modules for the purpose of synchronisation of several TIMs => LTP crate modules must be properly configured. Optionally sequencer can be programmed to generate after-pulse triggers after a delay, which is set up by two parameters - one for after-pulse delay (Trigger delay in passive TIM, CAL_INJ mode) and one for number of after-pulse triggers (Number of subsequent triggers in passive TIM, CAL_INJ mode). The following TIM configuration may be used:

And the corresponding run configuration:

• SEQUENCER TIM generates all TTC signals internally using sequencer configuration stored in ~/configs/sequin.cfg. This mode has also internal/external sequencer triggering option. The .cfg file has the same syntax as LTP pattern generator, i.e. each line describes TIM output state for one bunch crossing unless multiplicity parameter is applied.
• INT_RANDOM TIM generates trigger pulses with a random frequency. Mean value of the frequency can be specified by triggerRand2Frequency parameter.
• EXTERNAL_NIM All TTC signals (ECR, BCR, CAL, Trigger) with the exception of the clock are taken externally (NIM or ECL) from TIM front panel.

TIM debugging

• Diagnostic tools
• TIM3 web page
• Some of the tools (TimStatus, decode_eventROStext) can be found also in pixeldaqdev/tools directory

Tipps and tricks

• Partition is running but data-flow rate is 0. Check first if you send triggers either by looking on TIM front panel LED or by using of TimStatus program, which shows status of trigger counter/BCID. Use the same program to see any of RODs are BUSY and which ROD BUSY's are OR'ed to form crate BUSY which is used to block triggers in TIM/LTP.

References and Talks

• Data taking experience with Endcap A
• ATLAS Global timing workshop
• Summer Student introduction on Trigger
• Thilo's note on BCID

ROD configuration parameters (as they can be setup by RunConfigEditor tool)

Each ROD can have either individual run configuration or have a common (global) one for a group of RODs, accessible by pressing "r". Basically there are two modes of ROD operation - normal one and with simulated input data. EventSimulation_SimulationEnabled parameter controls the choice. If you plan to use simulated data specify also EventSimulation_ModuleOccupancy (# of hits per module per event) and EventSimulation_LVL1Accept (# of consecutive data packets sent in response to one trigger) parameters. The last one has to be by 1 lower than the number of consecutive LVL1s sent (controlled by RunParams_consecutiveLVL1 parameter)

References and Talks

-- IskanderIbragimov - 27 Aug 2007