Dec 2012

Date : 3rd Dec 2012 (K. Allada)

• I did some more checks to see if the data we are getting using the new TI is good or bad.
• First, I wanted to see if I can get the FADC "RAW" mode to work with the new TI.
  • First, I made sure that I am using exactly same piece of code for FADC that used to work with old TIR module.
  • When I run FADC in the "RAW" mode with new TI, I don't see a signal using the fadc decoder. I made sure that the data structure is same as the old one (no BANK etc..).
  • Went back to old TIR config (with "RAW" FADC mode) to make sure I see the signal, and I did (it is plugged in chan 12)!
  • At this point I am not sure what is wrong with the new TI config.
• Now I wanted to check "pulse integral" mode and blocking with new TI
  • When using "pulse integral" mode with BLOCKLEVEL=100 events, I see only about 25% of the events in a particular block actually have "pulse integral" and "pulse time" information, rest of them don't have this information (see run 1559). That is wierd.
  • Also, when the input trigger rate crosses ~200kHz, the datascan becomes zero and no more data is recorded. That is bad.
  • The readout time is about 50us when I use BLOCKLEVEL = 150 and with ~200kHz trigger rate.
• I also disabled BANKS structure in the data so that we can compare it with the previous data using old TI.
• B. Moffit suggested using "tiSetTriggerHoldoff()" to fix the issue of "datascan" going to zero (see email)

Date : 4 Dec 2012 (K. Allada and R. Michaels)

Today we set the parameters of tiSetTriggerHoldoff(). At first, we could not receive above about 100 kHz data rate (started seeing deadtime), but we realized we needed tight parameters. With arguments of (1,4,1) we found we could read 365 kHz of data rate with ~zero deadtime. (I say "~zero" because it's not precisely measured yet.). This is as high a rate as the pulser can go. Pretty good start.

Next, we need some analysis software to do some data-quality checks. There were the mysterious observations before that some of the events in pulse-integral mode (how we were running today) has no data, and that raw mode wasn't working. This needs to be checked. The former may be a threshold setting, the latter might be analysis software.

Date : 5 Dec 2012 (R. Michaels)

There was an observation (considered possibly a problem) on Dec 3 that in pulse-integral mode, some events don't have data, i.e. pulse integral and pulse time are missing. I studied this a bit today and found that it appears to be dependent on the threshold set in faSetThreshold. It looks like if the threshold is 10 the efficiency is 100%, but if thr=100, the efficiency is much lower, typically 30 to 50% (fluctuates). What's more, the integral depends strongly on this threshold. So, we clearly need: 1) to develop a procedure to optimize this threshold, and 2) offline software to analyze all events.

Towards the 2nd goal, here are some runs to check and develop software, my next job.

run      rate      threshold

pulse integral mode
1587      436 Hz      10
1588      416 kHz     10
1589      416 kHz     100

raw mode
1592      416 Hz