NDOS CommissionMtng 20120716

Attending: Chad, Denis, Will, Jessica, Chris, Leon, Jon, Mark

APD Monitoring:

Will - Detector Plotter package. Root version issue. Working to get more information?

Mark Mathis:
it looks at the thresholds of each channel, and compares those over time. I also make plots to show how many channels flip from good-bad or bad-good, and have started breaking out some of those by coating, which Matt has been looking at. Still have some debugging to do, and if we have a summer student (?) who could work on that, that'd be great. Most of the plots that are made in the CR scripts are reproduced by my scripts as well.

Chris Backhouse: Interested in dropping the thresholds in DCS running to collect data on non-guassian noise tails.

Email- porposal:
To flesh out what I suggested in today's Commissioning meeting a little more:

docdb 6068 contains what I initially did with DSO data. It sounds like we're already processing DSO into histograms like this to monitor the APDs. One thing pointed out here is that if you plot a few different deltas instead of just the raw values/DCS you can get at the time correlations, and thus how much of the noise is current noise or voltage noise. Here all the noise seemed to be matchable to the gaussian model in the MC.

Then in docdb 6633, slide 7 starts to show the non-gaussian tails. But this is a large quantity of DSO data and you can still barely see it (clearer summed together on slide 8). We run out of stats right around 50 ADC, where this starts to become relevant for physics coming out of the NDOS.

The suggestion is to try and look at this in normal data instead of DSO, where the short scan times limit your stats.

Leon's suggestion is that in general we should be able to set the thresholds lower. Right now they're based on an extrapolation from the gaussian central part of the distribution taken from DSO traces. This has to be conservative because it doesn't have enough stats to see what happens in the tails. Instead, we can determine the tolerable thresholds empirically. Start at some reasonable values, and then gradually lower the threshold until you find a rate in normal running that is "too high". Leave it set just above that point.

I don't know what the definition of too high a rate will be. Possibly it's the level at which the readout can't handle it. But if that's more than an order of magnitude from where we are now it may be that Offline have something to say about the increased file sizes. But for physics purposes, really, lower is always better.

In any case, my suggestion was to take special runs with the thresholds as low as possible to look at the noise shapes. Depending where the bottleneck is, it may well be possible to push the threshold even further down to where it gives a ~30x higher rate than normally tolerable by masking off (or at least not changing the threshold on) all but one of the pixels per APD.

Looking at a real data file, one subrun may be about the length you need to get a reasonable-looking plot.

Also, note that I see the non-gaussian tails on the negative sides as well as positive. I'd love for the DCS trigger to be altered so that it picks up large negative excursions as well as positive. We'd just cut them out for physics, but they'd be good to see to understand the noise better.

Leon - Expects 3% light loss from parylene coating. This is probably lost in the noise due to temp variation and HV settings.
Looking to make rate versus threshold plot from APDWatch
Needs to load calibration in of into DB for newest APDs from test stand

Jon - Has scripts to get HV setting. Will make it generate cvs file. Will set an default exception for missing info
-Calibration info from recovered parylene should still be good

Kirk (email) - Just so everyone knows, I have a basic website ready that connects to my database and shows basic information for any APD or channel.  It's still crude and needs work but it has basic functionality.  You can use it to check average #pe/hit, APD temperature, and rates > or < 100 pe for the whole APD or any channel on the APD, for 2 day and 4 week time periods.  It has some downsides - it calculates plots on the fly, which takes ~10 seconds, and the way it is set up it'll probably get confused if more than one person is trying to use it at once.  Please try it out though and give me feedback.

note - if you look at an APD, it will list the channel numbers for each pixel at the end. 

Run Plans:
Hardware Inventory and Checkout (UMn Crookston) expected at Fermilab

1.  Detector Update -
Crookston with Denis, checkout, inventory and hardware.

2.  DataCheck Update
Two weeks ago: 7/9 - 7/15
Monday to Tuesday
13964 19 subruns
FEB2-3:44 shutoff in subrun 0
FEB1-1:38 shutoff in subrun 1
FEB2-3:11 shutoff in subrun 4

Tuesday to Wednesday
13966 18 subruns
FEB2-3:11 shutoff in subrun 2
FEB2-3:32 shutoff in subrun 2
FEB1-1:38 shutoff in subrun 16

Wednesday to Thursday
13968 19 subruns
FEB2-1:21 shutoff in subrun 0

Thursday to Friday
13971 19 subruns
FEB2-1:21 shutoff in subrun 0
FEB2-3:44 shutoff in subrun 2
FEB1-2:33 shutoff in subrun 8

Friday to Saturday
13973 24 subruns
FEB2-1:21 shutoff in subrun 0
FEB3-1:0 shutoff in subrun 0
FEB1-1:38 shutoff in subrun 3

Saturday to Sunday (no data on subrun 9)
13974 24 subruns
FEB3-2:6 shutoff in subrun 19

Sunday to Monday
13975 17 subruns
FEB3-2:23 shutoff in subrun 2

4.  Installation Plans for the week
APD status - thermistors were damaged (15 in working order)
2nd week in August likely install target

5.  DAQ Update and Plans for the week

6.  DCS Update and Plans for the week
Synoptic Display interface

7.  AOB