90 likes | 216 Views
Online Data Format and Condition Database. Proposed data format In the FE crate After zero suppression ECAL-HCAL Prs-Spd Use of the Condition Database. Online Data Format. I have an unpublished Note From March 2001, never published It should be after we agree on the format !
E N D
Online Data Format andCondition Database Proposed data format In the FE crate After zero suppression ECAL-HCAL Prs-Spd Use of the Condition Database
Online Data Format • I have an unpublished Note • From March 2001, never published • It should be after we agree on the format ! • This was probably presented at some meeting • but I haven’t found when • Sorry for that ! • The format in the FE crate is well defined • 21 bits are transported from FE card to the CROC • 20 bits of data plus a parity • 12 (ADC) + 8 (Trigger) for ECAL and HCAL • 2*( 8 (ADC) + 1 (Prs trigger) + 1 (SPD) ) for PreShower Online Data Format and Condition Database
Parity Parity Trigger (8bits) ADC value (12 bits) SPD SPD PRS PRS ADC content ADC content • This will be the input of the L1CommonBoard • Replaces the CROP, common board -> less maintenance problems • What is the format of the output to the DAQ ? • We don’t send to L1, so nothing to specify there. • We want a compact format, but with calibrated data. • Final cell ID should be generated First cell Second cell Online Data Format and Condition Database
ID of the first cell Cluster length Energy in MeV, float, first cell Energy in MeV, float, second cell First cluster Energy in MeV, float, third cell Energy in MeV, float, last cell ID of the first cell Cluster length Energy in MeV, float, first cell Second cluster Energy in MeV, float, next cell ECAL and HCAL format • Data is clearly defined • 32 bits words • Cluster of consecutive cells • Specify the ID of only the first cell. 16 bits is enough. • Data on 32 bits • Floating seems the best (most efficient) • Can have integer energy in keV (maximum = 2000 GeV on 32 bits) Online Data Format and Condition Database
ID of the first cell Data first cell Data next cell ID of the first cell Data first cell Data next cell • Trigger data is less clear • We want to keep unchanged the 8 bits • We want to zero-suppress, and minimise the total size • Put two consecutive cells and a CellID in a 32 bits word Online Data Format and Condition Database
ID of the first cell 8 SPD bits 8 PreShower bits ID of the first cell 8 SPD bits 8 PreShower bits PreShower and SPD • One solution is to pass the 10 bits unchanged • Just put the cell ID in the upper 16 bits • But not too easy to use… • Preferred proposal • Same format as ECAL-HCAL for the data • ADC (special non-linear coding on 8 bits) back to 10, then to keV or float. • Trigger data as bit patterns, both Prs and SPD together • Send only non empty patterns • Should make the data compact enough. Online Data Format and Condition Database
Data will be produced by “FE” modules • This is the DAQ view, this means by L1 common board module • 2 modules for ECAL outer and middle part, Prs outer part. on each side. • One module for ECAL inner, hcal inner and outer, Prs middle and outer • Total 22 modules • Simulation of the format seems easy • But has to be done • Some attempt was made, and reported in June 2001 • But the code is no longer in Calo/CaloDigit • I can probably implement that quite soon • Main question is how to define the L1 Common Board boundaries. • Yet another function of the Detector Element ? Online Data Format and Condition Database
Condition Database • Provide data that can change with time • Typically alignment, calibration,… • How can we use it in the Calorimeter software ? • Replace some constants from XmlDDDB • Calibration : GeV per ADC count • Calorimeter positions • Replace some jobOptions • Noise and gain error in the digitisation • What are our special requests • None as far as I know • Just some values for specified parameters, accessible from the Detector Element or from an Algorithm Online Data Format and Condition Database
Discussion of initial implementation tomorrow • First session of the “Software Week” is on alignment and calibration, as this is important for Velo, RICH and tracking • If we have special constraints / idea, we could contribute to the discussion • I guess we just have this simple requirement • Parameters with name and value • Alignment to supersede the XmlDDB values • Translation and rotation matrices • But I may have forgotten something important ! • Speak now… Online Data Format and Condition Database