Cosmic ray detection from vertical and horizontal directions using three Geiger counters

__MATHJAX_DOLLAR__ Research Group: Ryan Mountcastle, Minh Trang Nguyen, Nathan Ranno, and Ryan Ward

Launch: Whitworth Fall 2012

This experiment was designed to examine cosmic ray activity in the Earth's atmosphere as altitude increases. The previous group's project utilized three Geiger counters stacked vertically to eliminate false positives. This only accounts for rays travelling in the vertical direction. We seek to examine the rays travelling in both the vertical and horizontal direction knowing that rays are scattered in the atmosphere (see Fig. 1). Our arrangement of three Geiger counters had two searching the vertical direction and two searching the horizontal direction; one Geiger counter was shared between the directions. We used an Arduino microcontroller and NOR chip to take the readings from the Geiger counters and watch for simultaneous counts in a single direction. The counts were summed over a one minute interval and read as a scaled voltage by the transmitter. Due to a faulty variable declaration in our code, the pod did not transmit data successfully for us to analyze. We were not able to reach the desired conclusions, but we are confident that fixing the problem in a future project will result in successful data collection.

Background
In the early stages of cosmic ray detection, it was believed that “atmospheric electricity” came directly from radioactive elements in the ground. Furthermore, it wasn’t until 1912, when Vector Hess’s balloon experiment concluded that the ionization levels (radiation) gradually increased in altitude. Although Hess later won the Nobel Peace Prize in Physics for his discovery, the term "cosmic rays" wasn’t fully discovered until the mid-1920’s when Robert Millikan made measurements on primary gamma rays and secondary electrons. From his data Millikan concluded that the gamma rays originated from deep interstellar fusion between hydrogen atoms and heavier elements and that electrons were produced from gamma rays interacting with the earth’s atmosphere. Later studies proved that cosmic ray particles do in fact origin from deep space, however, they carry an electric charge rather than being designated as photons. As a result, Cosmic Rays birthed a new era of astronomical science.

Ultimately, there are 3 major types of Cosmic Rays: Galactic, Anomalous, and Solar Energetic Particles. All though these different types of cosmic rays have their own “finger print” or source, for the most part, they are categorized in either Primary or Secondary Cosmic Rays. Primary Cosmic rays originate from deep space where as Secondary Cosmic Rays are formed once the particles penetrate the earths or other interstellar matter’s atmosphere and surface. For the purpose of this experiment, we will focus on Secondary Cosmic Rays. With the exception of a small percentage of antimatter particles and anti protons, Cosmic rays primarily consist of subatomic particles; protons, electrons, and nuclei. Moreover, about 89% of the rays are protons, 9% are alpha particles, and less than 1% is heavier nuclei or electrons. Once the Primary Cosmic Rays hit the earth’s atmosphere, they interact with air molecules and break down into their own respective components. Fig. 1 As the Primary Cosmic rays start to break down, their interaction alters the states of the particles where they “shower” down into low energy states. The apparent question of Cosmic Radiation then becomes: How much energy does each Cosmic Ray have as they collide with atmospheric molecules and break off into their components? Research tells us that the peak of Cosmic rays in our Earth’s atmosphere is somewhere around 15 km. This can be explained in 3 parts. First, when Primary Cosmic rays enter the atmosphere, they range from very high to very low energy states. Second, the key to measuring Cosmic rays in our experiment is to only account for high energies. Third, the peak of Cosmic Rays in our Earth’s atmosphere is the sum of the max energies of high secondary cosmic rays and primary cosmic rays. As a result, the different energies of the Cosmic rays can give us a better reading on the variation of cosmic rays as you move up in altitude.

Materials

 * Structure
 * Styrofoam
 * Mylar
 * Carbon fiber kite poles (2)
 * Epoxy
 * Zip-ties
 * Pod's Innards
 * Aware RM-60 Geiger counters (3)
 * 9V Lithium ion battery
 * Arduino Uno, 28116TH
 * NOR Gate, FFCW9034
 * StratoStar experiment interface module

Pod Construction
We created the pod from styrofoam and two carbon fiber kite poles.





Electrical
Our circuitry consists of a NOR gate to watch for simultaneous counts between each pair of Geiger counters, an Arduino Uno microcontroller, RC filtering, and the transmitter. The counters and NOR chip are powered with the 5V output from the Arduino, which is in turn powered with a 9V battery.

Data Sheets

 * Micro Roentgen Radiation Monitor, Aware Electronics RM-60
 * Quad 2-Input NOR Gate, Datasheet for SN74LS02

Software
We wrote a program to input the results of the NOR gates to the Arduino, watch continuously over a period of one minute for synchronous counts, then output the number of counts as a voltage from 0-5V. We scaled the voltages such that 255counts = 5V.

Program Flow

 * 1) attachInterrupt continuously checks inputs for Rising voltage
 * 2) Call 'vert' when pin2 Rises to increment vertical counter; call 'horiz' when pin3 Rises to increment horizontal counter
 * 3) After one minute output total of 'vert' counts on pin6 and 'horiz' on pin9 as a scaled voltage
 * 4) Reset counters and repeat

Code
Cosmic_Rays_3Geiger_L //Initialize counters and I/O pins unsigned long count12 = 0; unsigned long count23 = 0; const int C12 = 6; const int C23 = 9; float V12 = 0; float V23 = 0; unsigned int interval = 60000; //Originally was signed int

void vert { count12++; }

void horiz { count23++; }

void setup { pinMode(C12, OUTPUT); pinMode(C23, OUTPUT); //Whenever the input to pin 2 changes from LOW to HIGH, call function vert to increment number of sync counts for GCs 1 and 2 //Whenever the input to pin 3 changes from LOW to HIGH, call function horiz to increment number of sync counts for GCs 2 and 3 attachInterrupt(0, vert, RISING); attachInterrupt(1, horiz, RISING); }

void loop { //Output a voltage from 0-5V scaled by the number of counts: //Let 255 counts correspond to 5V, so each count is approx 0.0196V //analogWrite(Pin, PinVal), where PinVal(0-255) = 255*(Analog Volts)/5 analogWrite(C12, count12); analogWrite(C23, count23); count12=0; count23=0; //Read data over an interval of one minute = 60000ms delay(interval); }

Geiger Counters and NOR Gate
As previous groups have reported, the Geiger Counters output high voltage with a 0V spike when it registers a count. In order to test the counters, we used a NOT gate, and found that each counter read from 0-10 counts per minute from background radiation. For testing multiple counters, we used the NOR gate so that simultaneous counts resulted in a HIGH output from the gate. We found the synchronous counts to be lower, from 0-4 counts per minute.

We had several mechanical issues with the counters: firstly, the mica film on the vacuum tube of one of the counters was disconnected and so a new counter had to be ordered. Secondly, he cables connecting the counters to the circuit are, as we discovered the hard way, directional, and we had to resolder several of the wires multiple times.

Circuit and Software Testing
We tested the program in two main chunks: attachInterrupt and associated functions, and output voltages. We tested the attachInterrupt with a basic program that displayed a message when the pin Rises, and then with the geiger counters to ensure that Rising voltage would actually interrupt the loop to call the proper function. We tested the output voltages with a simple program that takes a given number of counts and converts it to a voltage using the aforementioned scaling. We investigated the idea of using an overflow bit, having an output to indicate if the number of counts exceeded 255 (e.g. 280 counts would register as 25 counts with the overflow bit on logic HIGH), but upon inspection of previous groups' data we decided that the number of counts would not exceed 255 counts per minute and scrapped the overflow idea.

Transmitter Testing
We connected the transmitter with 'horiz' counts on pin4 and 'vert' counts on pin5. We put a small radioactive source in our pod and verified that the data was indeed being recorded on the tracking laptop. We discovered that the command module interprets voltages 0-5V as a number from 0-1023. Because our program outputs the number of counts 0-255 as a voltage 0-5V, to convert from command module data to number of counts, we divide by 4.

Data and Analysis
Upon retrieval of the pod, we immediately verified that the Arduino was still powered, which indicated that the battery did not die during flight. We also verified that all circuitry components were still properly connected.

When we analyzed the data, we observed several oddities: firstly, all of the voltages were nearly zero. With the command module's scaling accounted for, the highest number of counts we saw was 0.5. Secondly, we noticed that the voltage was not constant over the course of a minute, as it should have been according to our code's 'delay' operator. These two errors lead us to believe that there was a malfunction in either the circuitry or the code, having already ruled out mechanical issues through the post-retrieval checks.

Troubleshooting
We performed a series of tests in order to isolate the problem. First, we used a digital multimeter to verify that all components (resistors, capacitors, Geiger counter wires, etc.) had not been damaged. We also confirmed that the NOR chip only output HI when both inputs were LOW.

Next we removed the Geiger counters from our circuit, instead moving a wire between logic HI and LOW to simulate counts on GC1 while maintaining GC2 at LOW. The output voltage was always 0.03V, no matter how many counts we forced. We then removed the proxy Geiger counters and NOR chip, as well as the RC filtering components. When we input a number of counts directly to the Arduino and read the output voltage from pins 6 and 9, we still measured 0.03V.

We obtained a second, new Arduino onto which we loaded our final code, so that we might check the program for errors while not overwriting the code used during launch. We observed that the program worked with this new Arduino at intervals of 10s and 30s, but failed at 60s. We discovered that 'interval', the variable used to delay the code for 60000ms, had been stored as a 'short signed int', whose maximum value is +32767. By changing 'interval' to either a 'long signed int' or a 'short unsigned int', the program operated correctly.

What this suggests is that we did not test our final code. We tested the various important components such as 'attachInterrupt', the voltage scaling, and the entire program at 10s and 30s intervals, as well as the partial code at 60s. Had we increased 'interval' in the complete code even as high as 33s, then we would have spotted the error and revised our variables.

Results
Due to the programming error, our pod collected no meaningful data. Without the proper timer variable, our code predictably ran for the first iteration of our loop and stopped.