Tuesday, October 11, 2011

Sigh Lab

Ray texted me that one of the scintillators is producing pulses 1,000x wider than the other, but I don't understand how that's possible?!?!?  I didn't see that behavior.  Ask him to show me what he is seeing when he gets in.  Aha, turned out one of the scope inputs was set to the wrong impedance (1 Mohm instead of 50 ohm).

Sigh, stupid SciLab ran out of memory again even, when processing only 1/4th of the data file, a mere 2 million lines.  Let's try cutting the file in half again...

Cutting at Wed Oct 05 22:41:00 2011.

The new data file "node0.uart-cut.1st-egth.trnscr" has 931,499 lines.  Changing Scilab script (anal-pulses.sce) to preallocate space for 1,000,000 data records.

In case this is going to work this time, let's generate some summary data.

The length of this (1/8th) run is 3,518,106,163,688 time steps (5 ns each), which is 17,590.53081844 seconds or 293.17551364067 minutes or 4.886258560678 hours.

Start time:  Wed Oct 05 17:47:49 2011 + 629 ms
End time:    Wed Oct 05 22:40:59 2011 + 978 ms

Length of run (according to when data was logged on the server) was thus 5 hours, -7 minutes, 9 seconds, 349 ms, or in other words 293 minutes, 9.349 seconds, i.e., 293.1558167 minutes, or 17,589.349 seconds, so in other words, the server's idea of the length of the run differed from the board's idea of the length of the run by only 1.182 seconds out of ~17,590, or in other words, by only 0.0067% or 67 parts per million.  Not too shabby... Sometime, I might want to figure out what accounts for most of the discrepancy (board clock drift or communication delays), but it's not a priority at the moment.

PMT #1 had 718,080 pulses over the 17,590 secs., for an average pulse rate of 40.82 pps.
PMT #2 had 213,413 pulses over the 17,590 secs., for an average pulse rate of 12.13 pps.

Ray is using the LeCroy scope to collect histogram data for the pulse height in the coincidences.

We are thinking maybe we really should start doing coincidence detection on the board, so that we can lower the thresholds without exhausting our data rate.  I may start working on this code.

Went back and reviewed my notes on this from an earlier blog post.  Started making the changes, but in the context of an "#ifdef FILTER_COINS" preprocessor option, so that we can easily revert to the old version of we have trouble fitting the new code.

When I left, I had just modified pb_add() in pulsebuf.c (in Q:\software_v4\FEDM_ctrl_fw\), and was about to modify pb_get(), which is where most of the work of the new algorithm will be.

The SciLab code is still running; over 11,000 coincidences so far on this dataset...

No comments:

Post a Comment