Good point - as I noted, Max's circuit started clicking for me with no mods at all, so as you say the capacitance of the tube does provide reasonable smoothing. The tube data diagrams I linked to give tube capacitance as only a few pF.
However, with the low duty cycle 300 Hs power pulses from the transformer, I wonder what would happen to the tube voltage if several ionisations occurred between power "top ups" as would certainly happen with the source in the video. The best info I could find in the tube data gave "dead time" as 100-200 uS for most tubes, impying a maximum count rate of 5000 counts / second - ie more than 10 counts between each 300 Hz power pulse.
I will freely admit I was also influenced by the fact that almost every other schematic I saw had a smoothing cap of a few nF or so. And I'm not keen on re-inventing wheels!
Again, this is a relatively low-cost kit not intended for professional measurements, but Cheney certainly could have improved the design considerably for only a couple of dollars worth of extra parts.
OOPS!! Well spotted my deliberate mistake, Peter :-)! I will provide Max with a corrected schematic to insert if possible. Thanks for that.
As you advised, my highest count rate would have been pretty high, and it was only when it was right near the source that the LED dimmed. Not an easy test to repeat. I went for the cap based on the facts that (a) it worked and (b) the power supply pulses were considerably sharper than the event pulses, so a cap would attenuate them more.
As I said, I think if I was building one from scratch I'd do it a bit differently. One article I saw (think it was somewhere else, not here) suggested using a fluorescent lamp inverter transformer - as it happens I have quite a few of these (I pick up the emergency exit signs at work when they renew them every couple of years!). However they are designed for powering an 8 or 10 W tube and would probably be overkill - size and power wise- for a geiger counter. The Maxim AN ref in the article looks really good. See also comment on ArekZ's post below.
Thanks again Peter for your input - I was also happy that our results were similar (proves I'm not such an idiot!!)
It's nice to see a happy end. 8)
My only comment regards the "strange thing" number 2 - a G-M tube is a high voltage capacitor (with some side effects) and perhaps this is why a smoothing capacitor was omitted in the original design.Also 300Hz is much higher than 900CPM.
David, et al.,
Great work you have done on this project and the documentation and write-up - and the time you spent on it!
I have a few notes and comments:
1) I noticed that your modified schematic (Figure 6) shows R7 and C5 connected not across base-emitter (BE) of Q3, but to the G-M tube "Gnd". Although your text indicates these two components are connected to BE of Q3 - I assume the text is correct? Which means that the G-M tube is only referenced to the positive side of the battery via the speaker-resistor network.
2) I also measured the voltage across the G-M tube with a Fluke DVM a while back, and also got about 70 VDC. Prior to that, I had a friend who had an old Beckman Int'l scope in which we measured 400+ volt charge-up spikes (prior to installing the HV smoothing capacitor).
3) This past weekend I was able to buy an old travel wind-up clock at a flea market, which turned out to be pretty radioactive (w/radium, I presume). When placed directly on the G-M tube, the digital readout on my C6981 kit gave a reading of 700-900 CPM (counts per minute)! I quickly headed for the hills. :-) The LED had no problems keeping up, but I don't have source like in David's video, which probably had CPMs in the 1000's. I also tested a smoke detector source (Americium 241), which gave about 200-300 CPMs.
4) I would also like to give credit to a fellow ham (amateur radio) person who initially suggested a HV smoothing capacitor during our initial debug session together back in March. Given her EE background and intuitive debugging skills, she was instrumental in getting the kit going. I will give her name credit on my PicasaWeb page.
5) Thanks for all those who provided their experiences with their problematic kits. I'm glad some folks got their kits working (better) using the modifications I had. It was good to see that both David and my modifications closely concur based on David's independent investigation of Max's kit.
One further comment here. My solution to the LED ON problem was a 1 Megohm in parallel with a 68pF capacitor, across Q3 Base-Emitter. As in the video, the LED tends to go off at high count rates. Pchow's solution was a lower resistor (330K I think) and no cap. I think his solution might work better at high count rates but by the time I saw it I had already done my test. It would be interesting to redo the test with Peter's mod instead of mine and compare - I have a suspicion that his might work better for high radiation counts - my addition of a cap would tend to kill high freqs. If anyone's in a position to test further, let us know.
A great example of a broad range of engineering skills -- testing, debugging, circuit analysis and creative PCB modification to add the new components as neatly as possible. Very nice work David.
I got a good laugh at the quote from your wife. Mine would've said pretty much the same thing :)
Excellent result. Many thanks for your efforts.
I've been away on business travel for many weeks and dying to get back and bring my Geiger counter back to like. In the mean time I ordered spares and studies every blog entry. Everything is waiting for a free Saturday. Maybe next month!
By the way - TIG welding electrodes, 2% Thoriated tungsten, are a very excellent source. I was just getting ready to capture that video when the kit gave up the ghost!
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.