[time-nuts] Fluke PM6681 triggering

Rex rexa at sonic.net
Sun Jun 5 08:46:05 UTC 2011

Bill and Bruce,

Clearly, fixing the messed up signal is the proper approach. What you 
are missing is that I got a shiney new (for me) expensive hammer and I 
thought that it should be able to drive defective nails. :)

I got an off-list reply that suggested that hold-off affects the counter 
gating -- which either doesn't matter in this totaling app or 
complicates it. He also suggested using the negative slope of the pulse 
to trigger. Doh! The negative slope is more gradual and would affect 
timing accuracy, but that doesn't matter in my counting situation.

Oh, and as reply to the question of more detail on where the signal 
comes from, this is a 1960's CD-700 (civil defense, yellow) gieger 
counter. The signal is the earphone output. In the future I think I'm 
going to make my own circuits to connect to a geiger tube or a 
scintillator/PMT MCA application, but that is even further from playing 
with the nice new counter.

Thanks for the feedback -- any more welcomed.

On 6/5/2011 12:42 AM, Bruce Griffiths wrote:
> A Geiger Muller (GM) tube produces an output pulse as a result of an 
> avalanche discharge in the gas filled tube initiated by the passage of 
> ionising radiation through the tube.
> A high voltage is initially maintained between an outer usually 
> cylindrical electrode and an inner small diameter wire electrode. The 
> discharge current develops a voltage across a resistor in series with 
> the inner electrode. The pulse amplitude is relatively large and 
> little gain is required to drive a speaker.
> Pulse shaping using a suitable differentiating and integrating RC time 
> constants is typically used to shape the pulses and  maximise the SNR 
> of signals from scintillators and proportional counters.
> For Geiger counters the signal is so large that such shaping to 
> maximise SNR isnt usually required.
> Using a non retriggerable monostable to define the deadtime in nuclear 
> counters is relatively common.
> The pulse risetime for a GM tube is relatively slow so that something 
> like a 74HC series monostable should suffice.
> An HCMOS monostable also has the advantage of a high input impedance 
> so that little or no amplification should be necessary,
> Bruce
> WB6BNQ wrote:
>> Hi again Rex,
>> I should have asked these questions in the first place.
>> How are you connecting the Fluke to the geiger counter ?
>> Is this a signal that drives a speaker or some other kind of noise 
>> maker ?
>> What happens if you load that line with some capacitance like 1 uf or 
>> more ?
>> If the capacitance helps you will have to experiment with the value 
>> so as to not
>> completely destroy the pulse shape.  Never played with a geiger 
>> counter so have
>> no real idea how they do the noise making.
>> Bill....WB6BNQ
>> Rex wrote:
>>> I recently picked up a Fluke PM6681 counter (same as a Pendulum 
>>> CNT-81).
>>> Looks like a sweet device.
>>> I was just trying to use it for a not-so-much-timing purpose and was
>>> hoping to find an expert here who might help me with a triggering 
>>> question.
>>> I just set it up to count total pulses, over a 5 min interval, coming
>>> randomly out of a geiger counter. Basically I set it up and it works
>>> except for a subtlety. The pulses out of the geiger counter are not
>>> clean. At a low count rate they have a big glitch on the leading edge.
>>> Here is a picture of the pulse:
>>> http://www.xertech.net/geiger/single.jpg
>>> The glitch causes the count to increment by two on each event except
>>> that when the pulse rate gets high the pulse shape changes causing the
>>> the glitch to smooth out and the peak amplitude to drop, like this:
>>> http://www.xertech.net/geiger/multiple.jpg
>>> If I set the trigger voltage on the counter to just above the glitch
>>> peak I can get proper counts, but finding a sweet spot on the changing
>>> wave shape is not ideal.
>>> I thought I could use the counter's Hold Off feature to get a clean
>>> solution but it isn't working as I expected. Reading the Operator's
>>> Manual I thought that the Hold Off period started at a trigger event 
>>> and
>>> would prevent another trigger event until after the hold-off period. I
>>> thought I could set the trigger level to occur around the middle of the
>>> glitch rise (about 3 volts) and set the hold-off time for 1 uS or more
>>> to prevent a 2nd trigger on the big rise just after the glitch. I tried
>>> hold-off values of 250 nS through 20 uS, but I still see the count
>>> incrementing by two on the glitchy pulses.
>>> I'm wondering if anyone has experience with this counter and can 
>>> tell me
>>> if I have mis-understood the Hold-Off function. Or maybe it has
>>> something to do with me using Total A-B mode. The Op Manual covers a 
>>> lot
>>> of ground, but it isn't the easiest to follow the finesse stuff unless
>>> you happen to need to do exactly what they are showing in an example.

More information about the time-nuts mailing list