Helicity and Charge Asymmetry
Shift worker info
Soon to come
Information for experts
DRAFT
We are running with delayed helicity reporting.
The helicity state of the beam is reported with a delay of 8 helicity windows; we are running with quartets, so it is delayed by two patterns.
The reported helicity, pattern start signal, and the T_settle (time during which the helicity can change) are all recorded for each physics trigger in two FADC modules, one in LHRS and one in SBS bunker. The T_settle is used to veto and latch the helicity scalers, and the reported helicity and pattern start signal are latched into the scaler events; the helicity scaler inputs are the V/F signals from the BCMs. So for each helicity window we can determine the average beam current. The scalers have an internal buffer that allow us to accumulate up to a large (but not infinite) number of scaler events in their internal memory before they are read out. They are read out during physics events if they have data available. The helicities in each pattern are either +--+ or the inverse. The starting helicity of the pattern is generated in the helicity generator board with a 30-bit psuedorandom algorithm. Once you have measured the starting helicity of 30 patterns, you can reconstruct the seed of this algorithm, and then use that to predict and check the starting helicity of the next pattern, or you can pass the seed to the analyzer to calculate what helicity would be reported two patterns later. This is the predictor. In order to build a helicity seed you need to have the starting helicities from 30 consecutive patterns. We use the scaler events to record these starting helicities.
The "scalhel.hel" variable that Sean showed is the "true helicity" for the triggered event. I have added additional cross-checks in the decoding to compare both sets of FADCs and scalers and set "hel" to zero and set an errorcode if the systems disagree. I will push that up and submit a PR. I or someone else can work to go back through the runs we have taken to see what we get from this system.
Questions
- What’s the point of “delayed reporting”?
- It is to avoid false asymmetries from pickup of the reported helicity signal. The pseudorandom generator and delay means that the electrical signal you record as the helicity state is independent of the true helicity. It is very important for PV experiments, but even non-PV experiments with smaller asymmetries can be impacted.
- Hhow small does the asymmetry being measured (and its uncertainty) need to be before this becomes important? what’s the threshold? Was this important for GEn?
- I don't know off the top of my head. I think we didn't really care about getting delayed reporting. We had asked Hall B if they wanted to use prompt or delayed reporting, and they wanted delayed. I don't know if they really needed it or just were used to it.
