Project Logs

Collapse

• Disappointing, but Not Unexpected

  Dave Ehnebuske • 06/02/2018 at 18:18 • 0 comments

  Well, I've now logged how many clicks my Geiger counter saw each minute since some time on May 20. It's more than clear that the click rate is falling gradually. When I first became suspicious a while back, the rate was about 50 clicks per second and now it's about 45. The radioactive source I'm using is the little dot of ²²⁶Ra stuck right up next to the GM tube that I've used for some time now. Here's the data:

  As with earlier charts, the blue line is the average of the whole run up to that point and the red line is an exponentially decaying moving average with a decay period of an hour -- a measure of the behavior during the previous hour. For my purpose -- building a timebase -- this is not good at all.

  I'm relatively certain the problem is with the long-term stability of my Geiger counter, not the physical setup or the radioactive source. It's still possible, I suppose, that there's an environmental problem (e.g. variability due to Rn), though there's no obvious diurnal pattern to the data or correlation that I can see with the weather.
  

  Time, I think, to look into a different (type of) detector to see how it behaves over time. I need to do some research on the alternatives.
  

• What Counts as "Flying"?

  Dave Ehnebuske • 05/12/2018 at 17:25 • 0 comments

  Observation shows that the change in the click rate for my Geiger counter has, for now at least, stopped changing (so much) over time. Here's the data from a recent run of well over a day:

  As you can see, the average is no longer falling as it was. In fact it's behaving within statistical limits. If it had behaved this way from the beginning, I would not have become suspicious it was changing.
  

  Quite why this should be, I'm not at all sure. Maybe the brand new Geiger counter just needed to run for a while, and now all's well. Maybe it's just not very stable? Maybe its sensitive to "the phase of the moon"? I haven't found anything yet that would indicate it's fundamentally unstable or subject to malign influences, but then I wouldn't: its been stable for a while now.
  

  Such as it is, that's the good news: results so far don't rule out getting this to work. But there's bad news, too. A little research shows that the sensitivity of Geiger counters of the sort I'm using tends change over time. None of the sources I've found say why the sensitivity changes, but people talk about needing to calibrate "survey Geiger counters" against a standard every few months. That doesn't bode well for what's supposed to be a source of truth. I'm beginning to worry I need a different sort of detector.

  Research, both into stability and into alternative detectors continues.
  

• Pig Airport

  Dave Ehnebuske • 05/05/2018 at 16:17 • 0 comments

  Well, I built the first version of a complete clock using the Geiger counter, an interface shield, an Arduino Uno and a Lavet motor clock display. The Arduino sketch uses detected clicks from the Geiger counter to figure out updated guesses estimates of how many Arduno micros() there are in a standard second and uses that to drive the clock display. The idea is to calibrate the speed of the Arduino's not-too-accurate ceramic resonator clock using the count of the decays detected by the Geiger counter.

  While I'm pretty happy with the way it works, continued observation of the click rate from the Geiger counter worries me. The click rate continues to decline slowly with time. At the beginning of the week it was just under 51 clicks per second, now it's just under 48.  Since I don't want to build the equivalent of  "pig airport" -- a bunch of fancy, complicated infrastructure based on the fundamentally flawed idea that pigs can fly -- I need to figure out why the click rate is not constant.

  As [Thomas] observed, there are several critical aspects of the way the Geiger counter detector is built that could be the cause of what I see. I've tried to make sure the radioactive source itself is stable and in a stable relationship with the GM tube. So, I'll look first at things I haven't tried to control. For example, perhaps the voltage on the GM tube is wandering around. Or maybe changes like this are just what one sees if a Geiger counter is run continuously for a week. For that I'll need to do some research.
  

• A Longer Run

  Dave Ehnebuske • 05/02/2018 at 14:46 • 0 comments

  To test whether the slow decline in the click rate I saw in the several-hour run I talked about a few days ago, I did a much longer run using the same setup as last time. Here is the result:

  As with the chart from the previous run, the blue line is the average number of clicks per second to that point in the run. The red line is the moving average with a decay of an hour. This run is ambiguous enough that I've decided to carry on with the experiment using a "hotter" ¹³⁷Cs source Getting one could take a while, so in the meantime, I'll assume things will work out and plan to carry on with developing the code for the 1Hz timebase.

• New Radioactive Source

  Dave Ehnebuske • 04/30/2018 at 16:37 • 5 comments

  After an extremely productive discussion here on hackaday.io, I decided to change the source of decay events I'm using. I swapped out the ²⁴¹Am source for a ²²⁶Ra source I had obtained a while back on fleaBay. It claims to be a 6k CPM source intended for calibrating old Civil Defense Geiger counters from the cold war days. ²²⁶Ra breaks down to ²²²Rn by emitting an alpha particle and a gamma photon. (See the radium decay series chart here.) My Geiger counter doesn't detect alpha particles, but it does detect gamma photons.

  The idea here is to raise the rate at which decays are detected to the point where I get enough of them that the statistics will produce an acceptably accurate clock. The mathematics are covered on a very useful page (here) that [Ted Yapo] brought to my attention. What it nets out to is the higher the rate of detected decay events ("clicks"), the more accurate the clock. For example, I need at 168 clicks per second for the clock to achieve (within 1 standard deviation) a 1-minute-a-week accuracy. To achieve a 1-minute-year accuracy, I'd need to detect 8760 clicks per second.

  So, I swapped in my ²²⁶Ra source and measured the click rate against a realtime clock with an accuracy of 2 sec/year. So far, the result is a little disturbing.
  

  The good news is that the rate is up quite a bit. The average over the 15.5-hour run is a little over 50 clicks per second. That's not enough. I need more than three times that many even to get to an accuracy of a minute a week. It looks like I'll need a much "hotter" source. More disturbing is that, so far, the average shows a trend:

  During the run, the number of clicks detected was measured once a minute. In the chart, the blue line is the average of the click rate over time. The red line is the exponential decay moving average with a decay period of an hour -- basically a measure of the rate during the course of the preceding hour. As you can see, both measures decrease with time.
  

  Ack! Where did that come from? Is my Geiger counter getting tired of counting this quickly? An artifact of running for too short a time? An experimental error? At 50.9 clicks per second and 15.5 hours of run time, the SD is 5.9e-4, so the decrease looks like it could be real.
  

  Time will tell. I'd welcome your thoughts.
  

View all 5 project logs