Standard counter screen

[Doug Coulter]

Screenshot of standard counter output with two cal sources and background. Log y

Software testing the output of the standard counter design. Red's the one second result, green is the simple moving average over 10 of those, and blue is a lowpass leaky bessel, off the 1 sec input, coef A = 0.03. Gnuplot is doing a lot of the work here. Most of the perl is finding the doggone thing out there on USB and pulling lines out of it, then changing them into arrays of numbers to plot, which is the sort of thing perl is good for.

[Doug Coulter]

Here's another one. This could go on any of several threads, as it's about metrology, statistics, hardware, software, signal processing, but it's also pretty, so here it is.

An hour of background shown a few ways

This is showing the output of the standard counter for about an hour's worth, shown in a few ways. Notice the CPM-1 (red) can only show zero, or multiples of 60 -- that's because of the one second sampling time for that, on which all the rest is based. A time quanta if you will -- and during that time, you can only have integer numbers of counts. The green is a ten sample simple moving average of those -- as you can see, even it bounces around quite a lot. The blue is a simple bessel filter (same as an RC filter) on the 1 second capture data, one that takes a few hundred seconds to fully "catch up" when a loud cal source is put on the counter, as in the previous post.
Note that even that heavy smoothing has ripples and never converges to a smooth average, though with some eyballing you can get an average of about 27 cpm out of it (gnuplot helps as it reports the cursor position in graph units down in the corner). Also note that even with a bit of processing, when you just don't have much data (see the total counts on the terminal view), you just don't have much data to work with, and radiation, whether from a rock or the universe, is the most random thing there is.

A trained eye can get a lot of this by squinting a little -- see where the red lines are denser, and the other displays go up? But most of us like to have the power of a bit of processing, if we can have it, and here it's pretty easy to do.

In the previous post, you can see that when a medium hot source is there, the "simpler" outputs get a lot "quieter" and more smooth all by themselves -- the power of statistics once you have enough data does this with no meddling required. As these are log plots, you are really seeing the signal to noise ratio whatever the signal is at the time, and these are quiet enough with no source that you see how noisy a low rate random event string really is. This is why it can take a long count and careful use of math to see things near background and be sure about it -- the background itself is moving around a lot. There are of course tricks for when the background is mostly coming from "up", such as using another counter in anti-coincidence, but even that reduces the basic data rate -- and the result is still noisy, maybe even worse! Luckily for the intended use of this thing, silver isn't hard to activate to over 500 cpm (which really stands out in a non-log plot) for at least the first few ten second intervals. And indium, while it doesn't get as hot for the same exposure, lets you count a lot longer to be sure of the increase over background better. Should anyone start making really significant neutron counts, we can move to gold...

And yes, down the road, we'll enable some curve fitting....silver, with all the possibilities and metastable states is going to be interesting indeed when exposed to that, there's a lot of cooks for that stew. Indium should be more boring...

Now that I've got this in a box and can carry it around without worrying I'll break it, I'll try a fusor run with some Ag and In and see how we do with it, and compare to our previous standard, which was about twice the sensitivity for X rays, but maybe not that different for betas. Nothing beats a guess like a measurement, though.

For those who don't know how to do that bessel filter in math, here it is.

Coefficient A is .03 in this case. B is 1.0 - coeff A. You need one memory location, I call the accumulator. The math is like this:

new value of accumulator = new input * A + old accumulator * B;

And that's all there is to it. This leaks 3%, as though you had 3 percent of the series R in series with the cap, instead of taking the output off the cap top purely. Breaks of the game, the pure bessel is a little more complex to compute. This one nicely has a gain of precisely one, and can be augmented by various logic tricks to make it track in quicker when it's way off in some situations.

For those who might worry that we skip counts on second boundaries, no, we don't. The counter is hardware and just counts, we read it at one second intervals and never reset it. There's a hardware re-sync flip flop buffer, so if we miss a count that "belonged" in one second, it just shows up in the next sample. Being 32 bits, it should be enough....

[Joe Jarski]

Nice! Besides the standard counter, that would be a fun one to use for monitoring background 24/7. I might have to watch for a large GM tube or maybe put together a PMT for that.

OK, after confusing myself a little bit over the multiples of 60 and having counts per minute every second... would it be better to send the raw CPS numbers (CPS1 & CPS10) to the PC instead of converting it to CPM in the PIC? Or maybe just send actual counts per second to the PC and then let it add up the the last 10s and last 60s? I'm just thinking out load here because the standard counter doesn't have a display for the count rate.

[Doug Coulter]

I chose CPM because it's the standard everyone uses, and it's a lossless conversion we can do whatever we want with at the PC end where "heavy math" isn't so heavy. In the PIC we multiply the per second count by 60, and after adding up the last ten of them, by 6. All integer. So you can do pretty much anything you want later to convert, no information is lost. The basic problem of the "quanta" remains either way. Instead of seeing say, 0,60,120, 180 cpm on background (don't think I've seen a 240 yet), you just get 0,1,2,3 - which has the same signal to noise ratio and quanta - the multiplication or lack of that doesn't change anything but the scale. The motivation for using the CPM is that everyone knows what it means, and so people who don't want to deal with the fancy PC software can just use a dumb serial terminal program and get the data in as human-readable form as I could get it (most serial terminal programs will also save to a file). For example, it would have been simpler to not have the column labels as well, but -- after any initial line scrolls off the screen, you'd have to remember which was which. Or you'd have to have a scheme that puts those out only every nth line - but then PC software would have to deal with that, and this might confuse any simple data import to a spreadsheet for example.

There is a possibility we will add a config file for this program, and allow you to put in any fudge factor you want to (this would be floating point). The idea behind that would be to "normalize" all these so they all show precisely the same numbers when exposed to the same calibration source. When I get a GUI done for the PC end of things, that can be an option pretty easily. Right now, you just run this program from the command prompt.

Yes, for long term monitoring, there are several better sensors you'd choose from. Either a large area pancake or a big tube like John Strong showed (he had some 6" diameter and 4-6 feet long), halogen quenched, or perhaps a phototube-scintillator, which can be very stable.

Phototube sensors have one potential large disadvantage, or at least difference, for background monitoring, compared to something slower like a geiger tube. In a radioactively clean lab, like here, most all the background is from secondary cosmic showers, where the primary cosmic (probably a proton) hit something above you (probably an air atom, but maybe one in your roof) and created a shower. Experiments with coincidence counters have shown these showers can be large (lots of particles and gammas), and very wide -- hundreds of meters at the ground. All this "junk" has varying mass and energy, and therefore varying speeds. This means that if a shower starts well above you, something with great time resolution (like a phototube -- typical might be 5 ns) will count a varying number of times for what started out as a single event -- it can resolve the arrival times of some, but not all, of a burst. This would be more accurate in the case of calculating a dosage on something, maybe (really, you'd want a spectrometer for that) but for simple monitoring, this "some large but incomplete number of counts per primary cosmic ray" actually makes the problems shown above much worse -- you're adding another noise source, in essence - the variability of how many counts you get per primary. Your detector may not see them all, but it will see a few per event, and it can still miss some that actually hit it because they might not vary enough in transit time to the detector to no just pile up into a single larger pulse.

It's actually a medium-fascinating problem, and the usual evil words "it depends" never applied more than to this one. For what the standard counter is meant for, the slow response, which is just slow enough to "smear out" almost all cosmic bursts, is actually ideal -- and that wasn't an accident, it's by design, implemented by the detector chosen. This gives a closer mapping to one count per cosmic event, instead of a random, but large number of counts per event -- depending on which hit, which miss, how close the shower generation was, and so forth.

For measurements of very low activations, the very best setup would use two geiger tubes, one above the other, with the top one negating any simultaneous count from the bottom one, which gets your activation sample. Unfortunately, this greatly increases costs, and can't fully fix the problem -- there will still be errors, cosmics that don't make it through both, counts from the sample that just happen to occur at the same time as a cosmic event, and so on.

Like I said, a fascinating problem. In this case we are taking advantage of everything we already know -- we're NOT going to be working all that close to background for one thing, so most of these questions just go away - for this use. Once we have this basic PIC platform going, we can of course add whatever we want over time. This is early days for this. I envision some other incarnations for other uses, but for this use -- counting activations, I can't think of a way to make it any better at this point.

Now, it's your job to take this butt-ugly thing and make a nice PCB and nice robust packaging for it, with the idea that over time, there will be different uses of the basic platform, and our NRE is a significant cost at the low likely volumes any of this will be produced in. At the moment, I'm very pleased with how this one works, and how well the unit to PC interface works - we've got a solid basis to build on now.

Current WW prototype. Big and ugly, but built to facilitate trying other things with the platform.

For those who don't know -- Joe and I are both working on this one (and several other projects), and plan to have a little company to produce these and other things useful to amateur scientists like ourselves. We don't expect to make a lot of money at this, it's more for lulz, and because we realize we're pretty good at some things others don't have the time to acquire the skills for and do for themselves, but merely want to get on with whatever their own research is -- without paying the normal insane industry prices for gearing up. For those who remember Don Lancaster's SWTP -- boards and bags 'o parts, or built units, that's kinda what we have in mind here - facilitating other's work by making some things a lot simpler and more affordable. We just have a different focus than Don had, in our case a smaller market -- and somewhat more sophisticated gadgets, useful to physics people rather than audiophiles. Look for more in the future. The next thing on my plate is to do a good vacuum station controller for those cheapo Pfeiffer turbos (I have 4 of those, thanks to BillF) and whatever forepump you've got, with some unique capabilities, as in fine gas flow/pressure regulation for processes like fusors, accelerators, ion sources, and sputtering to be controlled, and logged if desired. We have a few more things on our short list (for example, neutron detector tubes and the equivalent to this but for neutrons), but....with just two of us, it's a good idea not to divide our attention too widely just yet. We'll get there.