The reformat.c routine translates/processes raw data in the MiniDAQ format described by SN0282.

A series of reformat-based .kumac's, `fmt_ped`, `fmt_geom`
and `fmt_track`, find pedestals, make geometry maps, and track
cosmic rays for these data tables. The .kumac's exist in
`~staronl/Staf/wrk/tfc`

.

Binaries (tfcStaf) for irix and Solaris exist in
`~staronl/Staf/bin`

and can be run via the script
`~staronl/Staf/wrk/tfc/Staf`

.

The running mode of this code is determined by switch settings in the fmtpar switch table. There are 6 distinct running modes, as distinguished by the value of fmtpar.event_type; these are listed below, together with their flags:

Flag Event Type Description ---- ---------- ----------- -3 Gain data Fill "gain" table with those calculated online and included in the BEGIN_RUN event -1 Geometry data Fill "valid" and "native_map" tables from incoming Structure/Data tables (pending only_type value) 0 "Normal" data ped/gain-correct data (optionally) while repackaging it into pixel tables 1 Pedestal data Calculate pedestal mean/RMS over many events 2 Pulser data Calculate pulser mean/RMS over many events 3 Gain calculation Subtract pedestal means from pulser means and calculate the gain via the integrated area of the pulser peak There are two possible ``data sources.'' One can extract data from ByteData (8-bit/1-byte) or ShortData (10-bit/2-byte) tables. The source is selected via the switch fmtpar.data_size: data_size Operation --------- --------- -1 Use ByteData; do NOT decompress to 10-bit data 1 Use ByteData; decompress 2 Use ShortData For fmtpar.event_type=0 (normal data), one can also choose to apply pedestal and/or gain corrections, or neither, via the switch fmtpar.ped_subtract. Flagging conventions are: Flag Operation ---- --------- 0 Apply NEITHER pedestals NOR gains 1 Apply BOTH pedestals AND gains 2 Apply gains ONLY Besides these flags, several other entries in the fmtpar table control aspects of reformat.c's behavior. Following is the .idl file used to create fmtpar, with the remaining fields explained:

/*********************************************************************** * Reformat switch settings ***********************************************************************/ struct tfc_fmtpar { long nped_samples[6]; /* # pedestal events in mean ped */ long npuls_samples[6]; /* # pulser events in mean pulser */ long event_type; /* event type flag: -1=geom, 0=data, 1=ped, 2=puls, 3=gain */ long ped_subtract; /* 1 if ped should be subtracted from data */ long thresh; /* pedestal-subtracted adc threshold */ float times_rms; /* quant subtracted=ave+(times_rms)*rms */ float ave_gain; /* gives absolute scale for gain */ long first_bucket; /* first bucket used in gain calculation */ long last_bucket; /* last bucket used " " " */ long only_type; /* only index type to be processed (-1=all) */ long data_size; /* size of data tables to be used (bytes) */ long printf; /* output flag */ };

Variable Description -------- ----------- nped_samples[6] The number of pedestal events used to calculate the mean/RMS values in the output pedestal table. The index corresponds to the time-ordered sequencing of ordered pairs (sector,RDO) that reformat ``sees.'' npuls_samples[6] The number of pulser events used (etc...) event_type controls the operating mode (-1,0,1,2,3 details above) ped_subtract selects application of pedestal/gain tables (0,1,2 details above) thresh lowest value written to output pixel tables times_rms (pixel ADC) = (raw ADC) - pedestal - RMS*(times_rms) ave_gain Average value of integrated pulser signal (averaged over all pads). This value is also used as the normalization factor for applying gains calculated online. first_bucket Lowest bucket number to be used in either gain calculation translation of raw data last_bucket Last bucket number (etc...) only_type Setting this to any non-negative value will result in processing only rows of the Index table having this data_type data_size Size (in bytes) of tables from which to extract raw data (1 for ByteData, 2 for ShortData) printf If printf==1, then diagnostic output will be generated during run-time.

Written: 10-JUN-1997 by Nathan Stone (edited by R.Bossingham)

Page maintenance:

Roy Bossingham, LBNL

RRBossingham@lbl.gov