Spatter Analysis

Let's see, yesterday I was not in, b/c I had presentations over at COE all afternoon.  The COSMICi group's presentation is scheduled for this afternoon at 4:30 pm in room A223, and I will leave here to go to it at about 4:00 pm.  Actually, I need to leave a little bit earlier, to get the rubrics ready.

Monday, Darryl and David came in and we talked a little about the bad DAC problem, and probed its output pin (pin 7) directly with the multimeter to verify that the problem was not in the pin-pad connection (if it had been, I don't know if that would have made it any easier to fix, but I thought we should at least check).

Probably, what we need to do at this point is just to shift DACs #3-6 up to positions 2-5, replace the comparator outputs from DAC #2 with Vcc, and modify the firmware to skip DAC #2 when configuring the voltage ladder.  We will only have 5 levels, but we rarely cross all 6 as it is.  We can space the levels out to cover the same range.  It is less information than we had originally, sure, but not too bad.  I just hope we don't lose another one!

In case the problem was caused by water drips from the cooling system, we will hereby institute a policy of only running the fan (not the thermoelectric plate) to eliminate condensation.  If it turns out that the plate absolutely has to be used, we will minimize the chance of drips by only running for a few minutes at a time for short tests.  No more long overnight runs with aggressive cooling until we get a better cooling system.

 We also peered at the board with the magnifying glass, and there is clear residue, probably from evaporated water dripped down from the cooling plate.  Dr. Ordonez suggested during his visit last week that we turn the system upside-down, but we will still need some mechanical support to do that.  Also, that is not a permanent solution b/c we don't really want water dripping onto the carpet & people in the classroom in CLC.  If a cold plate is still used in the new design, then either the cold side has to be sealed from contact with the air, or else there has to be some kind of tray to catch the drips.

In other news:  I am giving a graduate seminar in the ECE department at 4:15 pm next Tuesday (in A337) to survey issues in hardware-software codesign (controlling custom hardware from C) that are exemplified by the work that was done in this project on the FEDM board.  All COSMICi computer engineering students (and all Senior Design students in general) should attend.

Dead DAC Diagnostic

Today, I want to see if I can narrow down why the dead DAC (#2) is not working.  I want to probe its pins directly, to see if maybe the problem is with the connection between the IC and its pads.

First step: Find the DAC datasheet.  To do that, I really need to clean up my desk papers.

A little later, the EE student (Samad) is going to come by, and we will start working on gathering information on the voltage requirement / current draw of various system components.   Cleaning my desk papers will be helpful for that as well.

He's here, we're starting to go through some of the power-related stuff stuff.  Some notes:

• The PMT base is rated at 250 mW @ 12Vdc = 20.8 mA (quiescent power).  Ray said he could pick up some more barrel connectors at Fouraker's, so that we could do a direct measurement with the paddles connected.  We'll wait to try that measurement until he can do that.
  
  
• We directly measured the power consumption of the Wi-Fi board by powering it from the Keithley sourcemeter through J8 pin 3.  It typically consumes at most about 300 mA at high data rates.  It would be a good idea though to inflate this figure to (say) 500 mA in case the board uses more power when located farther from the base station (currently it is less than 3 feet away).  A limit of 500 is appropriate also because the on-board voltage regulator U2 (which generates the +3.3V logic level) can handle at most 500 mA anyway.
  
• We spent a while looking for information on the voltages and currents drawn by the DE3 board (for the GPS app), but the provided docs are frustratingly ambiguous on this point.  We think it is probably using at most just the +12V, +5V, and +3.3V lines from the external power supply, but we don't know the actual current draw on each.  We could supply these three using the Agilent and Keithley supplies and measure them that way.  However, we decided that rather than doing an experiment today to measure this, we would postpone it to Monday afternoon, when we will have more time to set it up.
  

Meet & Greet

Today (Tue.) at 3:00 pm in 206, we will (finally) have our first meeting with the entire (we hope) COSMICi team, including all ECE & ME students, and all 3 advisors (myself, Dr. O'Neal & Dr. Ordonez).

Dr. O'Neal has to leave the meeting before 3:30 pm to give a Physics dept. seminar on the COSMICi project, but the rest of us can continue.

Future advising meetings (the ME ones, at least) can be over in the College of Engineering, for more convenience to Dr. Ordonez.

We had the meeting; it started a little late b/c we were waiting for more of the students to show up.  Everyone did arrive eventually.  I went over some administrative issues, then gave a brief overview of the project on the whiteboard, and then I showed the lab and the equipment to the ME group members who hadn't seen it yet (George Chakhtoura & Dr. Ordonez).  The meeting ended before 4:30.

The EE student (Samad) is going to come back around 3:00 pm tomorrow (Wed.) to discuss requirements for the power supplies in more detail - we will start doing some measurements of current drawn by different system components whose total power draw is not yet known.  I also discussed with him about the need for us to investigate what's in the ceiling at CLC in terms of power, and determine whether battery power is feasible for the stage 1 sensor nodes, at least.  If we draw AC power from the ceiling, then a professional electrician should probably be contracted to install any needed ceiling outlets.

This reminds me, I haven't yet heard from our contact at the Challenger center; Ray and I should probably go down there sometime and look him up or find out who else to talk to.

His Toe-Gram

A thought for today: Plot a histogram of the distribution of coincidence delays.  This is a good sanity check to see if it's consistent with the known angular distribution of showers.  We should expect to see more from the zenith (near the E-W-zenith plane) than from near the N-S axis.  Ray says he might show the graph in his astronomy class.

Also: Run a hodoscope configuration with perpendicular paddles to reduce slewing.  Picture of that setup (jury-rigged, as usual):

This will (we think) give us a picture of coincidences due to (mostly) single-particle events passing (more or less) vertically through the far ends of both paddles, giving us (perhaps) a clearer picture of the difference in gain of the two paddles.  At this depth inside the building (away from window, under the 5th floor and the roof), the vertical cosmics should be mostly muons.

Whoops, for some reason, threshold 2 seems to be messed up today.  It's reading 70 mV when it is supposed to be 2.000V.  Perhaps a water drip caused a voltage surge that zapped the DAC #2 chip?  Not sure what to do here.  I've tried re-loading a couple different versions of the gelware; it makes no difference.  Could try cleaning the pads on that IC, in case there is some residue causing a short.  If all else fails, we can route around it, just use the other 5 DACs.  It would be nice to first know why it's failing though.

Also need to set up Neutralino accounts for the students.  Need to remember to take pictures of them for the site next time they're here.

Spent a little while inspecting the board.  There is a fair amount of residue on the board, perhaps a result of drips from the cooling system.  We should probably look into washing off the board, in some appropriate way.  Ray says Radio Shack might have an electronics wash spray which we should try.

Anyway, here is a plot of the histogram of absolute time deltas from the run a couple of weeks ago.  The number of events for deltas other than 0 is halved to compensate for the fact that only half of the data comes from positive vs. negative deltas.  (We haven't yet explicitly separated out the data to check for any North/South asymmetry.)

From run of Sep. 6th-7th:  This shows how the number of coincidence events falls off with an increase in the (binned) absolute time difference between arrivals at the two detectors.  (Counts other than at delta=0 have been halved to compensate for the fact that data from positive and negative values of delta are thrown together.)

That's all for tonight.

Reading my Hodoscope

My Scilab run finished overnight.  In the stacked (hodoscope) configuration from the overnight run earlier in the week, we got 16,325 "concidences."  False-coincidences (the range for these is still set at 30 to 50 ns) were only 2, so I think we can be confident that almost all of the 16,325 coincidences were "real" (i.e., the result of a particle or particle-shower passing through both detectors).

As a percentage of total pulse count:  The coincidences accounted for 16,325/110,912 = 14.7% of events on PMT1, and 16,325/280,036 = 5.83% of events on PMT2.

The run turns out to have had some interesting variation in the total pulse rate over the course of the run:

Pulse rates from two PMTs hodoscope configuration, from 5:15 pm on Mon. 9/12 to 11:06 am on Tue. 9/13.  Horizontal axis:  Minute in run.  Vertical axis:  Pulses in that minute.  Lower curve: PMT1; Middle curve: PMT2; Upper curve: Sum.

It could possibly be related to ambient light (since this was an overnight run), but I'm unsure whether the shape of the variation really fits with that hypothesis.  Too bad we don't have a light meter that could record the room light levels independently.  Interestingly, the detector with the higher pulse rate also had more (candidate) apparent diurnal variation.  Possibly if we just sealed the gun case better (or threw a blanket over it), the pulse rate would be more in line with the other detector.  I should probably do a test where we see if switching the lights on & off affects it.

Garbage In, Garbage Out

Arrived this morning to find lots of garbage output and multiple automatic restarts in the UART log.  Water drips?  Overheating?  This just goes to show our need for a better cooling solution!

The first crash was at 12:18 pm (shortly after noon), after 280,036 pulses on PMT2, and 110,912 pulses on PMT1.  However, there was a good bit of garbage output even before then.  The last clean data was at 11:06 am at pulse 279,719 (PMT2) and 110,787 (PMT1).  The run started at 5:15 pm the night before.  Thus the run length was 17 hours 49 minutes = 1,069 minutes; the average pulse rate was 261.96 ppm on PMT1 and 103.75 ppm on PMT2.

Now doing a data-analysis run (anal-pulses.sce) to check the coincidence count.  This experiment was performed with the two paddles stacked on top of each other, so we are expecting a high count.  Indeed, it is looking like the count will be high.

Emailed the Senior Design team to get them in here.  Darryl and David are re-hired to help train the new students.  Also added Dr. Ordonez to the Blackboard group and emailed him asking for a meeting time.

Staying Grounded

Still having trouble with the 2nd input-capture datapath (channel #1) today.  I'm routing the comparator outputs to the B2 bus on the scope, so we can see if they're working right, at least.

In our full data run from last week, we got 431 coincidences within 50 ns, and only 12 of them were identifiable "false coincidences" of 30 ns time difference or larger.  The distribution of time differences among the false coincidences was:

30 ns:  ####
35 ns:  #####
40 ns:  ##
45 ns:
50 ns:  #

Most of them were clustered at the low end of the scale, so these are unlikely to be purely accidental coincidences.  Some theories:

1. They represent individual particle pairs in occasional thicker-than-normal EAS pancakes, at least 10-20 ns thick, or perhaps outliers from a normal-thickness pancake.
   
2. Maybe there are multiple showers occurring close together in time?
   
3. There is some unexpected occasional source of up to +/- 20 ns inaccuracy in our time measurements.

By the way, here is the graph of the average pulse rates in that data set (extended a few hours from last time):

Aha, looking at the comparator outputs showed me the problem:  I never properly grounded the AC input node on PMT2; it was just floating.  It was supposed to be tied to the +2.5V supply so that the negative excursions of the pulses would take it past the DAC levels.  We were just lucky that it worked at all before!  I placed a jumper bridge/sheath across J69, and this fixes the problem.

Anyway, let's look at the coincidences with anomolously large time differences in a little more detail.  Here's the first one:

Coincidence #9 with delta = 30 ns:

    3.596D+11    3545.    2.    1.    0.    6.    0.    0.    0.    0.    0.    0.    0.    0.    0.    0.    0. 
    3.596D+11    26549.    1.    1.    0.    1.    0.    0.    0.    0.    0.    0.    0.    0.    0.    0.    0. 

Here are the raw data lines:

Tue Sep 06 17:34:01 2011 + 528 ms: < PULSE,2,3545,359642909738,1,(0,6)
Tue Sep 06 17:34:01 2011 + 527 ms: < PULSE,1,26549,359642909744,1,(0,1)

Not too noteworthy.

Coincidence #10 with delta = 30 ns:

    3.840D+11    3784.    2.    2.    0.    1.    2.    4.    0.    0.    0.    0.    0.    0.    0.    0.    0. 
    3.840D+11    28326.    1.    2.    0.    3.    1.    6.    0.    0.    0.    0.    0.    0.    0.    0.    0. 

These at least are bigger (2-threshold) pulses.