SLAC PEP-II
BABAR
SLAC<->RAL
Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Det. Search
Who's who?
Meetings
FAQ
Images
Archive
Systems
Performance
Intern. region
Vertex Tracker
Drift chamber
DIRC
Calorimeter
IFR
LST
Magnet
Electronics
Trigger
Operations
Run Coordination
Contact Experts
Shift Takers Info
Operations Manual
Electronic Logbook
Ops Hypernews
Shift Signup
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)
DAQ for DCT upgrade

DAQ thoughts (minutes of the October 3rd L3 meeting) :

In the current old DCT, the DAQ data are organized with 3 moduleTC. Each of these moduleTC correspond to a specific ROM as described in the following  table
 
ROM id moduleTC associated trigger crate
0 L1DTsfModuleTC TSF-X
1 L1DTsfModuleTC TSF-Y
2 L1DBltPtdModuleTC BLT-PTD

Each moduleTC is made of sectionTC, one sectionTC per trigger board read. The sectionTC contains the data of one board.

Each moduleTC can be defined even if some sectionTC are missing.

For the upgrade DCT, TSF data should remained identical, the BLT data won't change and the PTD data will be replaced by ZPD data. We should end
with the following configuration :
 
ROM id moduleTC associated trigger crate
3 L1DTsfModuleTC new TSF-X
4 L1DTsfModuleTC new TSF-Y
5 L1DBltZpdModuleTC BLT-ZPD

The ROM id for the upgrade DCT are not 0, 1 and 2 since we want to be able to run the 2 triggers in parallel.

During the commissioning phase,  we will run with 2 triggers in parallel, hence producing 2 L1DTsfModuleTC. To avoid the confusion, all the moduleTC will be doubled. The already existing ones will be called production moduleTC. Their twins will be called test module TC.

The module TC production will be as follow :
When new trigger is ran as a parasite of the old trigger,
ROM id moduleTC associated trigger crate
0 L1DTsfModuleTC TSF-X
1 L1DTsfModuleTC TSF-Y
2 L1DBltPtdModuleTC BLT-PTD
3 L1DTsfTestModuleTC new TSF-X parasite
4 L1DTsfTestModuleTC new TSF-Y parasite
5 L1DBltZpdTestModuleTC BLT-ZPD parasite

When the old trigger is ran as a parasite of the new ,
ROM id moduleTC associated trigger crate
0 L1DTsfTestModuleTC TSF-X parasite
1 L1DTsfTestModuleTC TSF-Y parasite
2 L1DBltPtdTestModuleTC BLT-PTD parasite
3 L1DTsfModuleTC new TSF-X
4 L1DTsfModuleTC new TSF-Y
5 L1DBltZpdModuleTC BLT-ZPD

In the above tables, moduleTC with a different name have a different type id (contains field). For the TSF moduleTC, the yet unused secondary id will be used to flag which trigger (old or new) has taken the data in the moduleTC.

Concerning BLT ZPD and BLT PTD moduleTC, Gregory mentioned that we could use TC with inhomogeneous content.

With this scheme, the TSF to new TSF transition should be smooth for L3 and OPR. However the PTD to ZPD will need the introduction of the L1DBltZpdModuleTC at some point. Do we need to suppress the L1DBltPtdModuleTC at the same time?

Update (minutes of october 18th meeting)

We want to do the same thing for the PTD to ZPD transition as for the TSF to new TSF transition. A quick look at the source code of the L1DBltPtdSectionTC shows that there is nothing board specific (except the contains field) at this level. Providing that the classes that will use the contents of the TC knows how to recognize and deal correctly both PTD and ZPD, this approach is possible.