Using a Raspberry Pi to Monitor a Geiger Counter


To help teaching students about nuclear radiation at Willow-International Community College in Clovis, CA, we bought a Geiger counter that came with a carbon-14 sample. That could be used to demonstrate how beta rays from the C-14 decays could be hindered by a few sheets of paper. A geology teacher then gave me some uraninite rocks in which uranium is decays to lead in a chain of nuclear alpha, beta, and gamma decays. The gamma rays have great penetration power and could be shown to easily penetrate one's hand.

The nagging question that could not be tested was what was causing the background counts when no C-14 or uraninite samples were nearby? Were they caused by electronic noise, cosmic rays, or radiation from the ground and concrete? We then received a mini-grant from the school to buy 10 2"x4"x8" lead bricks for $635. With the lead bricks shielding all sides of the Geiger tube for at least 2" distance, a student (Larry Meyers) and I manually counted 250 Geiger counter clicks over 40 minutes, a rate of 6.25 counts/minute. We then removed the upper wall of lead exposing the Geiger tube to the ceiling of our second-story laboratory. Then, 250 clicks occurred in 34 minutes for a rate of 7.35 counts/minute.

As is typical in scientific investigations, this inspired additional investigation, but the manual counting needed to be replaced by automatic recording of the time of each event over days.

With summer break coming, I decided to automate the Geiger counter event logging using a Raspberry Pi and Gertboard. Fortunately, the Geiger counter (PUG-7 manufactured by Technical Associates of Canoga Park, CA) came with a schematic diagram and it was easy to locate a 5 V digital circuit to provide 50 ms pulses for each event. The Gertboard needed 3.3-V pulses so a resistive divider with 22 kOhms in the upper leg and 33 kOhms in the lower leg was used between the Geiger counter and a Gertboard buffer leading to the ATmega328P processor on the Gertboard.

It was also convenient to have the analog-to-digital converter on the ATmega328P processor monitor the battery voltage of the Geiger counter since after about 9 days of continuous use, its two 9-V batteries would need to be replaced. Another voltage divider sampled the battery voltage after the Geiger counter power switch to provide about 3.3 V when the Geiger counter batteries were at full charge. This divider had a 100 kohm resistor as its top leg and a 47 kohm resistor as its bottom leg going to ground.

Connections to the Geiger Counter

The following connections were made to allow the Raspberry Pi and Gertboard to log the Geiger counter events:

Necessary Software

ATmega328P Assembly language program

The 600-page Datasheet for the ATmega328P was downloaded and its first 330 pages carefully studied. This assembly language program was the result. After initializing the SPI interface and timer1 with their interrupts, it goes into an infinite loop waiting for interrupts.

The ATmega328P interrupt routines perform as follows:

Retrieving data from the ATmega328P

Whereas the ATmega328P processor is dedicated to monitoring the Geiger counter events, the Raspberry Pi is multitasking with other activities and should not be required to always be looking for data from the ATmega328P. The ATmega328P storage capacity of about 500 readings allows a more leisurely transfer of data into the Raspberry Pi. The program, written in the Python language, to retrieve that data is here. It stores the data in a file called dataOut as pickled data on the 16 GB class 10 storage card plugged into the Raspberry Pi card slot.

Synchronization of the SPI transfer is a bit tricky. When no data is ready to be sent, the receiver will happily place zero bytes into the data stream. To clearly deliniate the start of valid data, 4 0xFF bytes are sent before sending very first of the 4-byte data values. Since negligible errors will be introduced by assuming that no event will have a time of 4 0x00 bytes or 4 0xFF bytes and that the event times will never be decreasing, it was possible to construct an algorithm for data synchronization that appears to reliably extract the data values from the spurious zero bytes.

The voltage data is never larger than 0x000003FF, a value the quickly is exceeded by the monotonically increasing time values. This fact as well as the fact that the voltage is tacked on at the end of the data stream when the buffer has been emptied, allows it to be distinguished from the time values.

Presenting the Data as a Graph

When I am interested in looking at the data, I use the ssh/scp protocol to copy dataOut from the Raspberry Pi into my desktop computer where it is given an appropriate name such as dataOutDoubleBottomShielding-3. If there were no disruptions or software changes, only one file would be necessary, but currently, I use a range of name-n files which this Python program interprets and presents in graphical form.

Some Results

Uploading the Machine Code from the Assembler into the Program Storage of the ATmega328P

The machine code for the ATmega328P processor is contained in an object code file loggingWithSPIInterrupts.obj produced by the avra assembler from the loggingWithSPIInterrupts.asm assembly language source program. The Python program extracts the machine code, adds special ATmega328P programming command codes, holds down the RESET line of the ATmega328P, and sends it to the ATmega328P which is then able to receive program code.

A program called avrdude mentioned in the Gertboard User Manual among other places can do this, but I like to fully understand what is happening in this system and preferred to write my own uploader. It required really understanding parts of the ATmega328P Specsheet and utilizing hints from other AVR documents. The resulting program encapsulates what I learned.

It is with some satisfaction that I can point out that all hardware and software used here, including the Linux operating system on the Raspberry Pi, is fully documented with available schematic diagrams and source code. Nothing is hidden!

Last updated: December 23, 2013

Valid CSS! Valid XHTML 1.0 Strict

Contact Craig Van Degrift if you have problems or questions with this web site.