Geiger Counter

Description

This project started back in 2011 in a different form. I was curious whether the background radiation levels were going to increase as a result of the Fukushima meltdown. I bought a low cost Geiger counter kit and built it. The results were pretty disappointing, It was closer to a random number generator than an instrument. The power supply design was so poor that it collapsed completely when the tube conducted, then the switching supply transitions resulted in output counts as the supply recovered. It went in a box until the Fall of 2018, when I had time to design one of my own. The new design has a local LCD display and a serial data output to allow for long term data acquisition, which is the main reason I want this device. I also added a "time between counts" output packet in the normally periodic serial data stream. Using this time value might be a good source of entropy for random number generation.

Details

As you can see from the picture of the testbench for this project, it is buillt in several smaller blocks. I have been building small circuits for a while, as a chance to play with them and learn about better PCB layout techniques. This also results in having small building blocks to create larger projects from. This method also works well for incorporating manufacturers eval boards into a project. Because this project uses high enough voltage to destroy digital boards and tools, I put all of the boards on a metal breadboard setup to keep them from floating around and shorting together. Since this project is designed to go into a fixed location data acquisition system, there is no reason to build all the modules on a single PCB, so it will stay in this format. The completed system configuration will go into a weatherproof polycarbonate box, and the metal baseplate to mount all of the boards to is fabricated.

The modules used are:

1) HV Power supply and Geiger Mueller tube analog stuff.

2) Low pass digital filter.

3) MCU Board.

4) LCD Display and serial backpack.

5) Incoming power filter and pre-regulator board.

6) RS422 driver. May or may not incorporate.

All of the purple (OSHPark) boards in the picture are previous or current projects. Schematics for all of these boards are in the files section.

The Power Supply was the first block built for this project. I wanted a (sort of) high voltage power supply that I could use for other stuff like playing with Nixie tubes or EL wire in addition to this Geiger counter project. I picked the Linear Tech LT3757 chip, running in flyback mode. The output voltage from this circuit is adjustable from about 150VDC to about 425VDC. I have played with driving Nixie tubes with this supply, and it works well in this role.

My first iteration of the power supply board was very close to the LT data sheet design for the LT3757, including the RC snubber on the switch node. Messing with this circuit showed that the snubber was dissipating a noticeable amount of power and had problems with both the resistor and the cap surviving. Replacing the RC snubber with a diode snubber resulted in a much cleaner supply with lower power consumption and less smoke problems.

The Geiger Mueller tube is a metal sleeve (cathode) with a wire (anode) down the center, and it is filled with low pressure gas. When no radiation is being detected, the tube looks like an open circuit from the sleeve to the wire. When a particle of ionizing radiation passes into the tube (through the sleeve side), the gas ionizes and the tube conducts current from the sleeve to the wire. As long as the voltage across the tube is below the "self avalanche" level, the tube will stop conducting after about 30uS. This is an extremely hand-wavey explanation, if you want a better one, see Wikipedia: https://en.wikipedia.org/wiki/Geiger%E2%80%93M%C3%BCller_tube .

There is a 4.5M resistor between the HV power supply output + and the anode of the tube. A voltage divider between the tube cathode and ground gives an output signal to drive the base of a grounded emitter NPN transistor. The collector of the transistor is pulled up to 3.3V through a 4.7K resistor to give a 0 - 3.3V output signal from the tube. This signal is cleaned up with a Schmidt trigger inverter to give a well behaved logic signal output. One of the things that this project highlighted to me is that resistors have a voltage rating as well as a resistance value. Exceeding that voltage rating will cause bad things to happen!

I went through several iterations of PCB layout to get the flyback converter HV output as clean as possible. There are still some high frequency noise that shows up in the output. A simple 1 bit, digital low pass filter was implemented to clean this up. I though about trying to do this in the MCU software, but opted for the hardware approach.

The digital filter is a simple 8 bit shift register followed by some logic and a...

Files

RS422_Shifter.pdf

Schematic for UART to RS422 driver board (not tested yet)

Adobe Portable Document Format - 92.26 kB - 09/12/2019 at 19:55

Preview

Filter_Regulator_Bd2.pdf

Schematic for power input filter and local regulator. (not tested yet)

Adobe Portable Document Format - 170.76 kB - 09/12/2019 at 19:54

Preview

CPU.pdf

Schematic for SAMD21E18 MCU board with RS232 level shifter and local 3.3V regulator.

Adobe Portable Document Format - 228.42 kB - 09/12/2019 at 19:53

Preview

filter.pdf

Schematic for digital low pass filter.

Adobe Portable Document Format - 237.14 kB - 09/12/2019 at 19:52

Preview

PowerSupply2.pdf

Schematic for HV Power Supply and tube analog stuff

Adobe Portable Document Format - 183.47 kB - 09/12/2019 at 19:51

Preview

Project Logs

Collapse

Working on the Logging Program
Bharbour • 10/06/2019 at 00:01 • 0 comments

The primary intent of this counter is to sit in the corner and collect data for a long time. The approach that I am taking to that, is to use a very simple fixed format, space delimited protocol coming out of the serial port on the counter, and log the resulting data on a Linux box, where storage is cheap.

A logging program will capture the data from the serial port and store it to the disk, in files containing 24 hours of data each. Data is stored on 1 minute intervals, along with a time stamp from the counter's RTC. After each file is closed at midninght, it gets gzipped to reduce storage requirements. The disk files use Comma Separated Variable format because it is really easy to parse for post processing or just read into a spreadsheet program. A log file of text and debuggish information is also stored and compressed nightly.

Just after midnight, the counter RTC is checked against the host PC RTC which is GPS disciplined. If the counter RTC skews more than a few seconds from the PC clock, it will be corrected.

The logging program is going to be started from the init process when Linux boots. A consequence of this is that the program starts with root permissions, which is not a good plan for a secure system. Getting the process permissions and such to be reasonably secure in this situation has been pretty much of a slog. The last time I wrote "daemon code" was back in engineering school, a long time ago. Current Linux is not that different conceptually from the DEC Ultrix that we used for the systems programming classes in 1988, but enough time has passed and details have changed to require a lot of reading. My favorite reference book on Linux system programming is "The Linux Programming Interface" by Michael Kerrisk. It is an EXCELLENT reference book, well written with good explanations and good example code.

At this point, I have one more corner case to handle in the process ownership / configuration code. Once this is done, it is time to move on to another project.
Packaged It Up
Bharbour • 09/26/2019 at 20:18 • 0 comments

All of the boards are built and working, and the system is packaged up. The Linux code that will log the output data is mostly written and operating.
In normal use, there is no need for a display. A connector to allow using a display is shown and capped off at the lower right corner of the box. My plan is for this counter to run mostly unattended in a back corner of my shop, collecting data for extended periods. The enclosure should be fairly weatherproof, if I wanted to move it outside. A later project is a simple weather station, and putting this box in the same outdoor enclosure as the weather station would make sense, as my goal is to collect long term count data and try correlating it to weather patterns.
A standard character LCD display with a serial interface backpack is plugged into the counter here. Some kind of protective packaging will be necesary for the display, but I don't forsee many uses for a handheld counter in my shop.
Finally, here is a picture of the enclosure with the cover in place.
The sun is fierce here, so it will need to go under some kind of protective cover if it is placed outside. With the cover in place, the electronics run about 10F above the ambient temperature. This picture also shows the serial interface backpack on the display.
Total power consumption is under 700mW at 12V input. About half of that goes into the high voltage power supply. The digital filter board pulls about 10 or 15mA at 3.3V and the MCU and display pull the rest.
Next, I want to see if I can find any radiated RF, since this box will be running near my amateur radio equipment.
Playing with counter output data
Bharbour • 09/14/2019 at 18:57 • 0 comments

The firmware on my counter is set up to output the number of milliSeconds between count events. This morning, I carved up the parser program to generate a histogram of the time between events from a log file that I captured yesterday. About half of the log file was captured with an envelope of thoriated tungsten TIG electrodes was sitting next to the counter, and the other half is just background radiation level. The X axis is showing the number of milliSeconds between counts, from the minimum to the maximum that are in the capture file. The Y axis is showing the number of count events for that time between counts. There are 500 bins in this histogram, with time between events ranging from 21mS out to 31000mS, resulting in each bin being about 60mS wide. As an example, all of the events between 21mS and 81mS (minimum + bin width) are counted in the first point.

It has been a REALLY long time since I sat in a probabilities and sadistics class, but I was hoping that the curve was going to be flatter and spread out over a wider area. I suspect that if I had only background levels in the file, the curve would be a little bit more spread out at the low end. I will check this later, and if it is really noticable, I will post more on this.
9/15/2019 Update, Here is a plot of the count interval histogram with all data from background radiation, the TIG tungstens were are the other end of the house. There are no sources of radiation that I am aware of nearby. The data was collected mid afternoon. The counts/minute were averaging around 26 or so and this is a 3 hour acquisition set.
Comparing the two plots shows that the background only plot is somewhat wider at the at the low end, but the shape is pretty similar.
Connectors arrived today, Tie the big pieces together!
Bharbour • 09/13/2019 at 22:51 • 0 comments

The connectors arrived today to tie the MCU board tothe filter board, and the counter is counting! I am still running the HV supply on a separate power supply until the PCBs show up for the power filter/pre-regulator. Power consumption is about 1/2W total.
The software is working well enough to get coherent log files through the serial port. Right now, I am running the UART at logic level out to an external logic level UART board until I decide on RS232 or RS422 for the external interface.
Initial testing on the bench in my shop is showing about 20 - 36 counts/minute and parking an envelope of 35 year old 2% thoriated tungsten TIG electrodes a couple of inches from the tube triples that number.
So far, so good.
I also started on the Linux software that will monitor the serial data output stream and log it. That is coming together slowly, as I am still deciding what I want it to do...

View all 4 project logs

Discussions

helge wrote 07/27/2021 at 07:42

images seem to be broken (thanks, HaD) so I can't really see what the HV inverter looks like. Anyway, I built a radiation detector that ran continuously on 3 AA cells for > 1 1/2 years using a CCFL inverter transformer, along with a TS555 as comparator with hysteresis. Schematics: https://twitter.com/MisterHW/status/1321177043548209152

Are you sure? yes | no

Bharbour wrote 07/27/2021 at 09:54

I looked and the .pdf file for the HV supply schematic opens OK for me and the photos are all there.

This HV power supply pulls about 10 or 20 mA on the DC input from what I remember. It was not really designed to run from batteries on a long term basis. With the filter and the microcontroller board, the system probably pulls 40mA with 12V in.

When I started playing with Geiger counters, I got a kit that used a 555 in the HV power supply.

Are you sure? yes | no

helge wrote 07/27/2021 at 10:43

(re pictures: last time I got a broken base64 url, perhaps a temporary glitch)

Some converters use 555 timers for the switching signal itself (usually for a high-ratio boost converter, rarely to drive a flyback choke). The circuit has a quiescent current of 50-100 µA and running only for short bursts to recharge the capacitor.

I like your nice and clean build. Turning a Royer converter on for brief periods of time though seems to be rather promising for battery-powered loggers.

I've got a thing for loggers that can keep running on their own for years.

Are you sure? yes | no

Bharbour wrote 09/13/2019 at 19:23

I have heard that it is a good source of entropy. I was playing with the numbers for my implementation last night (when I should have been sleeping) and I suspect that I don't have enough measurement resolution to get much span on these values. Once I get it running, that will be something to look at.

Are you sure? yes | no

Dan Maloney wrote 09/13/2019 at 15:03

I like the idea of using counts to generate random numbers. I've got a couple Geiger tubes hanging around here - might make a fun project.

Are you sure? yes | no

Bharbour wrote 09/13/2019 at 22:57

After tying the counter output to the MCU, I have been watching the interval data. Initial tests were done with some 2% thoriated TIG electrodes parked near the tube, just to get higher numbers to see activity. Later, I removed the electrodes and logged an hour or so of data at background levels. With the higher count rates, the range of periods was a good bit lower, and the 1mS timing resolution was a little thin. With background levels, it looks like there are 12 or 13 bits of range. I have been logging the raw data, and will do a little analysis in the coming days.

Empirically, the values look to be all over the place, which is a good thing.

Are you sure? yes | no

Geiger Counter

Description

Details