see http://icecube.wisc.edu/~krasberg/flasher_board/onvsoffrates.jpg for a simple comparison of the effects of turning on the flasher boards for the 6 rev 4 DOMs on the 90+ DOMs in the DFL... Doug Cowen and Steve: Here is what I ended up doing: I turned all the flasher boards on for all of the rev4 boards - six of them were hooked up to a domhub (the six rev 4 DOMs are in one corner of the DFL, and they have no hoods on them). I checked out the rates for a few of the rev5 FAT DOMs (which have hoods on them). I could definitely see an increase in the SPE scalar rate for one of the DOMs which was closer to the rev 4 DOMs - the SPEF scalar rate for one went up from about 1.5 kHz to perhaps 2.2 or 2.5 kHz when the rev4 flasher boards were flashing for one of the DOMs. I couldn't easily notice a difference for a couple of the other DOMs I looked at which were further away (since the SPE scaler jumps around so much it is hard to see small increases in the rate). Anyway, I took a data run with the 91 FAT DOMs reading out 32 samples on ATWDs 0 and 1 (the high gain and the medium gain channels). the 5-minute run produced a half a GByte file - it can be found on our large disk at: /home/testdaq/latest_data/UWDAQ1_run0000373_TimeResolutionFlasher I will take another run like this, then I will turn off the flashers on the rev 4 DOMs and take a final run which I will call TimeResolutionFlasherOff (for comparison). Let me know what happens when you try to analyze this data - if I have time tomorrow I will take a look to see if I can visually see the flasher board puslses the way I could see them when I was taking data earlier today inside the chest freezer... I'd be interested to see the result of running the DOMTest Dark Noise test on the 'Flasher' vs the 'FlasherOff' runs and look at the SPE scalar plots - perhaps Doug Rutledge can do this tomorrow - to verify that there is indeed a rate increase due to the flasher LEDs. Thanks Mark On Wed, 25 Aug 2004, Mark Krasberg wrote: > > We just took flasher board data in our chest freezer - > one rev 4 dom started flashing about 30 seconds after the run started. > (this was necessary because we had to take control of the rev 4 DOM after > the run had started due to the fact that all doms are on the same > domhub). > > 2 rev 5 doms accumulated testdaq data for about 7 minutes. > > i checked the data and the flasher board pulses are clearly visible. > > We read out all 128 samples for all three gain channels of the atwd. > > the data is at > http://icecube.wisc.edu/~krasberg/flasher_board/ > i think the tar file is 23 Meg. > > mark > > > ps in theory we could do the same thing using approximately 5 or 6 of the > rev 4 doms in the DFL. I am not sure I have time to do this before I leave > tomorrow afternoon - I do not know if these DOMs will still be in the DFL > when I get back. > > Please let me know if this data is good enough for now... > > for example, you could check the steering file in the tar archive > to see if the settings are appropriate. > > > > > On Tue, 24 Aug 2004, Doug Cowen wrote: > > > Hi, > > > > If it is possible to use data that is already being gathered for another > > purpose, that of course would be ideal. But I don't know if any of the > > current set of tests involves a bright light source. > > > > If not, I concur with your initial suggestion to use the rev4 DOMs, > > provided they can be read out with DOMTest software. I think that the > > most expedient way to do this analysis will be from within the DOMTest > > framework. > > > > Doug > > > > Mark Krasberg wrote: > > > > > hi steve > > > > > > i think this kind of thing would be fun to do - it would probably have to > > > be done at room temperature (at least this would be easier) since > > > we can;t get into the DFL until the end of hte FAT. > > > > > > Also, later this week I go on a trip and won't return until sep 12. > > > > > > one caveat, there is talk about needing to remove DOMs from the freezer AS > > > SOON AS WE ARE DONE WITH THE FAT. I am not sure how much time there will > > > be - although the data you ask for should not take long to get. > > > > > > one thought - we actually have around 6 or 8 rev4 doms hooked up right > > > now at one end of the DFL and they have no black cloth on them. > > > It might be possible to use these DOMs for this test? > > > > > > Perhaps we could take some data with these DOMs and you could work on this > > > data first? I might be able to take such a data set today or tomorrow - > > > I would just have to figure out how to get one of the DOMs flashing - and > > > perhaps we could take data with the other DOMS (I dont think it is > > > possible to flash the flasher board with TestDAQ and take data - we would > > > have to operate one DOM independently from the others I think - I will > > > ask someone to make sure about this) > > > > > > Mark > > > > > > > > > Anyway, I will think about it a little. > > > > > > > > > On Tue, 24 Aug 2004, Steven Movit wrote: > > > > > > > > >>Hi Mark, > > >>This is Steve Movit. I work for Doug Cowen at PSU. I'm contacting you > > >>based on conversation with Martin Kestel about collecting freezer data for > > >>several purposes: testing timing calibration, basic geometry, and > > >>hopefully creating some pseudo-cascades to practice crude reconstruction > > >>on them. I've attached an email from Martin with the parameters of the > > >>tests we'd like to run. Does this sound reasonable? > > >> > > >>Basically, we want to use the flasher board on a given OM, and look at > > >>the response of nearby OM's. According to Doug, if we want to simulate > > >>a cascade, "all we'd need is a bright flash that hits all the tubes, if > > >>that is possible. If we know the locations of the tubes relative to > > >>each other, which I assume we know reasonably well, then we can > > >> try to reconstruct the position of the flash." > > >> > > >>Can we get some dedicated time at the end of the DFL period? > > >> > > >>Thanks. > > >>--Steve > > >> > > >> > > >> > > >> > > >> > > >>--------------------------------------------------------------------- > > >>The data recording for a test-sample cannot be done at this time (due to > > >>higher priority items currently at/in/with the DFL). > > >> > > >>What is required on your part and actually a good starting point is to > > >>talk to Mark Krasberg (he is in charge of the DFL operations on the dat > > >>recording side of things) and ask him for a dedicated time slot at the end > > >>of the DFL period in which you > > >> > > >>-- remove the black cloth covers from that subset of DOMs that should > > >>either fire their LEDs or record those flashes (probably you will be asked > > >>to leave the covers on the next neighbours of the designated flashers) > > >> > > >>-- instruct your flasher DOMs to flash (patterns, how many DOMs at a time > > >>etc. TBD) > > >>-- record data with all DOMs, including those still 'blind' > > >>-- verify the data quality, especially in terms of channel saturation and > > >>the availablity of lower-gain channel data that can be used instead. This > > >>step is important and should be done right away, preferentially on-site by > > >>a domtest expert. > > >> > > >>Target time for this will be the first or second week of September. > > >> > > >>Steve, I will be leaving for vacation tomorrow but will continue to answer > > >>my email in irregular time intervals. > > >> > > >>Martin > > >> > > > > > > > > > > > >