Hall A in G0 Helicity Mode

This file: http://www.jlab.org/~rom/g0helicity.html

With thanks to Ron Gilman, Hari Areti, Roger Flood, and Mark Pitt.

Last updated July 12, 2006

R. Michaels   rom@jlab.org
During running in the G0 era, helicity data are produced by the G0 electronics. There are four relevant signals : 1) MPS, 2) QRT, 3) Helicity, and 4) Pairsynch.   MPS is the master pulse at 30 Hz. For HAPPEX running it is line locked to the 60 cycle line, while for G0 it is not line locked. QRT denotes the beginning of a quad. Helicity comes in a quad structure (either +--+ or -++-). The pairsynch is a 15 Hz square wave. The G0 scheme is defined by Mark Pitt in this document g0helicity.pdf.   In hall A, we have organized our electronics to send these signals with correct timing to an input register that flags the data for each event, and also to scalers. Here is a timing diagram and from Ron Gilman here is a helicity electronics in counting room which hasn't changed much over the years.

In addition to helicity and QRT, we use MPS as a gate to define when the helicity is good. There is a blank-off period of about 0.5 msec for each 33.3 msec gate period. This blank-off is the time during which the Pockel cell at the source is changing and settling. All three bits (helicity, QRT, gate) are read in our datastream each event. Also they are read by scalers which have input registers, and the gate is used to gate the scalers.

NEW !! Note to data analysis folks:   Here is How to implement helicity in ``Podd".  

And here is somewhat older information about how to decode the helicity and scalers from ROC10 and ROC11 -- which you probably don't need if you use the Podd implementation (done for you).   Also available is the tar file of the code that predicts and tests G0 helicity predictor algorithm (untar this and see the README file).

For backward compatibility, the old packaging of data as it appears in "event type 140" remains the same. To find glitches and recover from them, one needs to use the new ROC10/11 data. The end-of-run summary which appears in halog (and elsewhere), as well as the xscaler display, will retain their familiar format.

Analysis of scalers: See the documentation in hallaweb.jlab.org/equipment/daq/THaScaler.html.   Analysis shows that the G0 helicity predictor algorithm agrees well with data, except for some rare glitches (once in 12 hours). These problematic periods are tolerable and are well-identified in our datastream, and we recover after 3 seconds.

Part of the pre-run shakedown will verify we observe an electronically generated asymmetry with both HAPPEX and spectrometer DAQ. This still doesn't test whether we know the delay of the helicity. There is an EPICS variable that tells us if it is delayed, but we have only one way empirically to verify this delay, I think: First make a successful Moller or Compton measurement of polarization, then induce a large charge asymmetry, and finally verify that all the DAQs see the same charge asymmetry.