Alternative/Additional In-flight Calibrations (Sasha and Eric)

• Proton Calibrations
  • It looks like we are rather limited in statistics of GCR, even with carbon - to get 1000 hits per crystal (without any angular or position selection) we need 2-3 days. With iron this number is ~200 days. Without selection the pathlength is rather sensitive to position measurement, so the error in position measurement could significantly broaden (and bias) the energy deposition peak even after pathlength correction. This means that even with carbon we should wait for few days (may be ~10 days) until we get the calibration. Another problem with GCR calibration is that we cannot test the procedure on the ground, so we'll definitely find some problems at the beginning.
  • It seems reasonable to use the alternative method of calibration, similar to what we are doing now, using protons to calibrate LEX8 range and any background energy depositions to intercalibrate other ranges and propagate the calibration from 12 MeV up to 70 GeV. Intercalibration of ranges with background energy depositions could be also used together with carbon peak measurement to propagate calibration from 500 MeV to higher energies (without using iron peak which requires much longer period of time to get reasonable statistics).
  • In order to collect protons we need to define a special mode of operation, when we "invert" the ACD veto (require the presence of ACD signal in the ROI), select only "clean" protons by onboard filter and prescale them to make the event rate acceptable for sending them to ground. These protons could be then processed by the same calibration procedure (calibGenCAL) as we use now for muons. We probably can just implement in the onboard filter the selections of "vertical" protons, used now in calibGenCAL(coincidence of 4 crystals in the same column) - this will allow us to send only necessary proton data to the ground. Note that, unlike heavy ion calibration, this is a special, non-science operating mode.
• Range Intercalibration
  • To intercalibrate the ranges ( as we did with GSI heavy ion data, for example) we need 4 range readout. This requires a separate trigger engine which accepts events with sufficiently big energy depositions in CAL (for example, containing CAL_LO trigger bit) and prescale them by appropriate factor to keep event rate reasonable. Simulation is needed to estimate the expected event rate.
• Calibgen Modifications
  • We plan to modify calibGen script for charge injection calibration. One significant change will be the use of "broadcast" charge injection (pulsing all channels simultaneously) replacing "columnwise" charge injection which we used so far. The comparison done for FM119 showed that the difference between the two modes is ~0.3% and is the same for almost all channels in a tower. Another change is the additional charge injection runs to measure the crosstalk from LE diode to HE diode in realistic LE/HE signal ratio, which could be done if CALIBGAIN bit is set to OFF. We propose to have two versions of calibGen:
    • flight version, containing only flight gain configurations and only broadcast charge injection
    • NRL version, which will be used during LAT environmental tests at NRL and which will contain also configurations with muon gain in HE diode and columnwise configurations ( to make a comparison broadcast vs columnwise for full LAT).
  • The use of broadcast charge injection in flight version will decrease by factor of 12 the time of test and the size of resulting files. This will allow us to add few runs with FLE/FHE=127 (the maximum possible value) to suppress the effect of FLE/FHE crosstalk which makes the analysis of charge injection curves rather difficult.
• MuTrig Modifications
  • We plan to modify muTrig script for measurement of FLE/FHE thresholds. It will contain only one configuration with flight threshold values. This script requires diagnostic information for CAL.
• On-Board Trigger Efficiency
  • We need to monitor the efficiency of onboard filter, both for photons and heavy ions. In order to do this, we probably have to allow some small known fraction of triggers to bypass the onboard filter (apply only prescale factor, not onboard filter). This fraction should be chosen small enough to keep total event rate acceptable. These events will allow us to measure the efficiency of onboard filter for different event parameters and configurations. (We didn't really discussed this last point with Eric, we just agreed in our worry about unknown efficiency of onboard filter).