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.
The following connections were made to allow the Raspberry Pi and Gertboard to log the Geiger counter events:
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:
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.
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.
Here is such a graph where each band encompasses 48 hours with hours separated by yellow lines or days in Universal Time (UT) separated by red lines. The start was at June 26, 2013, 08:14:47 UT (01:14:47 PDT) at the bottom left and the end is at the top band on July 6. Each horizontal pixel represents a 2-minute time slot and each horizontal grid line represents 25 events/minute. By chance, there was a large amount of solar particle activity during this period overwhelming the background cosmic ray flux.
In mid-July, there was less solar particle radiation. Also, I was able to get some data at high altitude. This graph has an 84-minute block of data taken at 3054 m altitude shown in magenta. I had software and battery trouble that prevented getting more data on that trip. 46 hours of data taken 10 days later at 1830 m altitude showed little difference from the earlier data at 266 m altitude. This is consistent with the known cosmic ray altitude dependence that starts out quite flat and then grows quickly above 2000 m altitude.
Can I see the C-14 decays in a block of wood using this arrangement? I only have 10 lead bricks which turns out to be inadequate to build a good shield for a Geiger tube. Cosmic rays can generate additional radiation when they strike lead which can defeat the goal of shielding for shields of less than 10 or 20 cm. Still, I tried and alternately switched a block of wood in and out of the front of the Geiger tube in an inadequate lead shield and without a lead shield. The resulting data are shown in this graph. The signal-to-noise ratio was too poor for any conclusion to be drawn. The bottom row was done with lead shielding and the remaining rows were done without.
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 uploadingViaSPI.py 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