Glitch Library



1. Duplication waveform.
    We found an unexpected phenomena in the data taken at the Southpole (2002-2003). The phenomena is that a part of waveform is repeated in the other waveform.[see the waveform].  Also, recently the same behavior is reproduced in the laboratory.  We reason is not understood yet.  A detailed investigation is performed with Acqiris Sofrware Support. The followings are what we found so far.
     a)  It happens only in the event "timed out - force trigger"
     b)  It happens in the second segments waveform only.
     c)  It happens CH1 and CH2 together.
     d)  It happens negative delay time (t_delay)
     e)  The size of duplicated waveform stronly depends on t_delay
t_delay (sec)   
  # of duplicated waveform
-0.5e-5  ( 10% of full WF)
  about  9910
-1.5e-5  ( 30% of full WF)
  about 29910
-2.5e-5  (50%  of full WF)
  about 49720
-3.5e-5  (70% of full WF)
  about 29720
-4.5e-5  (90% of full WF)
  about   9690
 zero or positive
  0
                  **with Nsample:100000, Sample_interval: 0.5e-9 sec

So far no fault has been found in our code even after very detailed check. Furthermore, the same behavior is well reproduced in a simple example code which was provided by company.  It may be behind of user's level.
No quick solution is expected from compay because the contact expert who is  Software Support Manager in Acqiris will go vacation untill August 4th.

Our Recommendation and suggestion.
We recommend the ANITA DAQ that "do not use negative delay" or "do not use multiple segment sequence" until solve this problem.  For an altanative way,  we suggest to take single segment waveform with double size of Nsample.
Also for the analysis of the data taken at the southpole, we recommend to use the first segment waveforms only.

Conclusion (After August 4th)
We figured out the problem is caused by the forced trigger itself.
Usually a single aquisition can be finished when all triggers of each segments are done. But the forced trigger is used in order to stop the data acquisition before remained segment(s) is taken. So the data in the data in remained segments are not perfect, only the first segment is correct. This problem can't be solved in current Acquiris software. To solve this problem they need new function to force each segments seperatly.

2. Glitch after sending a signal to the system.
The other unexpected phenomena is the glitch just after sending a signal to the system. This glitch was also observed in the south pole data.  Most of all time when we send a signal to system, the waveform become very unstable. Then the system returns to the stable condition after taking few waveforms. Of course the unstable wavorms have been excluded in the data analysis.
Good news is we found where the problem is.  
Problem is on the global signal like ^c (ctrl-c) or ^z.  Because we are using ^c signal as a interrupt signal in order to stop the program during we change the configuration variables.  Unfortunatly the ^c dose affect to our Acqiris system. Especially the ^c signal affect to the system when the Acquire process (real data acquisition) is running.
So important thing is the timming when we should send ^c signal. The answer is anytime when Acquire process is not runnig. For example, We found no problem when we send ^c  during the Readout process after Acquire process done.

There will be several solutions. We may think about not use the ^C to interupt the program. For example, we tested a simple  GUI control pannel to control the program. It can control the problem by clicking the button without use of ^c signal.

2. External Glitch.
Also we observed unexpected real signals. It seems like human made radio signal.  Most of all events in "jan26opentritip" run are trigged by this signal. But it is not identified yet. Following  shows an example waveform and power spectrum of that event.