Build a 100% functional geiger counter, complete with replica vintage case, analog gauge and glowing blue LEDs! - By Liam Davies and Daniel Koch
Geiger Counters have been around for nearly a century and have a great number of scientific and practical applications. While they’re not super useful for the average person - unless visiting an historically or scientifically irradiated location - they’re still a fascinating instrument and can lead to interesting insights about objects around us. There are various household objects that are naturally radioactive, even if your house isn’t older.
Unfortunately, in scientific research they’re not usually as effective as more sophisticated radiation detection and measurement techniques. We looked into building a scintillation detector or even an Ion Chamber in this project, however they usually require thousands of dollars in material to build one from scratch.
It’s worth noting that detection is a whole different ball game than measurement of radiation. Detection is significantly easier than measurement - if we’re taking a measurement, we’re interested in its quantity rather than solely determining whether it’s present or not. While our Geiger Counter will technically do both, it definitely won’t be accurate enough for scientific or research use. It’s more of a desk toy than anything else, so it’s not a good idea to rely on this project if for some reason you’re in a radioactive location!
We were inspired by the soviet-era Geiger Counters with the famous yellow and silver enclosures, with the top-positioned handles. Since we have access to CAD software that lets us add whatever features we want, we spiced ours up with some additional DIYODE goodies, including a custom panel meter, a pulsing blue LED bar and an authentic speaker that pulses when a tick is heard.
How It Works
The Geiger–Müller counter was developed in the mid 1920s by Hans Geiger and Walther Müller, who created various iterations on the design first theorised in 1908. It can detect a variety of radiation, with a few limitations.
A GM tube is much simpler than you may expect - the most common one used in Arduino-based models has a glass tube with two electrodes on each end. One electrode (the anode) is connected to a conductive wire mounted down the middle of the tube, and the other (cathode) is connected to the outside of the tube. The tube itself is filled with a low pressure inert gas, which is usually helium, argon or neon.
When ionising radiation - such as a beta particle - hits the tube, it ionises the gas inside and creates what is known as an ‘ion pair’. This consists of a free electron and a positively charged ion of the gas that was split. Because opposite charges attract and like charges repel, the negatively-charged electron travels towards the positively-charged anode (the wire in the middle of the tube) and eventually reaches it, creating a current.
But wait a minute, how would the current from one electron ever be noticeable to a circuit connected to the tube? Surely, it is far too small to create a pulse! As it turns out, as the electron hurls towards the anode after being split from its original gas molecule, it gathers so much energy that it collides with other gas molecules in the way. These molecules then split into another ion pair, and the process repeats at a faster and faster rate. This is known as an ‘electron avalanche” and is capable of creating a significant pulse in current from just one radioactive particle.
The electron avalanche is usually only persistent for a 10-20 microseconds, but its resulting current pulse is big enough to easily detect on the negative side of the circuit - usually on the level of a few volts. This makes counting detection of radioactive particles dead simple.
There are, of course, a few limitations of using a classic GM tube design like this. Because any detectable type of radioactive particle will cause the same electron avalanche, there isn’t any information about the particles themselves contained in the pulses given by the GM tube. This means that it’s not possible to differentiate between alpha and beta particles, for example. Virtually the only information that can be derived from the GM tube is the amount of incident particles in a given amount of time.
The GM tube also has limits to the rate at which it can detect radiation. If an exact count is required, measuring radioactive sources that result in more than 10,000-100,000 detection events per second (depending on the tube size) will cause the tube to be less responsive to additional counts. This limitation would not bother those who intend to use the Geiger as a qualitative indicator of high radiation levels, rather than exact CPM numbers that we can derive from the Arduino.
Also bear in mind that measuring materials that are strong alpha particle emitters would need a close proximity to be properly detected. Alpha particles only have a range of about 5cm in air, and can also be attenuated or stopped completely by the glass tube walls. We investigated this more during our experiments.
Our Counter
We did consider designing our own Geiger–Müller driver circuit for this project, however we eventually decided against it for a few reasons.
First, GM tubes use high voltages of typically over 400V. While the voltage can vary based on the sensitivity of the tubes, it’s still a dangerous level which we’d rather not create schematics for. It certainly couldn’t be created on a breadboard or veroboard with negligible safety risk - a proper PCB would be the way to go for a project like this if we did it from scratch.
Second, we’d need to source a Geiger–Müller tube that has a datasheet and reliable performance. Sourcing and designing a circuit for a specific tube would probably warrant an article on its own.
As a result, we chose DF-Robot’s Geiger Counter module. While it’s on the more expensive side, it turns what would otherwise be a complex and potentially dangerous project into a much more achievable one. Of course, high voltages are still present on this module as it operates on a similar voltage as other GM tubes, but it is protected with an acrylic sheet and we don't have to design or build any of it. For testing, we also wrapped some of the module in electrical tape in order to further insulate it and avoid accidental contact. We’d rather not find out what it feels like to get a zap from it!
The module itself is dead-simple to use - you don’t need an Arduino to get counter readings out of it. It just needs a 5V and Ground signal to turn the module on. It uses a simple active-low pulldown output to generate a pulse whenever a particle is detected in the tube. In other words, it simply sets the output voltage to 0V for a split-second. The most common measurement for this rate is Counts Per Minute (CPM) and, in Australia, the background radiation can be anywhere between 20 and 40CPM. This depends on whether you’re inside or outside, near natural or artificial radiation sources and so forth. While we haven’t tested it, this tube is also reportedly sensitive to bright light, so you’ll probably see slightly higher readings outside.
Fundamental Build
| Parts Required: | Jaycar | ||
|---|---|---|---|
| 1 x DFRobot: Geiger Counter Module | - | ||
| 1 x Large 5V Analog Panel Meter | - | ||
| 1 x Arduino Compatible Uno | XC4410 | ||
| 1 x Piezoelectric Buzzer | AB3442 | ||
| Dupont Wires | WC6027 |
The fundamental build is, for the most part, dead-simple. We’re essentially checking that everything that needs to work, works.
The voltmeter is the first thing we connected to our Arduino compatible Uno, which just needs to be connected to a ground pin and a PWM pin. We connected ours to Pin 9, but there are many other pins that can also be used for this - just look for the tilda (~) symbol next to the pin number to check it’s PWM compatible. The voltmeter itself is polarised, so be sure to match up the negative and positive terminals with ground and Pin 9 respectively.
For the fundamental build, we just screwed down two washers to clamp down Dupont cables, but for the final build we swapped to using eyelet connections for a much more reliable and robust connection.
The Geiger Tube module only has three header connections, which also includes a header cable that lets us use Dupont cables directly. You may need to use additional Male to Male dupont cables to connect it directly to our Arduino Uno.
It’s worth noting that the Geiger Counter already includes a Buzzer onboard, however after turning it on with the switch on the side of the module, we found it very annoying and piercing. It can be heard from across the office! We quickly turned it off and looked for a better solution. We first tried using a piezo element by connecting it to Pin 5, which can be pulsed with a short voltage to provide the familiar geiger “ticking” sound - although it was on the muted side and not as loud as we wanted it to be.
You’ll see shortly that the main build uses an actual speaker with a coil, as real Geiger counters do. Real Geiger counters have the speaker directly connected to the cathode of the geiger tube, however, we want a bit more control so we’re using the Arduino as a middle-man. This way, we can control how long each pulse should be, or if we should even pulse it at all. The speaker tends to get rather annoying if left on all the time!
The piezo buzzer/speaker doesn’t require a PWM pin considering that we’re never actually driving a frequency. If you want to play tones - a warning buzzer, for example - you will need to use a PWM pin though.
The Code
We’re only making a basic version of the code for the Fundamental Build, so we can check if our counting algorithm will work well.
First, let’s get some numbers down. As we previously mentioned, background radiation tends to be around 20-40CPM. However, this also varies based on the size and sensitivity of your GM tube. Higher grade and larger tubes will detect more radioactive particles, which may mislead the user into believing that an area has more CPM than it actually does. It’s for this reason that Geiger Counter modules like this one from DF-Robot include a conversion rate to a more standardised measurement, in this case Micro-Sieverts per Hour - or μSv/h. The Sievert is the unit for the radiation dose that affects the human body - there are many other different units of radiation measurements, however we’re keeping it simple in this project. The conversion rate for our module is 153.8CPM/μSv/h. In other words, if our CPM is 153.8, this would be the equivalent of 1μSv/h. Therefore, we should have a reading of around 0.2μSv/h with average background radiation.
However, we have another problem to address which we actually spent quite a lot of time working on. How should we measure how many counts per minute we get? The most obvious approach is to wait a full minute and sum up how many counts we read, which would be our exact CPM. Below is some rough pseudocode of how this would work:
loop forever:
CPM = 0
loop for 60 seconds:
if a count was detected:
add 1 to CPM
finish loop
output CPM
However, this wouldn’t be responsive. We’d have to put a radioactive sample next to the geiger counter for a full minute before we get a CPM reading!
The other approach is to wait until we receive a pulse, then calculate how long it’s been since we’ve seen one before that, extrapolating the results into a CPM reading. For example, if we read 2 pulses four seconds apart, we can say that we are reading 15CPM (60/4).
The code below continuously polls the delay between radioactive particles, and outputs it to the analog panel metre, as a range between 0 and 250CPM.
void loop() {
if(pulsed) {
pulsed = false;
inst_CPM = 60.0 / ((millis() - last_count_time) / 1000.0);
last_count_time = millis();
int out = 255 * inst_CPM / 250.0;
analogWrite(GAUGE_OUT, out);
}
}
void count() {
pulsed = true;
}
This works well and is responsive, however this is highly susceptible to random amounts of radioactive particles. Sometimes, we may go 10 or more seconds before seeing any particles, and other times we may get 2 radioactive particles within 100 milliseconds of another. In the latter case, we would calculate a CPM of 600! This, of course, is misleading - we aren’t really seeing 600CPM, we just happened to see two radioactive particles pulse the Geiger Tube nearly at the same time.
Ideally, we want to see a responsive needle so we know immediately that we are near a radioactive source, but simultaneously we should see a fairly accurate reading of the current CPM. This is actually a somewhat challenging task, and we found a research paper on this very topic. Unfortunately, it was locked behind a paywall. If you’re willing to pay we’ve left a link to it in the resources. We’ll get more into the solution for this in the main build.
Main Build
| Additional Parts Required: | Jaycar | ||
|---|---|---|---|
| Lipo Rider Plus 5V/3A USB Type C | - | ||
| Arduino Nano | XC4414 | ||
| 1x BD139 Transistor | ZT2189 | ||
| 1x BC337 Transistor | ZT2115 | ||
| 2 x 1kΩ Resistors * | RR0572 | ||
| 1 x 15Ω Resistor * | RR0528 | ||
| 8 x PCB Pins * | HP1250 | ||
| 8 x PCB Pin Sockets * | HP1260 | ||
| 1 x Rocker Switch (average) | SK0984 | ||
| 1 x Pushbutton Latching Switch (power) | SP0793 | ||
| 1 x LiPo Battery | - | ||
| 1 x Solder Perfboard | HP9570 | ||
| 6 x 6mm M3 Screws | HP0400 | ||
| 2 x 20mm M3 Screws | HP0410 | ||
| 1 x COB LED Bar | - | ||
| 1 x 40mm Speaker | AS3004 |
* Quantity required, may be sold in packs ^ May not have the same dimensions as the part we used.
Let's put together the main build! Most of the core bits of our circuit are unchanged. We’re just adding a few extra features and 3D printing a cool-looking case. If you need to refer to any wiring steps, the Fritzing and schematic is available for an easy wiring guide.
Control Board
Unlike the Fundamental Build, we’re using a more compact Arduino Nano for the Geiger Counter, which will be soldered directly onto a perfboard with a breadboard layout. We love these boards because not only are they convenient for moving a circuit from a breadboard directly, but components are also easy to lay because the pitch and orientation are the same as the breadboard.
The main board itself is not a super complex job, so we aren’t including the step-by-step construction details. The main tricky bit is ensuring no traces are shorted on the underside of the board, and adding enough strain relief to the wires so they don’t break as we are assembling it.
We used PCB pins to create easy, removable connections between pins and external wires. These can be connected with simple female Dupont wires. We’ve provided a parts list for all the components you’ll need to put together the main board.
Power
While we didn’t technically have to make this project battery powered, we thought doing so would add some serious coolness factor - we can test any object for radiation, portably! While a basic bank of AA batteries could have been used for this, we used a Lithium-Polymer battery to make the project fully rechargeable. To go alongside the battery is the awesome LiPo Rider Plus which manages battery protection, charging and regulating to 5V with virtually no setup required.
One thing that was not anticipated was the charging rate of the battery. The LiPo we chose only claims a maximum charging rate of 0.5A, while the LiPo Rider Plus will try and force 3A into it! If you do use the LiPo Rider Plus, you need to either use a higher maximum charge current battery, or modify the Rider Plus to output a maximum of 0.5A. Alternatively, use a different battery board.
Our solution for this problem is just using a standard USB port for charging the Geiger Counter. Since the USB 2.0 specification states a standard port can only supply 500mA, we shouldn’t be putting too much stress on the battery while charging. Sure, it’ll be slow, but the Geiger Counter won’t exactly get daily use!
Charging concerns aside, we also need to consider how we can turn on and off the LiPo Rider. The board itself has a handy power switch that enables or disables the 5V output, however, we want to wire in our own power switch. The ‘EN’ pin, like on many Arduino modules, can be powered or pulled to ground (depending on the board) to enable or disable the power. In this case, we pull the pin to ground in order to turn it off, and leave it floating to let the Rider board run.
The analog electronics on the circuit board are there to drive the output devices. The Average switch makes use of the Arduino’s internal pullup resistors, and so is a direct connection to the power rail. The speaker, however, needs a transistor for drive. It is a 0.25W 40mm speaker, which would draw a current of 20mA on an AC signal. However, we are using a DC supply and just pulsing the speaker. Therefore, a resistor is added in series to limit the DC current. The inductance of the coil will still limit the current and shape the rise and fall of the pulse, too.
Additionally, we used a BD139 transistor attached to a PWM pin to drive the blue COB light strip. This is a 3W module and draws up to 600mA when fully lit. Therefore, we used the 1.5A rated BD139 just to be sure. No heatsink is used, as the COB is never on long, usually being engaged at low PWM rates for low brightness.
Besides that, the PCB is mostly populated with PCB pins for connecting external items, and power connections for those items and the Arduino Nano.
3D Printing
There are three 3D printed parts to go along with our Geiger counter build. These are optional, but it tidies up everything into a nice neat package that you can bring anywhere if needed.
The top and bottom 3D printed parts are quite big and may take a number of hours to print. You will need a fairly decent sized printer to fit everything on the build plate.
We printed everything in shiny eSun Silk filament, opting for a bright yellow and copper finish. Of course, you could use an army green finish with a gun-metal PLA handle or any other colour combination to get what you want.
The handle sits on top of the whole unit and has a knurled finish for grip. It also fits the latching pushbutton for power - the wires connected to it are routed through the handle into the base. To actually insert the button, the nut should be dropped through the base until it sits flush in the hexagon-shaped recess. Then, just push the wires through and screw the button in place. The nut should compress the rubber O-ring to the plate which should hold everything nice and tight.
We printed the handle a number of times to dial in our print settings, since the curved edges create different reflectivity based on the direction of the layers. We also had some failed prints and some support problems, which we ended up fixing after a few tries of dialling in settings.
We used a small USB-C breakout board for powering the LiPo Rider board. While we could’ve mounted the LiPo board directly in a place where the USB-C port is accessible, we wanted a cleaner look. To mount the breakout board, simply push-fit it into the USB slot. Some gorilla glue can be used to fix it in place if the port moves when a USB cable is plugged into it. We’ll solder onto this shortly once we mount the LiPo Rider board.
A small area for the LiPo battery to slide into was designed, which can be fixed in place with double-sided tape or any non-heat based glue. While many makers do, it’s not the greatest idea to use hot glue guns or anything similar to affix Lithium-Polymer batteries as you’re applying unnecessary heat to batteries. You also may pull off the protective layers when removing the glue from the battery in the case of replacement or repair.
We originally were planning to use a heatsink with the COB LED bar, however we misplaced it and ended up using double-sided tape to affix the bar to the underside of the top enclosure. Since we’re rarely running it at full brightness, we doubt it would get hot enough to melt the plastic or overheat the LEDs. We also routed two solid core wires for power through a hole alongside the bar. Most parts in this project are connected to the main board with standard female jumper cables, so if you need to swap something out it's a fairly simple task.
We also added an “AV” switch to the top of the enclosure, which we’re planning to use to toggle the ‘averaging’ mode of the Geiger counter. The idea is, it can be enabled to enable long-term averaging if we want to measure something that reads only barely above background radiation. This has some spade connectors on the bottom side, although soldering wires directly to the switch terminals would work just as well.
The top lid is fairly easy to assemble, which just needs to be screwed to the underside of the handle. Brass inserts were used to secure everything together. Unfortunately, our brass inserts were slightly offset so some of the screws didn’t go in at a straight angle. While it’s not a huge problem, there is a slight gap between the lower and upper parts of the enclosure. You may wish to use a dedicated brass insert soldering tip to insert these at a perpendicular angle.
We used 6mm and 20mm hex bolts to screw through the top of the enclosure, which provide a nice stainless steel finish!
Custom Panel Meter
A few years back we made a PC status dashboard with custom panel meter gauges, and for this project we’re keeping this tradition! We love panel meters because they not only provide a retro way of visualising data, but it’s also quite intuitive and easy to understand. It’s not just a number on an LED display, it rather provides a better understanding of where the number sits in relation to its possible range.
|
Meter Colour |
Range / Units |
Maximum Danger Level |
|
Blue |
0 - 250CPM |
None |
|
Green |
0 - 5μSv/h |
Very Low |
|
Orange |
1 - 100000 BED |
Low |
|
Yellow |
0.1 - 10000μSv/h |
Low |
|
Red |
0.1 - 10000mSv/h |
Very High |
We made a bunch of templates in Adobe Illustrator to fit whatever range of radiation you might have in mind. To reiterate, using this project in an environment where radiation levels really matter is clearly a bad idea - we’re still providing a very high range of measuring dangerous radiation levels just for the coolness factor of having a red zone on our gauges.
In fact, our Geiger module can’t measure much more than 1.2mSv/h, so on our fancy red danger meter the needle would barely get past the first division.
To print this template out, print the PDF at 100% scale on A4 paper. Feel free to use thicker cardstock for making the meter look fancier, but using paper too thick may cause the needle to brush against it. The needle doesn’t have a lot of torque so anything slowing its movement will most likely stop it completely.
The best way to make these custom gauges is to glue them over the top of the existing panel meter’s backplate. Paper tends to be uneven and frustrating to get positioned correctly if screwed in by itself. You can use a craft glue stick as we did, or use more permanent glue if a smoother finish is desired. We suggest holding the gauge up to bright light to check the alignment.
Use a craft knife to cut off the excess paper around the aluminium backplate. The paper needs to be aligned as close as possible with the existing meter lines so that the needle lines up when re-inserted.
Before the front panel is screwed back on, we also used a pair of side cutters to very carefully remove the bottom part of the black plastic panel. Since we’re going to have the COB LED bar underneath it, it needs to have some way of shining through and illuminating the meter.
Handle
The handle has space for an illuminated pushbutton with a diameter of 16mm. The buttons we’re using from Jaycar latch ON/OFF (i.e. toggling), but also has a detent when pressed half-way that can be used to momentarily close the button’s switch. We’re going to set this up to temporarily turn on the geiger counter for quick measurements. This might be useful if you want to check if a certain sample of material is radioactive, without keeping the counter on and forgetting about it.
Code
The code for the Geiger Counter can be as simple or as advanced as you want, however we spent some time testing ours and developing an algorithm that provides a balance between a responsive panel meter needle and a fairly accurate CPM count. Because this project was originally designed for the ‘coolness’ factor, we also want some form of visual pulse to occur whenever a radioactive particle is detected.
In general, our code operates similarly to the “wait until a further pulse” idea we explored in the fundamental build. However, to avoid suddenly spiking the CPM count when we detect a new particle, we employ a sort of ‘rolling average’ algorithm that continuously shifts through CPM data values. For example, let’s say we plan to factor in up to 5 data points in our calculations.
The first CPM reading (after we receive the first pulse) gets put into an array like this:
[19 0 0 0 0]
When we receive the second reading, the first data point gets shifted along and the new one is inserted in its place.
[22 19 0 0 0]
This continues until we receive our 6th data point, at which point the original first data point gets removed. So, for every sample we receive, we add exactly one new data point and remove the oldest one.
[20 17 24 22 19]
[23 20 17 24 22]
Taking the average of the last array would equal a CPM of 21.2. This is great because we receive smoother readings, which can be tuned by changing the length of the array. We chose a value of 15 data points, but the averaging switch we added to the build will switch the array to having 100 data points for long-term measurements instead. We unfortunately ran out of time to implement the last feature, but the Arduino is ready to use it from a hardware perspective if necessary. In any case, here is our averaging algorithm:
double calcRunningAverage(double now_cpm) {
av_CPM_total = now_cpm;
for(int i = 0; i < ROLLING_AVERAGE_SAMPLES-1; i++) {
//Sum up array.
av_CPM_total += pulse_delay_array[i];
}
av_CPM_total /= ROLLING_AVERAGE_SAMPLES;
return av_CPM_total;
}
void loop() {
if(pulsed) {
pulsed = false;
inst_CPM = 60.0 / ((millis() - last_count_time) / 1000.0);
last_count_time = millis();
inst_uSvh = inst_CPM / CPM_PER_USV_PER_H;
calcRunningAverage(inst_CPM);
pulse_delay_array[0] = av_CPM_total;
for(int i = ROLLING_AVERAGE_SAMPLES - 1; i > 0; i--) {
//Shift each element along in the array
// by one element.
pulse_delay_array[i] = pulse_delay_array[i-1];
}
pulse_delay_array[0] = 0;
… (loop code continued) …
This code is on the complex side, but if you follow our aforementioned description of the algorithm, it should make sense. At its core, the for loops are doing the heavy lifting. The first for loop in the calcRunningAverage() function is responsible for adding up and calculating the total average of the array. The second for loop in the loop() function shifts the whole array along as the program runs, once for each time the Geiger Counter pulses.
Keen readers may also notice we’re not actually adding the CPM directly to the averaging array. We’re first averaging the value with the array’s elements, then finally adding that result to the array (yes, a bit of a tongue twister!). This acts almost as an exponential averager to smooth it out further, but we’re probably going too advanced here so we’ll keep it simple.
The range of the panel meters needle will need to be tuned based on the gauge you’re using. We wrote our code for the 0-250CPM range, although you can use the conversion
rate to and from μSv/h to match up with the panel meter graphics we’ve provided. The logarithmic scales will also need to convert the radiation reading appropriately - the log10() function will likely come in handy.
/* LED bar management */
int led_bar = 255 - (millis() - last_count_time)/10.0;
led_bar = max(led_bar, MIN_LED_BACKLIGHT);
led_bar = pgm_read_byte(&gamma8[led_bar]);
analogWrite(LED_OUT, led_bar);
This code is for driving the LED bar. All we’re doing is creating a linear dropoff in brightness based on how long ago the previous pulse was. If the pulse just occurred, the first line evaluates to 255, or maximum brightness. If its been a few seconds, we should see a value of close to zero.
The second line ensures that the LED is always partially on even if the counter hasn’t pulsed, which adds a nice bit of backlight to help with the ambience of the whole build.
The third line may be confusing, but it’s what's known as a “Gamma Correction Function”. Without going too far into it, the human eye doesn’t respond to brightness linearly so we can significantly improve the perceived quality of the LED bar brightness by using a gamma function. We’ve left a link to some reading from Adafruit in the resources section if you’re interested in how this mathematical function works - it’s actually quite an interesting read.
We finally write to the LED output, which is on the LED_OUT pin.
Testing
This was probably the most fun we’ve had assembling a project in a while, so we had high hopes for the results!
Of course, testing a Geiger Counter is an interesting ordeal. We didn’t really want to buy a plane ticket to one of the various radioactive exclusion zones around the world just to test our project, so we had to find some other sources of radiation.
The first thing we tried was placing a partially disassembled smoke detector near the Geiger Counter. This was an Ionisation type smoke detector no longer in use at our office. In contrast to the common Photoelectric type, an Ionisation smoke detector has a very small sample of Americium-241 to create alpha particles and low quantities of gamma rays. The sample is mostly enclosed in an aluminium shielding to absorb alpha particles. However, some do escape which we were hoping to detect with our Geiger Counter.
After placing the smoke detector next to our counter, we let the averaging settle out and watched the CPM counter. In contrast to the natural background radiation of around 20-25 CPM at our office, the detector seemed to hover around 30CPM. It’s worth noting that because the sample size is so small, we’d really need to let the Geiger Counter run for multiple hours to see any results representing a real change. Qualitatively, the ticks definitely seemed to occur faster than they would from background radiation.
Something else that probably contributed to the low tick rate of the smoke detector was the properties of Alpha particles. Alpha particles have a hard time penetrating solid objects - they can be stopped by something as thin as paper. So, our hypothesis was that most Alpha particles are stopped before reaching the inert-gas filled area of our Geiger tube.
Next up, we tried a piece of Uranium glass, or Vaseline glass as it’s sometimes known. In the early 20th century, glassmakers often used to add small amounts of natural uranium (U-238) to create a pale green or yellow glass. Besides the appeal of the natural colour, when it is held under a UV light, the glass fluoresces a vivid green! We put the glass next to the Geiger Counter, and we measured around 40-45CPM. This is still within tolerance of regular background radiation, but the alpha particles emitted by the Uranium are substantially contributing. This proves that, in regular use, Uranium glass is not dangerous. We wouldn’t go drinking or eating out of glassware made from it, but its radiation level is so low that it’s not really worth worrying about.
We also took some awesome long-exposure photos with the Uranium glass and a UV light.
We could’ve gone one step further and tracked down some more radioactive objects to test, such as watches with Radium dials or real Uranium ore, but we’d probably have a hard time ordering some in without ending up on a government watch list!
Where To From Here?
One very interesting - and perhaps unexpected - application of geiger counters is in random number generators. For those who are new to the basics of software development or computer science, computers can’t generate random numbers on their own! They only can generate ‘pseudo-random’ numbers which, while random enough for the vast majority of people, aren’t truly random and still follow a very predictable sequence given the same initial conditions.
Radioactive particle detections are virtually completely random. If you use a moderately radioactive sample of material, getting enough random pulse samples would be an awesome way of generating a totally random and unpredictable number.
This project has also inspired us to look into some more radiation-based ideas such as a cloud chamber. We’d love to make one in conjunction with this Geiger Counter to visualise the natural bombardment of alpha particles, beta particles and muons from space.
If you built this project and want to share your results with us, be sure to clue us in on social media!
In Defence of the Banana Equivalent Dose, and Generally Being Inaccurate
There is often an amount of disdain held by scientists for the Banana Equivalent Dose. For those who have not encountered it, it comes from the fact that bananas have a high amount (relatively for food) of potassium, and a small percentage of this is a naturally radioactive isotope, Potassium-40. That means that bananas are slightly radioactive. One banana has approximately 1% of the natural background radiation a person receives.
There is no standard for the dose and the whole concept is an approximation. Some in the scientific community rubbish it for this fact, and there are valid reasons for this opinion. However, from an educational perspective, it is very, very valid.
When someone is learning about or unfamiliar with a concept, then relating it to what is already known or what can already be seen is highly valuable. When we are young, we learn that the sun comes up in the morning, and goes down at night, and we can observe this. We even still say ‘sunrise’ and ‘sunset’. Yet later, usually in year 5 or 6 in the curriculum but earlier from sources around us, we learn that actually the sun stays still and the earth rotates. The entire concept of ‘sunrise’ and ‘sunset’ is inaccurate, but it makes sense to us. Most importantly, this way of knowing the world around us does not stop us learning and understanding the more technical reality when we are ready for it.
We have used this principle in Kids’ Basics and Classroom many times. Sometimes, we have to corrupt the truth in order to make it into a processable unit of knowledge. This is usually when explaining things accurately means far too much information to absorb at once. The question we always ask is: “Does it matter?” If the simplified explanation gets the reader to where they need to be, then it is valid. If the full answer would be too much to absorb, then the reader will gain no knowledge at all. The object is to lead someone to a functional understanding of what they need to know. If the inaccuracy does not change this, then it is acceptable.
Often, the difference between the simplified or inaccurate version, and the reality, only make sense once more related or supporting knowledge is gained. Additionally, it often does not matter to those who are not engaging deeply with the topic. We have often used the phrase “That’s a bit simplified but unless you’re an engineer, the truth won’t change anything for you.” We stand by this. If the inaccurate version gets someone to the understanding they need to do what they want to do or follow what they want to follow, and the differences to the real version do not change that outcome, then trying to explain any further is irrelevant and purely academic. It also feels very high and mighty to do, and we don’t like that!
Much like trying to explain to a toddler that the earth spins and the sun stays still: It is unrelatable. Saying the sun comes up and goes down makes sense. Knowing that the earth spins and the sun stays still changes nothing for that person until they start to learn about the rest of Earth’s place in space. Even then, it doesn’t actually matter to most of us.
Likewise, putting things in terms of something someone knows already, even if it is an imperfect analogy, makes things understandable when they otherwise may not be. This is where the Banana Equivalent Dose comes in. Bananas are popular and no one thinks of them as dangerous (except the occasional fussy toddler). Talking in Sieverts, Absorbed dose, Rads, Roentgens, all of those things mean nothing to someone who has no real knowledge of radiation. Numbers in technical units also bewilder many people learning about an unfamiliar topic, especially when different measurement systems are used, like absorbed dose versus emitted radioactivity.
We can get closer to understanding something in terms of, say, a certain number of chest x-rays’ worth of radiation. However, this is still hard to picture. For someone new to the topic, knowing that some exposure is the same as eating ten bananas while another exposure is like eating one million bananas gives a relatable visual guide that can be related to what we know, and gives an understanding of the relative scale of radiation where other explanations fail to do so.