uRADMonitor - Online radiation monitoring station

[radu.motisan]

uRADMonitor is a network connected monitoring station, focused on continuous Environmental Radiation Surveillance. This capability is delivered by a digital dosimeter constructed around the highly sensitive Geiger Muller tube SBM-19. Additional sensors gather real time data on temperature , humidity and sky luminosity.

I made a presentation Video (please see it in HD and full screen):
http://www.youtube.com/watch?v=O4cqDWPrW50

Everything is packed in a homemade PVC box and placed outside my home, in Timisoara, Romania. The box is relatively small, and it takes only two connectors: power (6V) and an Ethernet cable for internet connection. From that point, everything is automated, it gets an IP via DHCP, and then starts sending data online every single minute.

On the other end, there's a PHP script, that takes the data, stores it in a mySQL database. From this point, we have everything in place for showing charts or analyzing Radiation variations in time, or in relation to other parameters monitored. This is doing research the fun way!

The image above is a real time data chart! . It shows the radiation data collected over the last 5 days, integrated at a 2hours time interval, with timestamps computed for GMT+3 (Europe/Romania). Try refreshing the page after several minutes to see the numbers change? How is this possible? Well I made it so:

By accessing the image, you are actually accessing a PHP script, that interrogates the SQL database for the radiation data. Then the data with a 1minute resolution is integrated (averaged) for a 2hours interval. A graph is generated on the fly, and the image returned, like you would have accessed a normal PNG file.

Of course, there's also a smart caching mechanism, to prevent my server getting killed by multiple requests: each time you ask for a graph, based on several parameters (interval, integration, gmt, data type, etc), the PHP script looks if the image has not been generated already, and if there is an image matching these parameters, it checks that it is not older than 2 minutes.

There's much to add here. I will probably structure it in several posts. This project contains knowledge gathered for more than one year. Everybody makes geiger counters nowadays, but crucial issues are treated superficially: dead time, energy response compensation, tube's life, driver circuits / inverters, and so on. I'll try to bring my part of contribution here.

Construction details are also available on my blog: http://www.pocketmagic.net/?p=2457 (it is a very long article)

Or more details on uRadMonitor's page: http://uradmonitor.pocketmagic.net/

[radu.motisan]

Let's take it with the beginning:

Part 1 - What is a Geiger detector
If you've seen my video in the previous message, you know that radiation cannot be detected with our senses. This is why we had to develop tools to see what our eyes cannot.
A Geiger detector is a device that can sense the presence of ionizing radiation . It is composed of a sealed tube with two electrodes to which a potential difference is applied. A particle entering the tube will initiate a conductive channel between the two, by ionizing the medium inside. When this happens, we can count the pulse, with a counter connected to the tube. The conductive flow needs to be quenched, so the tube gets back to the initial status and it is ready to start detecting again. A special gas is added inside the tube, for eg. halogens, that combine with the formed ions to neutralize them.

The number of pulses / time, gives us a new unit for describing the radiation, that we call DOSE. The simplest unit of measure is the CPM , meaning counts per minute. Some tubes are more sensitive than others, so two different tubes will show different CPM readings when placed to the same radioactive source. This means that the CPM value is tube dependent.

Also the tube's sensitivity might change relative to the incoming radiation's energy. Most tubes show a linear response only above 150keV. This means that a weak source of radiation, of energy below 150keV, will produce false readings on an uncalibrated tube, showing a bigger dose than there actually is. This type of calibration is called "energy response compensation" and it implies placing a thin shield made of lead, to reduce the intensity of low energy particles. This shield will have no effect on higher energy particles, so we successfully apply the compensation only to the interval of interest, by choosing the shield's geometry (covering the tube partially or completely) or by choosing its thickness.

Before one starts the road of building a geiger counter, not to mention a geiger dosimeter, a minimum knowledge of Geiger Tube Theory is a must! I recommend this book: http://www.centronic.co.uk/downloads/Ge ... theory.pdf

[radu.motisan]

Part 2 - the dose
As CPMs are tube dependant, other dose measure units are involved: grays, rems, sieverts, etc. You can read more on them here: http://en.wikipedia.org/wiki/Sievert
Assuming a tube is compensated for energy response, there is a linear correspondence between CPMs and uSV/h . This function is usually presented in the tube's datasheet.

If the tube is not compensated, a linear conversion function is still possible if we limit the detection interval to above 150keV, where the response is function of the number of particles counted, and not with their energy. See the attached picture:

6993 energy curve small.jpg

(45.33 KiB) Downloaded 232 times

This is also my case, since I am monitoring background radiation, that is out of the nonlinear interval:
"... a GM tube will be perfectly good for observing most background radiation because the three main terrestrial components of background gammas are K-40 1462 keV, Bi-214 1760 keV from the U decay series, and Tl-206 from the Th decay series. Smaller contributions to total background come from Pb-212 239 keV, Bi-209 609 keV, Tl-208 908 keV and Bi-214 1120 keV
As you know, the most serious non-linearity of energy response in uncompensated GM tubes occurs below 150 keV - and most of that below 100 keV - so none of the background emissions I've listed above will be seriously affected, nor will the majority of cosmic rays.
The most seriously affected - and, in many ways, the most interesting - part of the background gamma spectrum that will fall within the GM tube's most non-linear energy response region is skyshine - the radiation scattered by the air above both natural and man-made sources like particle accelerators, reactors, and high-level waste dumps. Most skyshine falls below 500 keV, and most of that below 100 keV. However, unless you live near a uranium ore body, or a nuclear facility, or we have another Chernobyl event, skyshine will not be a significant part of data gathered by a GM tube!
So, I would say that CPM to μSv/hr conversions using manufacturers data based on either Cs-137 or Co-60 will not be too inaccurate to be of use across the natural background gamma spectrum. An integration period of four hours should be used for reliable gamma background assessment.
" (Proud Mary, 4HV.org).


Currently my charts show the data in CPMs. Transforming that to uSV/h is easy, using the following formula:

(0.09 * cpm)/60

I was not to eager to implement that since CPMs show the natural variations just fine, and that covers most of uRADMonitor's purpose.

[radu.motisan]

Part 3 - driving the tube
The tube I've used, the SBM-19, uses 400V . This implied the need for an inverter, taking my low 5V and boosting it to a 400V, while keeping ripple or other variations to a minimum.
Using discrete components, this can be achieved with a simple oscillator, a ferrite transformer, and high speed diodes for rectification. Depending on the transformer, a multiplier may or may not be required.


This works just fine, and you can see it in action in this Youtube video, working with several Geiger tubes:
http://www.youtube.com/watch?v=sJMngwBTXvw

For my uRADMonitor, I wanted to have the tube's voltage generated with PWM, directly by the microcontroller. For the Atmega168, I used the Timer1 to generate the PWM. A feedback connection via a voltage divider, takes the generated voltage and feeds it to an ADC port. If the voltage is less than 400V, it increases the PWM's duty cycle. If the voltage is in excess of 400V, it reduces the duty cycle. Nice and easy, and extremely efficient: Compared to the previous version with discrete components (I named that v3.2), the ripple is almost zero! See the two photos below:

ripple_geiger_counter_1.jpg

(34.32 KiB) Downloaded 232 times

ripple_geiger_counter_2.jpg

(23.16 KiB) Downloaded 232 times

The first, shows my version 3.2 inverter output, that uses a NPN oscillating transistor in an Armstrong oscillator, and a feedback mechanism constructed with zenner diodes set for 400V, that triggers an oscillator-blocking second transistor. Illustrated as trace for CH1 - yellow, set for 400V.
The second shows the output in uRadMonitor (version code 3.3.X), fully rectified and produced by a a precisely calculated PWM signal. See the CH2, cyan trace, set for 350V. That was only for testing, as the feedback mechanism now sets the voltage for 400V.

But there were many issues, that took me considerable time to have them solved. You can read about some of them in my construction log:
Issues with Timer1

[radu.motisan]

Part 4 - Network interface
I opted for enc28j60, based on previous experience with this chip. Initially I planed to use it with an atmega8 microcontroller, in the uRADMonitor project. But the memory proved to be insufficient for the growing software, as the development advanced. I had to use the Atmega168.


The device works as a client: at first it asks for an IP via DHCP, so it is plug an play at its best! Then it starts logging data which is exported to my server every minute. The data includes radiation data and sensor data.

You have the option to use a buffer between the microcontroller and the Ethernet chip . But it will run fine without it as well. I've discussed both options here: http://www.pocketmagic.net/?p=2457#121011

[radu.motisan]

Part 5 - the Waterproof enclosure
These days it rained, so it was a good test for my uRADMonitor placed outside. The box was made out of a PVC pipe, but it's the nice orange type, which was thick plastic. I love it! It was the touch of a quality case

I will not overload this thread with tens of pics. If you want to see them all, they are available here: http://www.pocketmagic.net/?p=2457#121019

[radu.motisan]

Part 6 - Getting the data
In case you're more interested in checking the radiation data variations, than the hardware details, you're in the right place. The device collects readings every single minute. This means that every single day, I get 24x60=1440 values for the background gamma radiation. Same for temperature, humidity and luminosity. Soon a pressure sensor will join in.

You can get this data too. I've developed a PHP interface, to let you generate charts on the fly. Here is how:

Currently I provide a simple interface to access the data collected by uRADMonitor #1, working in Timisoara, Romania. For server-side optimization reasons, the data is cached. Every time you access the data, you will receive charts not older than 2 minutes!
The data can be accessed as pre-generated charts, of variable parameters, via a HTTP-GET:

Code: Select all

http://www.pocketmagic.net/uradmonitor/public.php?param=STRING&interval=VALUE&integration=VALUE&size=STRING&gmt=STRING_URL_ENCODED

param: cpm|temp1|temp2|humi|lumi identifies the data: cpm for radiation, temp1 for temperature sensor #1 (DS1820), temp2 for temperature sensor #2 (DHT-11), humi for humidity sensor (DHT-11), lumi for luminosity sensor
interval: the last number of days data to retrieve. The uRadMonitor #1, started gathering data on October 21, 2012
integration: the average interval in hours. For better observations of the natural background radiation level , you should use a value of 4 (hours).
size: small | medium | large | xlarge
gmt: the gmt for the time coordinates, url encoded (default is Europe/Bucharest)

Try the following examples:
Example 1. The Radiation data on the last 3 days (3x24hours) with an integration average of 4 hours (each point in the chart represents the average of 4 hours of sensors data), with a chart size of 1200x800 pixels, and time displayed with GMT corresponding to London, UK.

http://www.pocketmagic.net/uradmonitor/public.php?param=cpm&interval=3&integration=4&size=xlarge&gmt=Europe%2FLondon

Example 2. The temperature data on the last day (1x24hours) with an integration average of 1 hour1 (each point in the chart represents the average of 1 hour of sensors data), with a chart size of 400x250 pixels, and time displayed as US Eastern time.

http://www.pocketmagic.net/uradmonitor/public.php?param=temp1&interval=1&integration=1&size=medium&gmt=US%2FEastern

[radu.motisan]

Part 7 - Conclusion

We here have a device that looks like this:


And works like this:
http://www.youtube.com/watch?feature=pl ... 4cqDWPrW50

You now know most of the details regarding uRADMonitor. Hope you like it Let's sit an wait and let it collect the valuable data. We'll have something to analyze one year from now.


Greetings from Timisoara,
Radu Motisan

[radu.motisan]

Added graph in uSv/h :

[radu.motisan]

The device works extremely stable - showing an almost constant radiation dose out of all those near-random CPM readings. After all, there's a steady cycle of those isotopes in nature, I'm just surprised to see that the device measures this correctly, without any interferences .

I expect to see the dose rise when the rain falls, because of short lived radioisotopes produced in radon disintegration.