Post by jsmith on Feb 13, 2015 14:48:15 GMT -8
Problem: During the last set of experiments, we noticed that the timestamps were not being reset on all the GRIF-16s for every run. We wrote a script to check the high timestamp words from the GRIF-16s and compare those to those from the 4Gs. In most cases, this fixed the obscenely large timestamp differences between GRIF-16s. During my data analysis, I noticed smaller timestamp shifts as well (~800 ns and ~70 ns). Timestamp shifts on this order are only offsets in the low timestamp word, which we didn't check during the experiment. Some diagnostics on other "good timestamp" runs revealed that during another of my long runs, two of the five GRIF-16s had offsets of ~1 us.
Fixing the DAQ problem: We think this was caused by the GRIF-16s not properly registering the "stop run" and "start run" commands. Bryerton thinks he has fixed this problem, but to my knowledge, this has not yet been tested.
More details: This problem has so far been correlated with GRIF-16s and not individual channels. Thie will significantly affect any analysis based on time coincidences - including event building. The problem appears to be random - some runs are perfectly fine, other runs are not. It also does not appear to change within a single run; the offsets have been the same for all subruns within a single run.
Offline fix: There are offset values that needs to be applied to timestamps from the errant GRIF-16s, one for each module. I've been thinking of the fix as two steps: figure out what those offset values are, and then apply the corrections. I've attached a few pages of my logbook about fixing the timestamp problem. They show how I identified the necessary timestamp offsets, both large (affecting the TimeStampHigh word) and small (only affecting the TimeStampLow word). Some of this will be useful, some will not. The program for creating a corrected MIDAS file is also attached (offsetadd.cxx). The compile line is commented at the top. Look for the comment: "Here's where we change the values of the time stamps!!!!" for, well... you get the picture.
Fixing the DAQ problem: We think this was caused by the GRIF-16s not properly registering the "stop run" and "start run" commands. Bryerton thinks he has fixed this problem, but to my knowledge, this has not yet been tested.
More details: This problem has so far been correlated with GRIF-16s and not individual channels. Thie will significantly affect any analysis based on time coincidences - including event building. The problem appears to be random - some runs are perfectly fine, other runs are not. It also does not appear to change within a single run; the offsets have been the same for all subruns within a single run.
Offline fix: There are offset values that needs to be applied to timestamps from the errant GRIF-16s, one for each module. I've been thinking of the fix as two steps: figure out what those offset values are, and then apply the corrections. I've attached a few pages of my logbook about fixing the timestamp problem. They show how I identified the necessary timestamp offsets, both large (affecting the TimeStampHigh word) and small (only affecting the TimeStampLow word). Some of this will be useful, some will not. The program for creating a corrected MIDAS file is also attached (offsetadd.cxx). The compile line is commented at the top. Look for the comment: "Here's where we change the values of the time stamps!!!!" for, well... you get the picture.
