A technical update (facelift) is coming out from the Muon Hunter ST Nucleo K8 version at the end of January. 

​Happy new year!

Have rev1, but want to have some of the new features? Read on to find out how to modify your kit.

The new kit is up and running...

The detector took some selfies when capturing muons today.

The new firmware is out for the detector and so is the new python scripts for datalogging.

What's new? Quite a lot:

• I2C based datalogging for the GM signals, too
• SQL data storage (SQLite3) with CSV export
• Database structure changed
• AVR records coincidences
  
• UI program revised
• LOG.py main datalogging script added
• export.py database to csv export script added

Check out the details here: https://github.com/mvadai/muonhunter

You'd expect more muons to come from the direction of the top of the atmosphere than from close to parallel to the surface of the Earth.

This initial data was taken with the highest aperture, so it merely shows the magnitude of the counts.

When the tubes were set parallel to the surface of the earth, I measured the following with one of the prototypes - look at the muons / hour data:

Nothing comes out of vacuum except for a few elusive particles, so this kit has its story, too.

Mine started when I was looking for a tool for demonstrations when teaching particle physics on a budget. Something that actually could do physics in this domain. The first thing I looked at was these cheap GM counters and started to think about turning them into a coincidence detector.

First I built a lead coincidence detector that detects electromagnetic cascades caused by muons at the end of 2014. You can check out this prototype here.

I was fortunate enough to have the chance to go on a 3 week course in CERN called HST 2015. I wanted to try out my detector with a cloud chamber so I thought I would bring it along if the programme allows to test it out. The organizers had been very helpful, so we were given the chance to set it up.

We had two opportunities to test the circuit - so the time was tight. However, we managed to capture a muon decay on camera, although we had trouble with the lighting in the cloud chamber. We fixed it somewhat, but still can be improved. Still, a faint, but clear trace of the decay can be seen on the picture below.

I originally wrote this program for my prototype lead array coincidence detector for cosmic rays. However, it can be used with virtually any GM counter which has a pulse output. Just make sure the pulse output is compatible or made compatible with the Raspberry Pi 3V GPIO inputs. This responds either to high or to low triggers. See settings.py . It's an ideal program to harness the powers of the Raspberry Pi 2. It's written for multi core architectures, but it will work on single core, too.

• supports up to 3 GM signal sources eg. GM tubes / counters and an additional coincidence signal connected at the same time
• GM / cosmic ray count logging (accurate in the normal GM tube response times)
• time logging for each hit on each source for lower count rates (<100 cps only)
• CSV exponential distribution statistics for the GM / cosmic ray pulses (<100 cps only)
• average CPM and dose logging
• real time demonstration output to console
• SSH real time console output - supports laptops, phones and tablets
• CSV raw data output - compatible with MS Excel, Google Spreadsheet, OpenOffice, LibreOffice, Quickoffice, iWork, Matlab, Mathematica and Maple. 
• written in object oriented python - no messing about with C or Arduino
• open source and documented
• runs in background as separate process threads for each equipment
• supports RPi A/A+, B/B+ and RPi 2
• dose calibration even for different tubes at the same time
• supports both trigger types for each equipment to connect various equipment at the same time
• supports any commercial Geiger Müller counter with low OR high pulse output (old ones, too) (just make sure it's 3V compatible so you don't damage your Pi - make sure it's "level shifted")
• supports DIYGeigerCounters
• supports the Mightyohm Geiger Counter
• supports coincidence / cosmic ray detectors,  such as my prototype CR-2
• supports long datalogging

1. sudo rpi-update
2. Setup git, if you haven't done it before: sudo apt-get install git  
3. git clone https://github.com/mvadai/rpi-geiger-logger.git

I. Make sure you change the GPIO, trigger, dose conversion settings in the settings.py where appropriate.

1. cd rpi-geiger-logger
2. open settings.py in any plain text editor eg. nano settings.py
3. read the instructions in the file and make changes
4.  save your changes
   

II. Connect your geiger loggers / counters / signal to the RPi GPIO. Warning: make sure the signal is 3V otherwise you risk damaging your Pi.

Datalogging on console or over SSH:
0. cd rpi-geiger-logger
1. sudo python main.py <number of seconds>

Replace the number of seconds with the desired whole number.

Running the datalogging in the background:
1. Issue the command above with 10 seconds, or make sure the RPi doesn't ask for the root password.
2. Issue the following command
Over SSH: nohup sudo python main.py <number of seconds> >/dev/null 2>&1 &
For console: sudo python main.py <number of seconds> >/dev/null 2>&1 &

That's it. Wait for the program to finish and you'll find your data in the CSV files in the same folder.

main.py

This is the main part of the program deals with input and output and the event handling on the different Geiger-Müller counters / signal sources. It takes one argument, the logging time needed expressed in seconds. Runs 1-4 threads depending on the configuration in settings.py. It's an ideal app to harness the powers of the Raspberry Pi 2. You can have a processor for each GM signal.

settings.py

The settings can be changed here. See the file itself for detailed instructions.

COUNTER.py

class COUNTER:
This is the main class for each signal source all the calculation and datalogging is done here.

Variables:
int PIN
GPIO pin number - BCM numbering convention.

int CPStomR
Determines the ionosation rate for a certain CPM for a certain GM tube. This should be in the GM tube's datasheet. For the SBM20 this is 22 CPS/mR/h for Co-60 gamma and 29 CPS/mR/h for Ra-226 gamma. Read the calculating the dose section here for more information.

float mRtouGy
Determines the mR to uGy conversion given by the datasheet if applicable. For tubes using CPS to uGy, this should be 1.

float START_TIME
Stores the time the counter was started.

int CNT
Stores the total number of GM hits. Default is 0.

float[] TIMES
This list stores the times for the GM hits.

__init__(pin, CPStomR, mRtouGy):
Constructor takes the GPIO pin number, the CPStomR (CPS/mR/h) and the mR to uGy conversion rate (eg. 8.77)

COUNTER.update()
Increments the counter by one and appends the current time to the TIMES the current dose to DOSES and the current CPM to CPMS.

COUNTER.av_cpm()
Returns the average  counts per minute as int, CPM for the whole logging period.

COUNTER.av_cph()
Returns the average counts per hour as int, CPH for the whole logging period.

COUNTER.av_dose()
Returns the average as float dose in uGy/h calculated from CPM.

COUNTER.av_doseh()
Returns the average dose calculated from the CPH in uGy/h as float.

COUNTER.cpm()
Returns the estimated CPM as int for times less than a minute and the CPM above one minute.

COUNTER.cph()
Returns the estimated CPH as int for times less than an hour and the CPH above one hour.

COUNTER.dose()
Returns the actual dose in uGy/h based on the dose conversion factor given in settings.py.  The calculation done is the following. Absorbed dose in uGy/h =  (mR to uGy factor) * CPS / (sensitivity (CPS/mR/h)).

COUNTER.doseh()
Returns the actual dose in uGy based on the dose conversion factor given in settings.py converted back from CPH.

COUNTER.exponential()
Calculates the timely distribution of GM hits. Determines the appropriate time intervals and counts the hits falling into those intervals. Writes the distribution in a CSV file.

COUNTER.csv_write()
Writes the total number of hits, the times for each hit, the average CPM and average dose for a counter into a CSV file.

Maximum theoretical count rate with SBM 20 is 5263 CPS, but it depends on the state of the tube you have.

Single core performance

The operating system is much slower than this. The 3 simultaneous signals appear in the logs usually within 0.01s only. This is only because of the response time of the operating system, not the actual signal detection on the detector itself or on the BCM chip. Therefore you can't assume that the 3 simultaneous signals which do appear on the hardware at the same time on the us timescale, will appear at the same time in the logs, too, only within 0.01s. The time difference between the signals in the logs is usually around 0.002 s.

However, this does not mean that the detector itself is that slow or you're witnessing a false positive detection or we're missing out on some signals. The time logging has a constraint of above, therefore it works until roughly 100 CPS. The event detection has been tested in the normal GM tube ranges (up to 10 kHz) the count rate. See this link for a nice comparison of the GM tubes. 

The 0.01s variation between the log times for 3 simultaneous hits is the price we pay for not busy waiting on the processor and for the low power consumption. When the hits are more frequent, the processor scales up.

Stay tuned for data for the Raspberry Pi 2.

To avoid false detections to calibrate the prototype detector, please check the troubleshooting section here.

I wrote a cosmic ray / Geiger Müller datalogger program for the Raspberry Pi in Python. It logs the number of hits and the times for each hit, the actual / average dose, the actual CPM / average CPM and the same for CPH, too. When it's below an hour for CPH or minute for CPM then it estimates a value for CPM and CPH based on the hits so far.

It can be used with 1-3 GM signals and a coincidence signal simultaneously. It's written in python (object oriented, so easily reusable) and produces a csv file for each GM tube and one for the cosmic rays. It also performs statistical calculations of the timely distributions of GM hits and produces a separate file output with that.

Then you can manipulate your data the way you want in your favourite spreadsheet application. CSV is compatible with most major softwares on the market MS Excel, OpenOffice, Google Spreadsheet, LibreOffice, iWork, Matlab, Mathematica and Maple. The datalogging can be viewed "real time", too. It runs three threads and has event handling. This means you can run it in the background, too, while your Pi is busy doing other tasks. It will easily run on an Raspberry A/A+, too.

For more information, screenshots and download, visit this link.

Since it's console you can easily run it over SSH from your phone/tablet/laptop. Even if you're logging radiation in Eritrea after Bruno Rossi, of course, over the local mobile internet when sitting somewhere else in the world. 

I wanted to make a coincidence detector for two Geiger tubes following the footsteps of Bruno Rossi. I had the 2 tubes, but wanted a simple power supply. 

The manual for the first prototype can be downloaded here.

The history of the HV supply circuit and detailed information about the GM tubes can be found here on the DIYGeigerCouter web site.  I wanted to do anode pulse detection opposed to the cathode method in the GM counter, since the later is not possible in a lead array configuration with the SBM20 tubes. I added coincidence detection, too. I omitted the microcontroller since I'm using a Raspberry Pi for more advanced datalogging.

I found a lead array design of the tubes on the CERN web site.  You can read about the theory of coincidence detection there, too.  Mine is a lead array 2 tube design.  I have a block of lead from car battery recyclers, given the dimensions of it, I opted for a 2 tube design.  

There's an impressive lead array design I found on the internet, that uses a different HV power supply and it has a 5V logic output. You might want to check out that too, that has an USB output to a laptop and a separate mains 9-14V power supply. That is a more concealed design, but I needed more flexibility.

I wanted mobility (as much as this is possible with lead), a demonstration tool and a 3V logic circuit and battery operation, therefore I made a different design. I had 74125 line drivers, those can be used, too, to make the coincidence circuit, not only the ICs mentioned in the CERN article. I prefer the Raspberry Pi for datalogging, mainly because of the affordability, the continuous, low power operation and because it runs Linux, but of course, you can connect your Arduino or laptop, too. This 3V logic will work in all cases.

Oh, just in case you wonder, our drill gave up at that depth in the lead block, so that's why I have the GM tubes sticking out. However, it really is a feature for demonstration. It just lowers our count rate, unfortunately.

Here is a photo of our beauty.

Do you want to see it in action? There's a video below of one detection. It happens at about 1.12. I made the blink longer for the green LED, so it's more noticeable.

Because the GM tubes are sitting in the lead with their cathode connected to the lead block the signal has to be taken from the anode.

The GM pulse is shortened to reduce the number of false positives. I included the resistors and the 220 pF high voltage capacitor connected to the anode of the SBM20 to achieve this. 

I had the SN74LVC125AC line driver in stock. That's suitable to make the coincidence detector from. It can act as a logic gate for the pulse shortening and the nor gate can be constructed from it, too. I wanted separate outputs from the GM tubes as well as the cosmic ray detection, since there is interesting statistics in those pulses.

The RPi GPIO in input mode is fast enough to catch the shortened pulses, so it makes sense to connect 1 - 3 free GPIOs. If for any reason you have problems with the inputs, you can always connect the long pulses from the test points, however those pulses will miss a lot of the action. See graphs below.

You can download and install the program from here.

While it's not possible to answer this question for a single discharge, there is a clear pattern in the time you have to wait for the next GM discharge. I logged data for 48 hours on both tubes. The graph shows the number of GM hits in each time interval one after the other in a sample of 134 856 GM hits. I wanted to know on average for how long do you have to wait for a GM hit to happen from normal background radiation. Ie. the first column shows the number of hits happened between 0s-1.865s one after the other. The second is the number of hits where you had to wait from 1.865s-3.729s for the next hit to happen, etc. These times show an exponential distribution.

The time interval between cosmic rays to see whether it's the same. I logged the rays for 48 hours, and I received a sample of 1763 rays, that is roughly 37 hits per hour.  Here's the graph:

I have received an interesting shower of particles on one night. There was a shower of 94 then 221 then 54 particles within a second. There were a couple of seconds between these air showers. 

The Rossi experiment could be done with this device, but I haven't done it yet, that's the next one.

There is a simple user interface for demonstrations. I included one LED for each GM tube so the individual hits can be seen and also one LED and a buzzer for when a cosmic ray is detected. Since this circuit uses a 555 already, I used some more in monostable connection to lengthen the pulses from the GM tubes to drive the LEDs. When you buy some of these for the HV supply (in case you're making more than one GM circuit), it makes sense to buy some more, since there's usually a discount. As an alternative, you might want to chose a microcontroller or some basic pulse lengthening techniques to drive the LEDs.

You will find the schematic below for the main board which has the datalogging output. The board which has the LEDs and the buzzer only has 3 555 monostables, to lengthen the impulses so it's viewable by the human eye.

The Roengten to Gray (or Sievert) "conversion"

The problem initially is that the datasheet of the SBM20 gives the number which can be used for dose calculations in a legacy unit mR. 

Roengten is the measure of ionization in AIR and not in tissue or other material for x rays and gamma rays in the few MeV range. It is the charge produced by ionization divided by the mass of air. In SI units this would be expressed as Coulombs/kg. According to the international conventions 1 Roengten = 2.58 x 10^-4 C/kg (this is the calculation used by the NIST and the EU). 

This is an entirely different unit to the dose units (joules/kg) of today. Which are absorbed energy/mass in the first order of approximation so to speak.

So how do you convert? Well, you can not convert in the mathematical sense, contrary to the popular belief.

What can you do? 

Now this is the sort of thing people do, but usually without realizing the limitations of this.

Since the Roengten is defined as the ionization produced in air by x rays and gamma rays in the few MeV range (that is luckily our range)international organisations have said that this is equal to 8.77 mGy (1Gy = 1 J/kg) absorbed dose in AIR (1 Sv = 1 J/kg, too, but it's different see below). Now we have a sort of "conversion" from Roengten to Gy for a certain material for a certain type of radiation. This number is 9.6 for human tissue for X-Rays and gamma rays in the few MeV range, but this is in Gy not in Sv!!!

This is the number you can change in the settings.py.

Do you wonder why my display does not say Sievert? Although 1 Sv = 1 J/kg = 1Gy, but Gy does not take into account the biological effect, whereas Sv does. We simply usually don't know what sort of radiation we measure with the GM tube and what the radiation weighing factor of that is. You'll have to know this if you wanted to convert to Sieverts.

However there's another complication if you wanted ANY dose measurements with a Geiger Müller tube. Here it comes.

Sensitivity of the GM tube or THE FLUX TO DOSE "CONVERSION"

This is the feature of the GM tube, this is found in the datasheet and it is not to be confused with the Roengten - Gray conversion. This tells you what the ionizing effect of a certain count rate measured by the GM tube is for a certain type of radiation. This has nothing to do with the R - Gy or Sv business. 

The estimation for my detector. The datasheet says that for Ra-226 the ionization measured by the SBM20 is 1 mR/h for 29 counts per second for gamma. For Co-60 the same number is 22 CPS. I used 24 cps/mR/h as an overall estimate based on the fact that only higher energy particles will enter the lead block, and the Co-60 gammas (1.17 MeV and 1.33 MeV) are typically the double of the energy of the Ra-226 gammas (typically 609 keV, but there's a large range of them). However, some lower energies will hit the tubes on the top, too. This is strictly an estimate at this point, it would require further research to estimate this more accurately. To get the full picture of Ra-226 gammas look at the table on p78 in this article. That is 1440 cpm/mR/h.

Anyway, knowing your source and equipment you can change this in settings.py for each tube / signal source therefore achieving a much more accurate dose measurement using this program on the Raspberry Pi.

What are the limitations here? Why does this program display uGy and not uSv?

The limitations are quite substantial, actually. There are two non mathematical conversions involved in here. The one is the R to Gy and the other one is from CPM to R.

The conversion factor you used to convert from Roengten to Gray (or even worse Sievert), ideally has to be for the same type of radiation and the same material as the conversion rate you used for CPM to R. This R to Gy is an experimental conversion for certain radiations and materials, not a conversion similar to from m to mm for instance. So in other words it's not a mathematical conversion. 

Formulae

To sum it up, here are calculations to enlighten the difference between mR/h, uGy/h and uSv/h.

sensitivity is expressed in CPS/mR/h - this is what you get from the GM datasheet
for 30 CPM and for SBM20 with Co-60 gamma = 22 CPS/mR/h (you can't just use this you'll have think what factor you use, you can't just take the average of the sensitivites if more given, either)

Ionization effect only in air (mR/h) = ( CPM/60 ) / sensitivity
Ionization effect = ( 30 / 60 ) / 22 = 0.0227 mR/h
 
Dose (uGy/h) = ("conversion" factor from mR to uGy) * ionization effect in air
This dose is called the absorbed dose and this does not take any biological effects into account.

for air it would be using the example above
Dose (uGy / h) = 8.77 * 0.0227 = 0.199 uGy/h
for tissue
Dose (uGy / h) = 9.6 * 0.0227 = 0.218 uGy/h

in Sieverts for gamma for human tissue
Dose (uSv/h) = (radiation weighing factor) * ("conversion" factor from mR to uGy) * ionization effect in air
This is called the equivalent dose and it does take the biological effect of different types of radiation into account.

This is derived from the ionization effect in air not in human tissue... That's why people don't like these conversions from Roengten to Sv, and this is why it was changed on an international level.

Anyway, if you really want to proceed... The radiation weighing factor for gamma is 1.
Dose (uSv / h) = 1 * 9.6 * 0.0227 = 0.218 uSv/h
You got lucky, huh? The uSv/h is the same as the uGy/h for gamma. So what's the fuss about. Part of it is that Roengten is only in air, this is an inherent weakness, but here comes the big bang.

Let's assume we have alpha (of course the GM tube's sensitivity is given in Co-60 gamma equivalent, so using this for alpha is not a wise thing to do, however just for the sake of the example, I carry on.) The radiation weighing factor is 20 not 1, whoooops.

Dose (uSv/h) = 20 * 9.6 * 0.0227 = 4.358 uSv/h and your counter which doesn't know this happily displays 0.218 uSv/h.

Another example with LND 712

Dose (uSv/h) = (radiation weighing factor) * (conversion factor from mR to uGy) * ( (CPM/60) / sensitivity )
Eg. Dose for an alpha source for LND 712 for 30 CPM using Co-60 gamma = 18 CPS/mR/h : 
Dose (uSv / h) = 20 * 8.77 * ( ( 30 / 60 ) / 18 ) 
Whereas dose in uGy / h is only 8.77 * ( ( 30 / 60 ) / 18 ) note there's a 20 TIMES DIFFERENCE!!!!

To calculate the effective dose, or committed dose you'd have to take the tissue weighing factor, the absorption factor of the certain tissue or location into account. See here.

To measure the dose properly you'd have to use a calorimeter which measures the energy of radiation. In contrast to the flux of the particles what the GM tube measures. The capability of GM tubes in measuring dose are very limited.

I wanted a device which can run on batteries and alternatively on a 3V power supply when we do long runs of measurements. This can be 3.3V from a Rasbperry Pi, too. It consumes about 10 mA for normal background, quite stable with no surges, so you don't have to buy any extra power accessories, it will work straight away. This means an alkaline battery will last about 80-120 hours in this device, a zinc carbon about the half. For more active sources it will use more energy.

The coincidence detector gives a positive signal for a cosmic ray when the two Geiger Müller tubes discharge one after the other within 2 us, because the GM pulse is shortened to reduce the number of false positives - see below. The GM tube's recovery time is 190 us. Therefore the typical trigger on the output will appear within 2 us at the same time on the us timescale. This has been tested on the hardware. 

Theoretically the delay time in the EM cascade in the lead block is around 100 ps (10^-10 s), although it can vary based on the locations and the extent of the cascade. This is the time frame in which the GM tubes are triggered one after the other according to my calculations based on the signal propagating times in the lead block. However, this sort of time is well beyond our signal detection electronics response time (10^-6 s), so we can assume that the signals appear at the same time on the us timescale.

The number of coincidences = false detections (assuming a 30 CPM background for both tubes) is:

 That is 1 false detection over a 278 hour logging period (11.6 days). For the theory of this calculation see this link.

For all problems, check all the connections first. That solves the problem in about 95% of the cases.

Symptom: there's no or very little GM signal.
Solution: The usual problem is that the voltage is too low on the GM tubes. Increase the voltage by turning the white screw in the potentiometer anti-clockwise towards the 1 mark. If this doesn't help, change the batteries.

Symptom: there is too many cosmic ray detections and the detection happens simultaneously with the detection on one of the GM tubes. This phenomena has been extensively tested, under normal operation this should not happen at all.
However, if it still happens with this current design, the cause is usually too high voltage on the GM tubes. Decrease the voltage by turning the white screw in the potentiometer clockwise towards the 3 mark.

Symptom: One of the GM tubes is firing constantly or in close succession without any source present.
Usually this is a connection problem on the HV terminal or on the GND terminal, so check the connections.
If not then the cause is usually too high voltage on the GM tube. Decrease the voltage by turning the white screw in the potentiometer clockwise towards the 3 mark.