« Use of standard deviation as marker for temperature event changes with Phidgets IR temperature sensor | Main | More Sparkfun geiger counter explorations »

Saturday, December 01, 2012

Sparkfun geiger counter - initial explorations

One of the things I've got to stop doing is looking at electronics sites late at night. While perusing the sparkfun.com website, ran across a geiger counter at a reasonable price ($150). This was something I knew I needed and so also ordered a bunch of other stuff at the same time as dealing with customs duties is a hassle so might as well get a bunch of other things I just can't live without.

The geiger counter itself is trivially easy to setup; just plug it into the USB port of ones computer and, assuming that one has the serial USB drivers installed (where to get them is given on sparkfun site), one can immediately see background radiation counts appearing on a terminal emulator which receives the output of the sparkfun device The geiger counter appears as a serial device to the system and transmits data at 9600 baud (a bit sedate if one is counting very radioactive sources).

Geiger counter output consists of the digits '0' and '1' which indicate whether the previous interval is longer or shorter than the current interval between counts. This output wasn't really that useful to me so I wrote a quick VB6 program which timed the occurrence of events to 1 msec precision and stored them in a csv file.

First thing to do was to measure background radiation and, in a basement in Kamloops BC, I get an average of 15 counts/minute (cpm) as background radiation. Then, took the first known radioactive source that I could find and put it in front of the geiger counter to see if I could pick up the radiation. (Still looking for my bottle of U2O3). The radioactive source was a bottle of potassium citrate capsules. Gratifyingly, the number of counts/minute increased and I got 20 cpm with the bottle of K-citrate in front of the GM tube. Taking it away made the number of cpm drop back to 15; a very nice demonstration that I could work with weak radioactive sources given a long enough counting period.

The radioactive isotope in K is K40 which is a beta emitter and K40 makes up 0.0117% of K. K40 has a half-life of 1.27 billion years meaning that a gram of KCl should have about 15 disintigrations of K40 to Ar40 every second. The bottle of K-citrate I was using had about 0.76 moles of elemental K contained within it which means that it would be producing about 668 counts/second or 40,058 cpm. I only picked up 5 of those cpm or 0.01% of the K40 disintigrations that one expects to be taking place in the K40 known to be in the bottle. A rather low count efficiency, but I was surprised that I even could pick up K40 radioactivity with a cheap geiger counter given that all of my biochemistry labs had used far more radioactive tracers than K40.

Next step was to figure out how best to display the results. The raw count data is quite random looking as expected:

What turned out to be more useful was to integrate the interval data to produce a graph of elapsed time vs counts. This is the red line in the graph above. The slope of the line is 2979 msec which, coincidentally, is the mean inter-event interval. This is a damn good approximation to a straight line with correlation coefficient of 0.9999; it doesn't get much better than that.

So, next step was to plot the integrals of background counts and K40 counts on the same graph to see how long a sampling period would be required to show up a difference between the two cases:

The red line is background radiation with a slope of 4025.9 and blue line is K40 source with average inter-count interval of 2979 msec. It's quite clear that one can separate these lines easily by eye even with as few as 500 counts. The shorter the inter-count interval, the lower the slope of the line as it takes fewer counts to get up to a given total time. Not bad for a $150 device.

Next step was to look at the distributions of the counts on a histogram. The histogram below is for K40 counts.

Expected shape of the distribution is a Poisson distribution but this one looks a bit funny; there seem to be too many counts in the 0-99 msec bin. One way of checking on this is to look at the same histogram, but now plotting the log of the count data:

The equation for a Poisson distribution involves a term e^(-lambda) and the shape of the distribution that one gets here would require lambda of around 1 or less. Thus, one would expect a log transform to give a straight line. Actually eyeballing the line is a better way of showing that there are too many short intervals. (I might be wrong on this).

Another way of checking whether one has too many short intervals is to look at the data and the one thing that immediately struck me was that the number 47 appeared far too often. What I suspect is happening is that the very simple low pass filter that the Sparkfun geiger counter uses is producing several events for a single GM tube electron shower. This is something that can be confirmed in the future by looking at the shape of the GM tube event on an oscilloscope (actually will have to use a Phidgets A/D converter to acquire this data and have to get motivated enough to write the code). The excess of short intervals that one sees is the analog of an improperly debounced push button. Something which will be easy to fix by sampling the raw GM tube analog output and counting events in software using a lot more powerful CPU than the microprocessor on the Sparkfun board.

Next thing to check, if one is using the Sparkfun geiger counter as a source of random numbers, is to verify that the waveform of Interval(count) has a spectrum equivalent to white noise. For the K40 data:

And, as expected for white noise, when one does a log-log transformation of the FFT, one has a slope of 0. So far so good. Then, out of curiousity, I decided to look at the residuals from the fitting of a line to the integrated intervals as a function of count. First the residuals:

When I first saw this I thought it looked like 1/f noise (have been spending far too much time in front of DPlot looking for 1/f noise in various things). Sure enough, when one does an FFT and log log transformation one gets:

The points fall on a straight line and represent 1/f^-0.9 noise (actually count^-0.9). This is odd as what's supposed to happen when one integrates white noise is that one gets Brownian motion with 0 memory, not 1/f noise. Time to get back to some mathematical basics as it's been over 20 years since I've worked in this area and am going on faint memories that still exist in parts of my wetware that haven't been hijacked to store medical knowledge.

So, while the Sparkfun geiger counter is more sensitive than I thought in detecting radioactivity, it likely is too biased to use as a source of random numbers. The nice thing about Sparkfun products is that they are completely open source and the schematics are available on the Sparkfun site as well as the source code for the microprocessor which digitized the GM tube output and outputs it on a USB serial port emulation. Don't know if there's enough RAM/flash on the embedded processor to perform more fancy "debouncing" algorithms on the filtered GM tube output, but such operations are easy to do in software if one instead samples the OUT signal from the Sparkfun Geiger counter.

The VB program that I used to capture inter-event intervals will be put online once I've cleaned it up. It still crashes when I let it run for too long a period of time which is unacceptable and one other option I want to include in it involves reading the CPU's TSC whenever a serial event occurs. The low bits of the TSC can be used as random bits although this has to be subjected to testing as the delays between windoze recieving a packet on a USB port to the data finally being available to the MSComm control in a VB program may be deterministic enough that even the low bits of the TSC can't be considered to be random. What I'm using to perform 1 msec timing now is the windoze system call TimeGetTime which accesses the 1 msec clock.

Posted by Boris Gimbarzevsky at 11:52 PM
Categories: Embedded systems