Log entry time 23:44:06 on March 12, 2012

Entry number 366048

This entry is a followup to: 366028

That's not just from the T-settle uncertainty, actually, a lot of it come
from the beam trip.
Because we receive delayed helicity from injector, we need to predict the
helicity, also we can use predict code to check whether if there has the
helicity signal lost. The helicity pattern is a pseudo random pattern of
(+--+) or (-++-), a 30 bit register is used for generate the pseudo
random number, so we need at least 30 patterns of helicity to predict it,
and we will set it to unknown helicity in helicity decode program before
we predict it.That means, there have 30x4=120 helicity windows will set
to unknown helicity before predicted. if the coda rate is 6KHz, there
will have 120x6=720 events set to unknown helicity. We have three sources
to record the helicity, TIR,scaler,happex, even if one source lose data
we can also use other two sources to recover it and do not need to
predict again. For scaler ringbuffer and happex ringbuffer, both of them
have 2000 depth, and we set to maximum read 50 buffers(1 buffer save 1
helicity window data) in one event trigger. The frequency of helicity is
1000Hz, so even if beam tripped for 2s we still do not need to predict
again. The reason we set to maximum 50 events is that reading a lot of
ringbuffer data will cause dead time. But if beam tripped for more than
2s we need to predict again. We can increase the ringbuffer depth to
10000 so that we can allow 10s beam trip, but that will cause we need to
read a lot of ringbuffer data after the beam back, also the memory of cpu
is limited we don't want to add any unstability of cpu. also we can add
more than 20Hz clock trigger during the run, so that we can make sure the
rate will not low than 20Hz which will not cause any data lost in
ringbuffer(1000/50=20).
I think it is the better way to add a >20Hz clock trigger than add the
ringbuffer depth.