[Swlug] DIY Geiger counter

Fri Mar 7 13:09:27 UTC 2025

Hi Rhys,

At Z+0000=2025-03-06Thu16:33:23, Rhys Sage via Swlug sent:
> I'm in the middle of a project - to build a Geiger counter. It's a fun project so far.

    I'm glad to hear of this.  I have been thinking of getting a Geiger counter, especially now with threats of nukes in the news.

> I have all the bits I need (I think) but as with all projects there's a lot of experimentation and changes made on the fly. 
> 
> I'm using a Thalium-doped Cesium Iodide crystal in combination with a BPX61 photo diode. For those that don't know- the BPX61 is slightly more sensitive to green light. The crystal emits blue/green light when struck by gamma radiation. Whether it emits light when struck by Alpha, Beta or X-Ray, I don't know. I do know there are other crystals more suited to those.

    There's also neutron radiation which makes other materials radioactive (and full of random impurities that cause structural weakness -- that's why nuclear power stations have to be decommissioned and become low-grade nuclear waste) -- but because of that, wherever you have neutron radiation you also have alpha, beta, & gamma which you can detect more easily I think because they are not electrically-neutral.  So in terms of detecting radioactive fallout and contaminated water & food, I think it only matters whether you can detect alpha, beta, & gamma.

> The BPX61 output will feed into an OPA134PA amplifier and then that will in turn feed into a microcontroller. Given that the events generated by radioactive decay are very brief, would microcontroller speed make much difference?

    I'm thinking that it would be better to have a capacitor hold circuit consisting of a diode on the input to a capacitor (in parallel) and with a resistor (also in parallel) to slowly sink the charge on the capacitor.  So there's an RC subcircuit in there; it's also how an AM receiver/demodulator works, iirc., the bit before it gets amplified, if it's amplified at all.

    The effect of this subcircuit would mean that each pulse raises the charge and thus voltage on the capacitor through the diode, which then decays exponentially due to the RC subcircuit.  This would give you a lot more time to sample the voltage on the capacitor using one of the analogue inputs of your microcontroller of choice, or any other ADC.  Or even have a purely analogue device where an LED and/or buzzer is controlled by the voltage on the capacitor.  You would choose values for C and R such that the decay rate is slow enough for your sample rate.  In the all-analogue case, you would choose the decay rate such that you get a "pip" of sound and a flash of light that is long enough for human perception to notice.

    I would try placing this AM-like subcircuit before your opamp, because your opamp probably won't have enough bandwidth for a pulse that may be on the scale of tens of nanoseconds.  But then again, if the spread-out pulse is too weak to amplify without a lot of noise, then actually it might be best to get a better opamp that feeds into the AM-like subcircuit.  I'm also wondering whether spreading the pulse a little bit before amplification and also spreading it out some more after amplification might be helpful if the crystal output is very weak.  And then I'm wondering whether the before-amplification spreading-out you get for free as part of the opamp bandwidth limitation, or whether the behaviour of it is not as good.  But diodes, resistors, small capacitors are pennies, so if a few more of those allows the use of a cheap audio opamp that you have to hand, then it's at least worth considering.

(schematic diagram to be viewed in any monospace font)

                          +
                          |
CRYSTAL --|>|--o----o--- AMP ---|>|--o----o-- ADC
               |    |     |          |    |
               |    >     |          |    >
              ---   <     |         ---   <
              ---   >     |         ---   >
               |    <     |          |    <
               |    |     |          |    |
      - -------o----o-----o----------o----o--

    An advantage of this over Terry John's idea of using a hardware digital counter is that it would be much better at accounting for "overlapping pulses", because you are not ignoring the analogue value of the pulses stacking-up.  A hardware binary counter, such as one from the 74HC-series (I'm very familiar with 74HC191, for example), might get "stuck" in the event that you have such a high wave of pulses that you get stuck in the high state, then on the next second, you reset it back to zero, and it gets stuck at zero, when in fact it is quite the opposite.

    Then again, a decoupling capacitor might be a way to force the pulses to be shorter such that you would pretty much guarantee to get a count per pulse event, but then there is also the problem of counter wrapping.  You would want to disable the wrap feature by connecting the last carry to the count-disable of all the counter ICs in the cascade, so that any reading that is at its maximum value represents "out-of-range".

    Another problem is that the irregular chain of pulses is input to the counter circuitry on the CLK input, which has some expectations about minimum pulse time in the datasheets.  Clock pulses need to be long enough to propagate to all stages in the cascade (even in the mode that avoids ripple in the output, in fact, I would say especially in that mode), so if a clock pulse is not long enough during a carry, it may be that one stage gets the clock signal and wraps, but the next stage does not get the clock signal and fails to count the carry, which being a more significant stage could result in a big discrepancy.  So you would still need something on the input, possibly involving a 555 timer or anything with Schmitt-trigger inputs (e.g. 74HC14) with a capacitor-regulated hysteresis circuit, to ensure that pulses are never too short for the counters to count properly.  This would not be a problem to measure the Hertz of a clean square wave or even sine wave, but definitely a problem here.

    You then also have to interface the counters to your microcontroller via a lot of digital pins, which could be a lot messier than a single analogue pin, and then you have to orchestrate the resets and holds to ensure that none of the stages count or carry while you are reading them.

    So even with the hardware counters, you would need some extra components, and possibly several of the counters in cascade to accumulate enough counter bits for a decent range.  The analogue input stage idea above requires fewer and cheaper components and I reckon that it would be a lot easier to "get right".  The fact that I could be bothered to do a draft of it in ASCII-art owes to its simplicity.  I'm not saying that hardware counters are not also simple in the right context, but Geiger counter pulses, the way that they can overlap, are actually more of an analogue matter, so it makes a lot more sense to me to have an analogue input stage based upon the principles of an AM radio (receiver/demodulator), which is a circuit that I learnt about and built at about the age of 10 (both without and with amplification).

    Also, if you get the hardware counters wrong in this case with erratic clock input, they might look like they are working most of the time but then when radiation levels increase they might start jumping by huge amounts due to carry failures (both ways, depending on which stage missed a short clock signal), and it would be difficult to correct this in software, because all this would be happening much faster than your microcontroller's sample rate.

    Whereas, the kind of probably that you might get if you get the analogue input stage wrong is some kind of distortion, which would become apparent if you calibrate it, and you could correct this in software by running each analogue reading through some function that models the inverse of the distortion.  You can also filter some analogue noise out digitally as well, so again, it is easier to get this right, I think.  There are fewer ways for it to go wrong and they are easier to correct for.  As well as being fewer and cheaper components.

> I could use an ATTiny13/ATTiny85 or something small like a micro RP2040 or an ESP32 C3 Super Mini.

    I guess it depends on how much data you want out of it.  Reading Alan Gray's comment, if you can sample fast enough to detect the difference between 20ns, 680ns, & 3340ns pulses, you might be able to detect the difference between gamma, beta, & alpha radiation.  If like me you just want to know whether there is any kind of danger here, then blending all that into 1 using an AM-like circuit like above is fine, and you can use a slow microcontroller to sample -- whatever is cheap, old, available, scavenged, or that you are familiar with programming-wise.

    If you do want to detect differentially between gamma, beta, & gamma, then an accurate way to do that might be to have different crystals/sensors that respond differently, and then digitally difference the readings between them to eliminate the "crosstalks" if you like between the different types of radiation and the tests that respond most sensitively to them.  I think it would be a simple case of simultaneous equations, which you could solve digitally using a matrix method, i.e. Linear Algebra.  Gaussian Elimination springs to mind.  But that would require more sensors and would add a lot of complexity to the design, so probably a bad idea for an initial attempt at this.

> With a regular Geiger counter,does the system store the events somehow or does it just rely upon measuring maximum pulses when a pulse happens during a sampling period?

    The ones that I remember using at school in Physics circa 2007 was purely analogue in that all it did is beeped briefly upon each event -- a short "pip" sound.  I don't remember it having any actual counter or whether we had to count the pips manually.  I remember them being light blue with a flat bit on one side, on the end of a cable.  Hmm, I now have a vague recollection that these plugged-into a counter unit with red 7-segment digits that just counted up from zero, with a button to reset the counter -- but being a dearer unit back then, was probably only seen in a class demonstration.  But this was nearly 2 decades ago so my memory of it is vague.  It may have also had a 2nd display for counts per second (aka. Becquerel/Hertz), and if so, probably also a "hold" button/switch because definitely a lot of other digital meters in the Physics Lab had hold buttons -- I've seen the hold function on 1980s digital equipment or sometimes even older.

    But why is it useful to know what a regular Geiger counter does?  What do you intend to achieve with it?  Do you want to be able to test whether something is safe for human consumption?  In which case your system may not need to store anything -- simple beeps would be enough, and you can do that entirely in analogue.  Or maybe you just want a Becquerel reading so you only store the count for a second, or use an exponentially-damped average stored on the capacitors in the AM-like subcircuits above.

    Or do you want to make something more like a weather station that can log the radioactivity of rain, and email you the results daily or hourly, and produce graphs over weeks, months, years, etc.?  In that case you do want to store the Becquerel counts as a log of them, similar to how you would log network activity, wind speed, or whatever else.

    I'm interested to see where you go with this.

Kind regards,
James.
-- 
Wealth doesn't bring happiness, but poverty brings sadness.
Sent from Debian with Claws Mail, using email subaddressing as an alternative to error-prone heuristical spam filtering.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.lug.org.uk/pipermail/swlug/attachments/20250307/76afbcea/attachment.sig>