[Swlug] DIY Geiger counter

[James R. Haigh (+ML.LUG subaddress)]

Alan sent me this off-list but I confirmed he meant to send it to the list, so replying on-list.

At Z+0000=2025-03-15Sat18:28:42, Alan Gray sent:
> Hello James,
> 
> Ceramic disc capacitors are not all equal. I came across the problem years ago when, as a walk-in, customer of a company that supplied one of the University of London colleges they had a problem. My ears pricked up and I took in the generality of a conversation. If you look up wiki "capacitor types" you will find they show two classes; others say three. The difference is largely the dielectric used. Essentially the dielectric constant may not be so constant. It depends on the molecular structure and varies with frequency and temperature. Mica types are very stable, as are class one ceramics. The wiki comments the latter have mostly replaced the former primarily on cost grounds.

    Interesting.  I didn't know that about the dielectrics and the dielectric constant being maybe not so constant at RF.  I'll keep an eye out for mica and/or Class 1 ceramics.

> When you get up to Gigahertz frequencies I am not not sure how much this helps. You may find you have enough capacitance in parallel pcb tracks!

    True.  This type of capacitor is exploited in PCB design and silicon die design.  A pair of power planes (ground plane and voltage source plane) are a particularly good example of this kind of capacitance.  I'm exploiting this in my newest digital electronics projects (currently stalled due to having had to focus on my email problems over the Autumn/Winter, but hoping to return to these projects soon).

    And you get inductance from their length or loop area.  This is mitigated by minimising the width between them, twisting them together, or even having them be coaxial.

> Here are a couple of links you might find useful:-
> Cern-diy-detector <https://physicsopenlab.org/2020/06/15/cern-diy-particle-detector/>

    Oh, okay, so I've just been reading this and it's very interesting.  I've heard of band gap energy before from Jeri Ellsworth in one of her DIY semiconductor fabrication videos, but this article clarifies it even further -- it is the potential energy difference between an electron in orbit and an electron being free, which according to that article is also known as being in the "conduction band", hence the term "band gap".  I have some familiarity with the concepts in this topic, but it is useful to get grasp things with crystal clarity.

    Further down, the article points-out a really key point for Rhys: The 27v or more volts is actually directly-related to the band gap of your crystal and the radiation that you are trying to detect.  As far as I can tell, you have to supply the voltage to make up the difference with the energy of the particles that you want to detect.  You can detect radiation with more energy than that threshold (assuming that your housing does not block it), but never anything with less energy.  I suspected that increasing the supply voltage would help a bit in an ohmic sense, but I didn't realise that this was fundamental to the workings of the various detectors -- so much so as to actually define which frequencies or energies of radiation it can detect.

    You will want to choose a voltage such that the threshold that it can detect is in accordance with the ionisation energy, thus allow you to detect ionising radiation, without detecting any radiation that is not the ionising sort.  For example, the threshold should reject all visible light, infrared, microwaves, & radio waves, as these are not ionising.

    There might be some variation depending on the properties of the crystal/semiconductor's band energy gap, but given that this article mentions the same components that you are using (not just Geiger--Muller tube or other detectors, I suspect that it is going to be necessary to try a voltage source more like 27v.

    I still find that surprising because LEDs emit visible light with voltage drops of only a couple of volts or so.  I would have thought that ionising radiation, with its much greater energy per particle, would have plenty enough energy to exceed the band gap of semiconductors powered by the 5v range, knocking electrons loose and into the conduction band.  Maybe there is an efficiency loss of some kind, like that particles will often glance rather than hurtle into electron shells directly, but I'm not convinced.

    I read so far and then X11 crashed after many months, due to a bug with the selection system.  It happens from time-to-time.  Very annoying.  All of my graphical applications got abruptly killed.  Fortunately, my hundreds of Tmux sessions will be intact, but I will still have to dig them out, as all window manager positions get lost of course when X11 crashes.  Bit of a mess that takes some tidying-up from.  At least I use much less GUI stuff these days.  The bug is possibly related to something called "Parcellite", but I'm not sure.

    Anyway, reading-on, and reading back again, it doesn't give a direct answer to this mystery, but I wonder whether it is to do with the way that these sensors are designed to have large windows that are hundreds of microns across.  If it is the electrical field strength that provides the extra energy to cross the band energy gap, then having a greater length of this gradient of voltage per distance would translate directly into a much greater overall voltage drop for a particular field strength to set the threshold at a particular particle energy.  This makes me wonder whether there are detectors with narrower depletion zones that would not require as high of a voltage as 27v to detect a good range of ionising radiation.

    For example, multiple narrow strips of depletion zone in parallel, or a serpentine depletion zone, could occupy a similar footprint under the same-sized housing window, yet operate at a much lower voltage -- that is what I suspect, anyway.  It'll be interesting to know whether such alternatives exist and are commercially-available and affordable.  If so, then it might still be preferable to order a lower-voltage sensor rather than have the complexity and risk of a boost convertor in the circuit -- these can fail to very high voltages that destroy most of your other components on the board, or even what's connected to it.  Boost convertors are not fail-safe, unlike buck convertors which are much better.

> Diy-particle-detector <https://github.com/ozel/DIY_particle_detector>

    Another excellent find, Alan! :-D  Okay, so this design does not seem to have a boost convertor, and yet it runs off only 9v, so clearly there are ways to evade the 27v, which seems excessively high for a handheld device by today's standards.  It would be really good if the boost convertor can be avoided completely. :-)

    It talks about how to do the energy calibration "below & in the paper".  I didn't see it below, and I'm not sure whether DOI.org is willing to give the PDF without a fuss...  Actually redirects to MDPI.com -- and no, its download button is refusing to give me anything, and I can't see any URL to a PDF file on that button, either. :-(

    They have an image there of what the pulses should look like (highlighted in red) if you see them on your oscilloscope -- a sharp dropped followed by a gradual decay, like I expected.  That is the sort of thing that you can get really excited about if/when you see it! :-D  The little tins as EMI-shielded and light-proof project boxes look really nice. :-D

    Also, having the 2 variants so that you can tell the difference between alpha and beta is really nice as well.  Okay, so these photodiodes are apparently too small to detect gamma -- but that's okay, because just detecting alpha and beta is enough to cover any really fallout event.  I can't imagine a fallout event that produces gamma but nothing else at all.  Also, for the same reasons, gamma actually does not intact that much with the human body -- most of it passes straight through us, generally only being most dangerous in very high doses like near a nuclear bomb blast, or some kind of long-term exposure to it, or if atoms in our DNA or RNA decay faster than those important molecules can be repaired.

    Btw., this reminds me: There is another form of radiation other than alpha, beta, gamma, & neutron -- neutrino radiation.  But it is irrelevant here because it passes through almost everything, including entire planets, huge amounts of it have been calculated to be radiating from the sun right through us and right through Earth, barely interacting with anything.  Sort of like ghost particles -- even leading-edge researchers have not had much luck detecting it, even with very large-scale experiments, according to a documentary that I watched as a child.  But being so ghostly and inert, it does not need detecting because it is harmless.  Not worth considering beyond a curiosity.  It has no relevance to detecting radioactive fallout and environmental health.

> Hackaday-radiation-sensor <https://hackaday.io/project/181032-nuclear-radiation-sensor-with-photodiode-detector>

    Can't see much of this -- PDF has no link on it again.  Can't see any way to download "Circuit.pdf".

> Measure-gamma-rays-with-a-photodiode <https://www.diyaudio.com/community/attachments/radiaton-detector-pdf.1197235/>

    Okay, good -- this one downloaded an actual PDF file! :-D  I'll have a read later, but I will send this now to reduce latency for Rhys, who might not have seen any of this yet seeing as your original email was accidentally sent off-list.

> Note: the BPW34 is electrically similar to the BPX61. Remember: the sensing crystal is hygroscopic if exposed.

    Exposed to what?

> Just as a test I have attached a small (20,529 bytes) svg file to see what happens.

    Well the test missed the list server, but I can tell you that yes your email would have not needed any moderation because it was below the list's 38KB email size limit.

> The Inkscape program is widely available and worth a try.

    I used to use it loads for different purposes.  Problem is that it is graphical, so for me I have a great deal more overhead in using it.  If I can produce an ASCII-art diagram in a tenth of the time, I tend to prefer this.

    Before the pandemic, I came up with a different technique for producing schematics that is less overhead than Inkscape would be, but it is still more overhead that ASCII-art, so for casual sketches, I don't feel like snagging my OCD-perfectionism on graphical details that don't matter for a diagram that will soon be forgotten about.

> Apologies for my mediocre artistic skills. It could be made smaller by removing the line of symbols at the top. They are useful for initial creation, but are not needed when you send.

> [electronic-circuit.svg  image/svg+xml (27753 bytes)]

    A Sziklai Pair augmented with a base--emitter resistor on the 2nd transistor to improve switch-off performance.

    I've attached it to this email so that this email can be the test email, even though I know it will definitely be less than 38KB, and also to share with the list that which you intended to send to the list.

> Regards
> Alan Gray
> 
> On 14/03/2025 18:23, James R. Haigh (+ML.LUG subaddress) wrote:
> [...]

At Z+0000=2025-03-15Sat23:47:16, James R. Haigh (+ML.LUG subaddress) sent:
> At Z+0000=2025-03-15Sat18:28:42, Alan Gray sent:
> > [...]
> > Just as a test I have attached a small (20,529 bytes) svg file to see what happens.  
> 
>     Hi Alan, were you aiming to stay below the list's tiny 38KB limit, but then accidentally sent it off-list?  This comment makes me wonder whether you meant to send it to the list, in wish case I'll reply to the list -- or otherwise let me know.
> 
>     Thanks for your email, it is very interesting. :-)
> 
> Kind regards,
> James.
> -- 
> [...]

At Z+0000=2025-03-16Sun05:11:27, Alan Gray sent:
> Brain failure! Yes it was meant to be on-list.

    Okay, it is now. :-)

>  It was not clear to me if attachments could be used. At the moment diagrams are fine on my desktop, but garbage on my android phone that I use for routine reading.

    They can, but only upto 38KB without moderation.  That said, both Rhys and I have slightly exceeded this limit a few times, and someone allows it through within about a day, so that's good.  Thank you moderator whoever you are! :-)

    I used to have problems with SVG on Android.  I found an SVG viewer on F-Droid.  These days I don't use smartphones at all, and I am glad of it.  Android was getting increasingly annoying -- far from the promise of eventually getting better.

    I much prefer desktop GNU+Linux, on a laptop with a proper keyboard, no newer than 2009 or so.  Emailing you all from an X200s, circa 16 years old! :-D

> I just thought the svg's might be useful for small diagrams as you have recently used between Rhys and yourself.

    Do you know of any good workflow where I can edit the SVG by hand in Vim, but see it update easily, and also see validation issues in a terminal or something?  Basically minimising the GUI aspects of working on a graphical image.

    For ASCII-art, and other monospace semigraphics, there is also Aewan, which, just like Vim, can run entirely on a virtual terminal without the need for any X11 session, but of course, just as easily used in a terminal emulator such as Mate Terminal.  I bridge the 2 worlds using Tmux.  I have not yet used Aewan much because of it being the Gimp of the TUI world with lots of bells & whistles, but I came to it relatively late in the game only a couple of years ago or so, so I still find it easier to manipulate semigraphical text in Vim rather than get used to Aewan, but that may change.  Both are great TUI applications. :-)

    I mainly use TUI almost entirely.  Claws Mail being a big exception, but I have already been dabbling with Mutt, recently.  I've sent all of my test emails from my new Postfix server using Mutt.  I'm having a few issues with Mutt itself, though.  Particularly having only a single "folder", whereas in Claws Mail I can browse between multiple, including Inbox, Sent, Draft, Queue, or any that I create.  Mutt seems to be making like an Mbox for sent and draft emails, whereas I just want to use Maildir.

    Anyway, I've gone on tangents from tangents from tangents here.  I'll return to Rhys's emails now.

> Alan Gray 
> 
> On 15 March 2025 23:47:16 GMT, "James R. Haigh (+ML.LUG subaddress)" <JRHaigh+ML.LUG at Runbox.com> wrote:
> [...]

    Btw., I was planning to stay-tuned for writing emails yesterday about Rhys's ionising radiation detector, but instead, more bad news about my walnut tree (stump) -- I discovered yesterday that my walnut tree stump has since been painted with a thick, gooey, brown tar, almost certainly some kind of poison applied to the stump by my idiot neighbour who took a chainsaw to it on Tuesday. :-(  On Tuesday, he claimed that he "didn't know", but I have since discovered that he did know, and I know for certain that he definitely did know prior to applying the poison because the poison was not there on Tuesday -- he has only done that /since/ he supposedly "found out" that the tree was mine.  Infuriating! >:-(

    But this time I did not nearly drown in the bathtub all night, and returned to positive things like this thread about ionising radiation detectors much more quickly. :-)  I replied to Rhys's emails first that had come through by then because I had more direct things to say about those that would hopefully reduce latency for him on his 3-day weekend.

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: electronic-circuit.svg
Type: image/svg+xml
Size: 20529 bytes
Desc: not available
URL: <http://mailman.lug.org.uk/pipermail/swlug/attachments/20250317/b8e911d8/attachment-0001.svg>
-------------- 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/20250317/b8e911d8/attachment-0001.sig>