Mapping of electronics addresses (without HV)

When you want to read or write a set-up parameter for any detector, and when you want to map your digitized data to their detectors, you obviously need the addresses of the electronics. For that purpose, you want to have tables which are keyed by the signals (i.e. whose first attribute shows up in column DET_SPEC of table DET_CONF and has the value 'self' in column SIG_SPEC). Such a table may have any name you like, and it will typically look as follows:

 
Table: Electronics addresses for two LAND detectors  

This table tells us that there are two PMTs called 'land01' and 'land02'. Both PMTs are connected to the same CFD 'cf1234', and their signals go into adjacent channels 0 and 1. The location of 'cf1234' (branch, crate, and slot number) is provided in a different table, called ELECLOC, which is shown in table . The outputs of the CFD go to the TDC module 't56565', whose location is also given in ELECLOC, and to the addresses 37 and 39. The energy signals go into different QDCs, but happen to have the same address (95) in the two modules.

The attributes of table  cannot be chosen arbitrarily, but are derived from entries in table PAR_CONF and ELECLOC: The first three letters of the appropriate entries in column MOD_TYPE have to re-appear as the first three letters in the attributes XXX_ID and XXXADDR. The reason for this convention is two-fold: First, when you want to access any parameter like 'walk', 'thr_cf' and 'thr_le', the software obtains via the MOD_TYPE in table PAR_CONF (table ) the attributes CFD_ID and CFDADDR it needs for the connection to CAMAC addresses. (In practice, this applies only to CFDs right now.) Second, the command CHKLOC (cf. 'help'-info and section 3.8) uses MOD_TYPE from table ELECLOC to obtain the attributes needed for the connection to signals, i.e. XXX_ID and XXXADDR.

For the second application of the set-up database - the mapping of the data in the event stream - no general convention has been established, since there are special routines for all facilities anyway into which the names of the signals etc. are hardwired. We do not see an easy way around this, since the signals from different facilities may have different numbers and different kinds of outputs (one energy and one time from most scintillators, but one energy only from the FOPI-ROSACE, one time and two energies from BaF-counters, etc.)