Geiger Counter

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.

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.

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.

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...