Detailed Instructions for Using Pachube in 1.3.4b+NOTE: Cosm/Pachube information has been removed as it is obsolete with acquisition as Xively. This feature is now deprecated due to changes in the service by Xively.
Conversion Factor: (変換係数)
- Unit display: CPM, mRem/h, µSv/h
-1 Roentgen = 1 Rad = 1 Rem, for gamma/beta and whole body exposure.
- CPM is converted to mRem or uSv by a conversion factor. (変換係数)
- For conversion factor
x: (変換係数)
1 mRem per hour = 10 µSv per hour = x Counts Per Second.
Conversion factor (変換係数) is usually calibrated to gamma activity from a Co-60 or Cs-137 source. It is specific to your tube, the radioisotope, and type of radiation. It is usually given only for gamma radiation. (actual gamma sensitivity is something like 1-10% depending on the isotope)
As an approximation, use 10 for smaller tubes, and 20 for large tubes (like the SBM-20).
Of course, most of the time you will not know the exact isotopes you are measuring -- even when you think you do. For example, for uranium, you do not measure the uranium directly-- you measure its decay products, chiefly Pb-214/Bi-214 (and others).
So the conversion factor is less of a true scientific assessment of biological dose equivalent, and more of a way of comparing the sensitivity of the detector. Even professionally calibrated detectors only have valid calibration for usually a single isotope.
Sample Conversion Factors: (変換係数)
For a Kvarts DRSB-01 (SBM-20 tube):
- Co-60: 22
- Ra-226: 29
For a CDV-700:
- Co-60: 10
For a Gamma-Scout:
- Cs-137: 25
Technical Info about Audio Engine Changes in 1.3 (deprecated in 1.3.3+)With version 1.3.3, you probably don't have to worry about this stuff anymore. So just ignore it, unless you want to tweak numbers. Note that RMS window is still actively used by auto adjust mode, and delay windows is used as auto adjust's minimum dead time setting.
s ------->Y-Axis range: -32768 .. +32768
① 実効値測定間隔 (16 サンプル)
② ディレイ間隔 (14 ×実効値測定間隔)
③ 1 バッファ (512 サンプル )
- 1.2: Delay = 23 to 46ms
- (42 RMS Windows (×実効値測定間隔))
- 1.3: Delay =
10ms- (14 RMS Windows (×実効値測定間隔))
- [DEFAULT]
- Recommend
5ms at high count rates
- (7 RMS Windows (×実効値測定間隔))
- Low volume threshold (音量しきい値) value: very sensitive, easy to set off
- High volume threshold (音量しきい値) value: takes high volume to reach, less sensitive
- Recommendations:
- High count rate:
8000- General use:
10000- [DEFAULT]
- Graph #2 shows current RMS power (実効値電力) (x1000 scale)
- Set refresh rate (
画面リフレッシュ) high temporarily to best visualize this
- NOTE: high count rates have reduced volume per click:
- RMS window (実効値電力): you should probably leave it alone
Determining Your Counter's Max Count RateLet us examine the Kvarts DRSB-01 (
1). The speaker is decoupled from the GM tube with a 22 nF capacitor, and the voltage is reduced by a 1M resistor. Using a first order Padé approximation (
2) the delay is 2 x R x C. Or 2 x 1x10
6 x 22x10
-9, which equals 0.044, or 44 ms. That's 23 CPS or 1364 CPM. (the actual rate will be slightly below that)
Therefore, the theoretical maximum count rate of the Kvarts DRSB-01 going into the speaker is ~< 1364 CPM. As it uses a SBM-20 tube with a conversion factor of 22 CPS/mR/h for 60Co, that is a maximum reading of about 1 mR/h or ~10 µSv/h. Or for 226Ra, ~7.93 µSv/h.
Summary:
Delay
| Max CPS
| Max CPM
| 60Co Max | 226Ra Max
|
44ms | 23 | 1364 | 10.05 µSv/h | 7.93 µSv/h |
This matches my empirical data, where stacking three radioisotopes that measure approx. 900, 700, and 500 CPM separately measure only 1200-1300 CPM combined.
Also, the LEDs: they both max out at ~2 Hz (540ms refresh). However, the red one (
ВНИМАНИЕ) only lights up at 8+ counts in that 540ms period.
Therefore, in a 1s period:
LEDs
| Counts
| ~ CPM
| 60Co µSv/h
| 226Ra µSv/h | Visual Aid
|
G
| 1 | 0 - 60
| 0 - 0.45
| 0 - 0.34 | G blinks intermittently
|
GG
| 2 - 7
| 120 - 479
| 0.90 - 3.63
| 0.69 - 2.74
| G blinks steady and fast
|
GGR
| 8 - 15
| 480 - 959
| 3.63 - 7.27
| 2.75 - 5.50
| R blinks at half the rate of G
|
GGRR
| 16+ | 960+
| 7.27+
| 5.51+
| R and G blink equally
|
(printable version)
60Co:
LEDs
| CPS
| CPM
| µSv/h
|
G
| 1 | 60
| 0.45
|
GG
| 2
| 120
| 0.90
|
GGR
| 8
| 480
| 3.63
|
GGRR
| 16+ | 960+
| 7.27+
|
226Ra:
LEDs
| CPS
| CPM
| µSv/h
|
G
| 1 | 60
| 0.34
|
GG
| 2
| 120
| 0.69
|
GGR
| 8
| 480
| 2.75
|
GGRR
| 16+ | 960+
| 5.51+
|
Sources:
(1) Kvarts DRSB-01 Geiger Counter USB Mod
(2) An Accurate Analog Delay Cicruit
(3) My HP48GX
New!Polimaster PM1703 ThoughtsThe Polimaster PM1703 is a relatively boring pager-sized scintillation counter, with an outstanding gamma sensitivity of 1000 CPS/mR/h and the price tag to match. Waterproof, shockproof, over a month of battery life.. it seems like it should be on an entirely different playing field than a Geiger counter. It is, and it isn't.
As a scintillation counter the PM1703 only detects gamma and x-ray radiation, unless you get the model which also detects neutron radiation. Scintillation counters can have much greater performance, but not the versatility of a Geiger counter in measuring multiple types of radiation.
The PM1703 is a very lazy radiation detector. Even when you adjust the z-score on the statistical model it uses down from the default of 5.1 (99.99997% confidence interval) it can't be bothered to get excited by mildly radioactive objects. The display will happily filter outliers away and not let the uranium glass marbles of life trouble you. There is no individual count output. It does have a mode to scan for radiation, and while it easily outperforms the Soeks when it is 'woken up', it does not detect things at a greater distance than the Soeks prior to that point.
No, the PM1703 uses its high sensitivity to do something quite different --
not alert you to radiation. It is very very good at eliminating false positives. And it also uses this sensitivity to determine this in a very short period of time, meaning it can quickly sweep by something radioactive and pick it up where a Geiger counter would have missed it.
To be clear, it has three main modes; one is a display of the DER with a longer integration count time, a 'search' mode that displays the DER with a shorter integration and is more sensitive for searching (oddly denoted with a 'R' if your unit is in sieverts mode instead of rem mode), and a DE (dosimeter) display. So while it has a specific mode for use as a survey meter, it's just not what it could be.
You're not going to be able to use the PM1703 to build an online radiation database for a map. Or use it with Geiger Bot. There is nothing to tweak, to modify. The logging it does is relatively uninformative. It is what it says it is-- a personal radiation detector/dosimeter. And it does what it says it does very, very well.
I would strongly recommend this to anyone in Japan who is obsessively checking radiation background levels because it measures them very well and very accurately; if you wanted a personal device to carry with you this is the best you can get that I have seen. But don't expect it to blow away your Soeks or Radex at finding mildly radioactive sources, because it won't. And that is sadly a software limitation of insanely sensitive hardware.
UPDATE: There is also a better model which I previously thought had been discontinued, the PM1703MO-1B, which connects via USB/Bluetooth to a Windows Mobile PDA or WinXP+ PC. It does, in fact, do GPS logging on the PC with an external GPS, as well as gamma spectroscopy as isotope correlation. However, it's $4500 USD (350000 JPY) and the only online source I'm aware of is this site in Japan.
New!Gamma-Scout Alert ThoughtsThe Gamma-Scout is an interesting device, its main distinguishing feature being its intended 10 years of continuous operation off a single battery. It also has a mechanical aluminum filter switch for blocking alpha or beta radiation, logging, computer connectivity, and is (supposedly) calibrated. The manual seems to be particularly proud of the fact it has an entire 64KB of memory for logging data. To be fair though, I can't think of another device that has meaningful logging as the Gamma-Scout does. For a Geiger counter it is relatively 'smart', and has a number of features I've not seen on other detectors. Unfortunately, it's a more impressive device in theory than in practice.
The Gamma-Scout uses a LND-712 tube. The gamma sensitivity of this tube does not differ much from the SBM-20 on spec sheets. In terms of real world performance, however, the difference is dramatic. At a couple inches from a 56g polycrase sample I was seeing easily 5x+ the counts on the Soeks-01M as the Gamma-Scout. Passing radiation detectors over the sample in a search pattern, it was not possible to discern the sample was present unless you held it above it briefly. That was < 1 cm from a 10 uSv/h source in a slow sweep pattern. The Soeks was a bit laggy unless you turned on audio counts or looked at the CPS graph, and the Polimaster PM1703 was more or less instant -- but both the Soeks and Polimaster could locate the sample. Or, trying to find the element in an intact smoke detector -- the Gamma-Scout utterly failed to do this, regardless of positioning or the mica shield being fully open. Again, both the Soeks and Polimaster could. (if you are interested, there are numerous comparison videos on YouTube)
And that is sort of the major fault of the unit, the tube. On one hand, it's a versatile tube, and has a mica window for alphas, soft betas, and lower energy x-rays. But this comes with a price, and that price is not being particularly good at 'scouting' for gamma radiation. Of course, that's pretty much what every review of the Gamma-Scout has ever said, so no surprises there.
The largest preventable and correctable fault I find with it is the integration count time on the display of the dose equivalent rate. I confirmed that the integration count (moving average measurement time) was indeed 20 seconds. That's just too short for low levels imo, and limits the minimum radiation above background you can detect. And this is why I wrote Geiger Bot in the first place, basically. A longer duration integration count. And it can be used with Geiger Bot, but this can be limited (see below).
It features a timed countdown 'pulse count' mode which is awkward to use and requires calculations on your part to convert it to the dose equivalent rate. (if only there were giant machines that could divide numbers quickly) Actually, most of all of the device's functions are a little obtuse to use and it's sort of like programming a VCR clock. This is probably a tradeoff in using low-power hardware that can run so long on a single battery.
So the Gamma-Scout has some interesting capabilities, but also limitations. If a power source is an issue, especially for an extended period of time, it's in a class of its own. It does not have the sensitivity of the Soeks, but then again, it never turns off whereas the Soeks does, and a Geiger counter that is turned off has no sensitivity at all.
I also had a hard time matching its DER to my PM1703's, which is also supposedly calibrated. The Gamma-Scout fluctuated 50%-100% above what the PM1703 reported, and the PM1703 was very close to the USGS data for the region. Perhaps it could be attributed to an over-response to lower-energy gamma radiation than the Cs-137 standard which is inherent in all Geiger counters.
At the end of the day, it comes down to this: a DRSB-01 I paid $50 for is much better at finding radioactive stuff than the Gamma-Scout at 10x the price. Had the Gamma-Scout used a pancake probe, I would be rabidly recommending it to everyone. As it is, I think it has a specific niche in long-term, always-on use more than anything. I also think the PM1703 is better still at that role, though to be fair the PM1703 is roughly 3x the cost of the Gamma-Scout and the PM1703's data logging is not very useful.
Also, it does work with Geiger Bot, with the audio 'ticker'. But beware-- using that frequently drops the 10-year battery life significantly, and the manual notes additional service fees if the ticker is used more than once per day.
Update: after doing more testing with the audio 'ticker' and Geiger Bot, some observations:
1. None of the published gamma sensitivities for the LND-712 will match the display. In fact, the Cs-137 one was about 50% lower DER than the Gamma-Scout even though it was picking up 100% of the counts. Tried multiple measurement times. LND's own published Co-60 spec was closer but still fell short. I'm not really sure, perhaps there's a calibration offset or something.
2.
(edit) In re-testing:
Am-241 Source (0 cm distance, directly on top of mica window)
DER mode: 1.9 mSv/h, OVERFLOW error
CPS mode: ~2500 CPS (150K CPM)
10 sec count: n/a
= derived conversion factor: ~13 CPS/mR/h
Am-241 Source (1 cm distance; Am-241 source was on surface, Gamma-Scout was placed top-down over it)
DER mode: 230 uSv/h
CPS mode: 496 CPS (29760 CPM)
10 sec count: 5923 (35538 CPM)
= derived conversion factor: ~22 CPS/mR/h
Background levels, gamma shield on
DER mode: ~0.130 uSv/h (fluctuating)
CPS mode: ~0.25 CPS (fluctuating) (15 CPM)
10 sec count: 2.0 (12 CPM)
= derived conversion factor: ~22 CPS/mR/h
Am-241 Source (1 cm distance)
with Geiger Bot on iPad 2 with mic adjacent to Gamma-Scout
Geiger Bot, Ultrafast Rates, Auto Adjust: 36K CPM
Geiger Bot, manual settings 1/2/10K (Ultrafast Rates disabled): 22K CPM
Comparison source online with LND-712 and Am-241 source: 108K CPM. I think the activity of the Am-241 source (smoke detector elements in either case) has to be +/- 30% by law. So I'm not really sure how to explain the lower number in this case, other than perhaps distance from the tube.
Another update: The manufacturer stated the conversion factor was non-linear but was ~23 CPS/mR/h at background levels, so it seems my above calculations were on target.
3. The alarm had to be turned off or it interfered further with counts
New!Soeks-01M ThoughtsUPDATE: My first two Soeks are gone; the first a gift, and the second was lost to an oddly very short drop in which the glass end of the tube impacted the speaker. As you can see in the picture below, they are extremely close together.
I have since purchased a 1.CL version Soeks-01M. It is very similar to the 1.BL firmware one. There are hardware differences; the contrast on the screen is different and it is oddly angled such that the unit's body is no longer a perfect fit. The contrast is overall lighter and makes the graph a little easier to see. The speaker was moved from the risky placement at the end of the GM tube to below the batteries.
The screen update is now 10s and it does 12x 10s second counts now. If there are other software differences I don't know what they are.
In the future I'd like to see a headphone or line output jack, and at least a 1 Hz screen update rate. Some logging capabilities and lower power consumption (perhaps by turning off the LCD entirely rather than just the backlight) would be nice. They're using a relatively beefier microcontroller than the Gamma-Scout, so there's not much of a reason that the Soeks couldn't have some additional functions such as logging, CPS display, history, etc.
--
I have just obtained 2x Soeks-01M Geiger counters direct from Federal Russia, to compliment my failing Kvarts DRSB-01 from Soviet Russia. They all use the same series of tubes (SBM-20). Series of tubes. Heh. The SBM-20 is one of the better cylindrical geometry GM tubes, and while not as sensitive as a scint counter or pancake GM probe, it's pretty good otherwise, mostly due to its unusually large size which catches more photons and electrons. Tube is big like Red Bear.
Readings on both counters were very similar. One was firmware 1.5L, the other 1.BL; 1.BL is the newer version and it has a secondary 2 minute integration count bar and radiation trend display. (so theoretically, the readings are more accurate than a mere 20s integration count)
I have a polycrase mineral sample (which is mostly sandstone) but the fractional amount of polycrase is 8% U and 8% Th, naturally occurring. On a calibrated gamma-only Polimaster PM1703M it measured 60K CPM, or about 10 uSv/h with the default conversion factors of that unit.
It also measured about 10 uSv/h on both Soeks units, once I either shielded the beta particles or used a ridiculously strong magnet to deflect them. With that sample putting out beta and gamma it measured about 30 uSv/h. With both of my smoke detector elements as well, I obtained a reading of about 38 uSv/h. This seems correct.
There is no way to see the count rate directly, or adjust the conversion factor. I believe it is set to 22, as Geiger Bot correctly displayed the same reading at lower count rates with the default factor of 22. (update: I calculated this manually with a stopwatch after reading where at least two people thought it was the Cs-137 conversion factor. I don't know what to say-- it came out as 22 every time for me.) Max count rate was about 1200 CPM or so -- every ~20s when a measurement interval finishes, the screen update halts the thread and the audio count rate freezes. (the Soeks-01M uses a STM8S10 5K6T6C 16MHz 8-bit industrial microcontroller with 2KB RAM**)
I've updated Geiger Bot to handle this much better. There will still be dropped counts at a high count rate, but in general and especially at levels < 5 uSv/h or so the displays should match up closely.
Note another impact of the modest microcontroller used here is the 2KB of RAM limits the duration of the integration count. I have read that only 127 data points are stored in RAM at any one time. While this is fine for surveying something fairly radioactive, it means obtaining that long duration integration count of static background levels isn't really going to happen too accurately. So although it is digital, and quite modern, I still use it with Geiger Bot.
The units have a USB port, but I'm not sure that's usable for anything but DC in power. It can also charge NiMH batteries, which are translated as 'accumulators'. (alkaline batteries are 'power elements') The battery life is not really impressive, probably because of the backlit color display and using 2x AAA batteries. I strongly recommend setting the backlight timeout on. The units run for quite some time in alarm mode with the screen off. And an AC power adapter with a mini-USB plug will run it continuously with Geiger Bot for Pachube uploading, if you're into that.
(** for comparison, the Gamma-Scout uses a TI MSP430; it consumes 3mA of power to the STM8S10's 8mA max. It's 16-bit, 3.3MHz, and has 512 bytes of RAM.)Auto-Adjust ModeTo update this section tremendously:
The 'auto adjust' mode is based upon an enhanced adaptive moving average filter for amplitude and frequency of a sound impulse. In other words, it uses the data it senses to determine what the settings should be, and continuously adjusts them based off a variety of parameters. It is pretty robust and accurate.
Of course, there is always room for improvement, so I do not think this will ever be 'done'. However, for the vast majority of users, I'm very satisfied by the performance of Auto Adjust mode. There is simply nothing else like it. (not because it's rocket science, just because it takes a lot of time to do well and it makes little commercial sense.)
A setting it does not do automatically is the RMS window. Without rather computationally intensive pattern matching (and the subsequent training / modeling of so many different types of count sounds), effectively decreasing the resolution of the input is necessary. The level at which it does this is less than a millisecond, so it's not exactly blurring everything together. Still, I chose to make it extra robust and precise for typical usage cases, and those needing higher detection resolution can still set the RMS window to 1 sample manually.
The advanced parameter for delay windows is also used, in determining the minimum 'dead time' for a count event. The majority of the versions with the auto-adjust feature didn't even set a minimum, and it was still quite accurate. But that isn't good enough, really. It also has to be robust and not just work under ideal conditions.
Some other things it does only in auto-adjust mode include extra adaptation to amplitude variance, and some minor filtering of outlier data in determining the settings.
Fast Standard DeviationTo save you a lot of TL;DR here's what you should be using. I didn't create this algorithm, merely the implementation. This is extremely efficient -- especially with the iOS's devices FPU -- and a cornerstone of all statistical analysis.
( n - 2 2 (mean - x) )
( n - 1 n )
Recursively calculates the standard deviation of a series of values, but must be executed for every new sample, where:
x .. the newest sample to be included in the standard deviation calculation
n .. the number of samples, _including_ the newest sample for which the standard deviation is being recalculated for
sd .. the old, previously calculated standard deviation, for the set of samples previous to this one (n-1)
mean .. the old, previously calculated mean (average), for the set of samples previous to this one (n-1)
revised code: (for readability)
static floatSDfromPrevious(float n, float x, float sd, float mean)
{
newSD = sqrtf( (n-2.0f)/(n-1.0f) * powf(sd,2.0f) + powf((mean-x),2.0f) /n );
return newSD;
}//SDfromPrevious
old code:
static inline floatq_SDfromPrevious(float f_index, float f_value, float f_oldSD, float f_oldMean) {
if (f_index <= 1)
return 0;
float f_stdDev = sqrtf((((f_index-2)/(f_index-1)*powf(f_oldSD,2)) + powf((f_oldMean - f_value),2)/f_index));
return f_stdDev;
}//q_SDfromPrevious