see UWDAQ1_run0000373.txt for further explanation. Doug Cowen: run UWDAQ1_run0000637_TimeResolutionFlasherOneOn is a run where one rev4 mainboard in the DFL was flashing and the other doms were taking data. i dont have time to do any more runs like this now. mark On Thu, 26 Aug 2004, Doug Cowen wrote: > Hi Mark, > > This does indeed look encouraging. Thanks for acting on this so quickly. > > One question: From what you wrote it sounds like you were firing > multiple flasher boards at once. If so, is it correct that these boards > do not flash simultaneously relative to one another? > > Even if you could make them flash simultaneously, the data we want > should have just one flasher board flashing. > > Remember, we are trying to reconstruct a point source. If that point > source is actually a set of point sources at different locations, then > the point source becomes more of a "blob" source, and thereby harder to > reconstruct. > > If all the flasher boards are flashing non-simultaneously, then although > we will have multiple point sources, we won't know--from event to > event--which flasher board actually flashed, and that will make this > effort much harder if not impossible. (Even if that information was > available, it would make the data substantially harder to analyze I think.) > > So, unless I am missing something, or misinterpreting what you said, I > would like to ask you to re-take the data, but with only one flasher > board flashing at a time. The board should be flashing at max > brightness, I suppose. I also suppose it might be useful to do multiple > such runs, running a different individual flasher board each time, but > that is probably asking too much as I know you are very busy... > > Thanks, > Doug > > Mark Krasberg wrote: > > > 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 > >>>>> > >>>> > >>>> > >>> > >> > > > >