Mossbauer Repair

Quirks, Repairs and Other Notes

The Count Rate Discrepancy Between the DAQ and the Ortec 994 Counter

The LabVIEW program that reads data from the DAQ reports count rates of only about 120 cps or so, even when the Co 57 source is positioned extremely close to the detector. Meanwhile, the Ortec 994 counter module may report count rates of 500, 1000, or greater counts per second, despite the fact that both components are triggered by the same SCA output signal. Here is what I have found relating to this discrepancy:

Instead of using the SCA out signal as the DAQ trigger in channel PFI0, I substituted a 2Vpp, 1V DC offset, square wave function generator signal. (Two volts is around what the DAQ needed to trigger.) With a 100Hz trigger signal, the LabVIEW program reports 100 cps, as expected. With a 300 Hz trigger signal, LabVIEW reported 296 cps. But at 500 and 600 Hz, LabVIEW reported only 326 and 334 cps, respectively. So, the processing time in the LabVIEW program (likely from writing copious data to an array, and then using only the first element of that array) does eventually limit the count rate somewhere around 300 cps. But since the actual data collection setup only experiences less than half of that, the LabVIEW program isn't the source of the discrepancy.

From the above investigation, I know that the DAQ needs to see the rising edge of a trigger signal with an amplitude somewhere around (at least) 2 V in order to trigger. The counter module (look up spec sheet online) triggers based on what threshold voltage is selected. The 994 has a 25-turn trimpot that should adjust the threshold voltage between 100mv and 9.5V.

The SCA output signal used as the trigger signal has about a 200mV offset between zero and its baseline noise. When

Reflections The counter module seems to be very sensitive to reflections. When the detector is at a distance where the LabVIEW program reports ~40cps, the count rate on the 994 counter is largely dependent on how the input signal is (or isn't) teed and is (or isn't) terminated.

• When the SCA output is connected directly to the 994 (isn't teed at either module, doesn't connect to the DAQ at all), and has no terminator, the 994 reports ~160 cps.

• When the SCA output is connected directly to the 994 and does have a terminator, the 994 reports about 45 - 50 cps.

• When the SCA output is teed (one side goes to the DAQ, one side goes to the 994) and there are terminators at both the DAQ and the 994, the 994 reports ~95 cps.

• When the SCA output is teed (one side goes to the DAQ, one side goes to the 994) and there is a terminator at the DAQ only, the 994 reports ~170 - 200 cps.

• When the SCA output is teed (one side goes to the DAQ, one side goes to the 994) and there is a terminator at the 994 only, the 994 reports ~90 cps.

Random Notes

The 550 SCA doesn't seem to work well above about 7.6 V. If you adjust the window center beyond this point, the count rate almost instantly drops to zero - it's a very precipitous cutoff. Therefore, watch the gain setting on the PX2T, since if this setting is too high (>5 or so), the 14.4 keV peak ends up beyond the cutoff.

The RTD (Rise Time Discriminator) setting on the PX2T (see XR-100CR manual, p. 10) allows only pulses corresponding to "good" events to be output. Leave the RTD on.

The Velocity Range setting on the Driver = generally on either the .1 or .2 setting. Open for discussion...

The 'Fidelity' setting on the Driver is extremely touchy. There appear to be several regions that produce good clean triangle waves, and the rest of the range is garbage. It has to be adjusted manually while looking at the signal on a scope. The 'Velocity Multiplier' on the Driver is set to '6' and I don't dare touch it.

A Correction Factor for the Imperfect Triangle Wave Velocity Signal?

Once the Fidelity setting has been adjusted so that the resulting triangle wave is as clean as possible, one can still notice that the wave isn't perfect. Specifically, it has something of a 'shark-fin' tilt to it, but this effect is very, very subtle when the fidelity is properly adjusted. Any imperfections in the triangle wave mean that the sample will be bombarded with relatively more photons of a particular energy - and not equal amounts of all photon energies in the range - which will distort the data collected. How can we see how good the triangle wave is, or how linear the acceleration is?

The velocity triangle wave has a period of 14 Hz (which can be measured with the scope, and it's the reference frequency input into the Driver). If we sample the velocity periodically and with a frequency that is a multiple of 14 Hz, we will measure the same velocities over and over again, each period. If we sample at 140 Hz, we should measure 10 different velocities over the course of one triangle wave period, and then measure those same 10 again and again. This gives us a histogram that looks like this:

Now, if this WAS a perfect triangle wave, all of those peaks in the histogram (which do actually contain the same numbers of counts) should be evenly spaced, indicating linear acceleration. Since this ISN'T a perfect triangle wave, we expect the histogram to have areas where the peaks are close together (where the acceleration was less) and areas where the peaks are further apart (where the source accelerated quickly).

Use Origin (multiple peak fit, above) to find all the peak centers and uncertainties. Then using arbitrary time units (1 - 10, say), plot the data in LSQFit. It looks very linear, but the residual plots show that there is clearly a non-linear trend in the acceleration.