TOF multiplicity window timing scan steps:

The TOF multiplicity is accumulated in the FPGAs in the TOF trays in a
~53ns window. The RHIC clock is sent to the TOF trays from the TOF DSMis 
associated with TF001-006 in the MIX crate. There is a correlation plot in 
the trigger section of the online QA that compares a simulated L0 
multiplicity using data from the HPTDCs selected within a trigger window (on 
the Y axis) and data from the L0 trigger (on the X-axis and labeled L1). 
Each NINO chip receives data from 8 MRPC pads, but contributes only "0" or
"1" to the multiplicity value for the tray. The multiplicity value for a tray
can range from 0-24. Additional details at the bottom below.

In order to use the correlation scan plot to monitor the performance of each phase
setting, the trigger timing windows in Jevp/StJevpBuilders/tofBuilder.cxx must be correct.

The phase of the multiplicity window is adjustable in ~6.7 ns steps using 
a hex value 0-f. The current setting for Run 13 as of today, March 12, is 
"f". The value in Run 12 was "d". The multiplicity phase is set automatically
on power up of the tray, or at the reset command issued at the start of 
every run, or to clear tof daq errors. This automatic reset needs to be 
overcome in order to change the phase value and perform a timing scan.

Steps:

The run can be performed with just a BBC trigger. Only trg, daq, and tof 
need to be included. The trigger will fire at a high rate with a proper 
prescale and 50k events can be recorded in less than a minute. That is 
enough of events for each correlation plot.

1) open a tofcontrol terminal window

2) select a current configuration (having the proper tier 1 file) with a 
BBC trigger.

3) take a run with 50k events. This run will have the current default 
phase value. After the end of the run:

4) on tofcontrol,  execute: sudo /sbin/service tof_recoveryd stop

5) execute the script

  ./multGate.sh x   on tofcontrol  where x=0-f, the phase of the multiplicity
   window.

6) take a run with 50k events

7) return to step 5 until runs for all the desired phases have been taken

8) if tof daq should encounter data errors, it will try to clear them 
but will fail and issue a tof power cycle. The power cycle will fix the 
error if it was an HPTDC error, but tof daq will now see bad bunch ids 
and possibly missing bunchids and will eventually stop the run.
To recover,

execute: sudo /sbin/service tof_recoveryd start

Then go to step 3 to see if the daq errors are all cleared and continue 
with the remaining phase values.

9) at the end of the scan,

execute: sudo /sbin/service tof_recoveryd start

Make sure that recoveryd is running when you finish this effort.

  /sbin/service tof_recoveryd status

Additional details:
A larger phase value means a later real time. However the transfer of the data
from the TCPU does not shift when the phase is changed. Jack and Ted set this
value 3-4 years ago when TOF multiplicity was first added to the trigger by
using a scope at the DSMi and seeing the level change. The level change is
set safely away from the latch in the DSMi. Since the TCPU gets the experimental
clock from the DSMi, it will always be using the same clock as the DSMi and any
changes to the DSMi clock cannot affect the proper latching of the TOF data.

In the correlation plots from run13 pp, the level change in the signal to the DSMi
occurs between phase 0 and phase 1. To say this another way, the gate for phase
0 is 6.7 ns later than the gate for phase f. The gate for phase 1 is 100 ns earlier
than the gate for phase 0. In phase 1 you see the hits in L0 from the previous
bunch crossing but there is no correlation with the offline data since TOF offline
and TRG L0 are different bunch crossings. By phase 7 we are 180 degrees out of
phase with the beam. By phase C we are picking up hits from the collisions and
there starts to be pretty good correlation with the offline hits from the trigger
window.