The GM-45 is a good, bare-bones radiation detector from Black Cat Systems. It is a detector only and needs to be attached to a computer or counter. The communication interface is RS-232 and reading data from it is super easy -- I've written a Geiger counter app in one line of Bash script.
Size: 5.3 by 3.4 by 1.5 inches (135 by 86 by 38 mm)
Weight: 9.3 ounces (264 grams)
Window: Mica, 1.75 mg/cm2 1.75 inch / 44.5 mm diameter Minimum allowed atmospheric pressure: 540 torr (8,000 ft altitude)
Radiation detected: Alpha: above 3 MeV, Beta: above 50 keV, Gamma/X-Ray: above 7 keV
Power requirements: Self powered from computer
Computer Hardware Requirements: USB version: USB port, Serial versions: serial port
Computer Software Requirements: Windows 98/2000/NT/XP/Vista/Windows 7, Macintosh MacOS 7.6 to 9.2, OSX 10.1.2 or later
Software Features: Built in graphing; Ability to store data to disk for further analysis; User selectable integration times; Built in statistics package; Trend line may be superimposed over graphed data; "Geiger Counter" clicking may be enabled
Package includes: GM-45 Unit; CD-ROM with software for both Windows and Macintosh; Appropriate serial cable - please order the correct version for your system, three are available: 1. Windows with 9 pin serial port, 2. Windows with 25 pin serial port, 3. Macintosh with 8 pin serial port
Reading data from a GM-10 or GM-45 radiation detector
The GM-10 and GM-45 are radiation detectors made by Black Cat Systems. These devices are Geiger-Müller counters. They count ionization events. Every time an alpha or beta particle or a gamma photo zips through the chamber the device will transmit a byte over its RS-232 output port. You just need to read the output and count the bytes. Note that the value of the byte is meaningless. You just need to count the fact that a byte of any value has been transmitted.
- Serial port settings: 57600 8N1 (57600 baud, 8 data bits, no parity, 1 stop bit).
- Set the DTR line high (DTR = 1). This is usually automatic, but if this is not done for some reason then the device will not receive power. It taps power from the DTR line.
The GM10 and GM45 come in RS-232 and USB versions. I chose the RS-232 version because I use Linux exclusively, so it was important to me that these devices work with Linux. The USB version will work with Linux, but not as easily as the RS-232 version. I decided that the RS-232 version made more sense because:
- I already own several FTDI FT232 based USB-to-RS232 converters that work great every RS-232 device I have tested.
- the USB versions of the GM10 and GM45 cost $50 more.
- the USB versions of the GM10 and GM45 are basically the RS-232 versions with a built-in FT232 converter.
- the FT232 converters in the USB GM10 and GM45 have custom USB VID number and PID number, so the Linux ftdi-usb-sio device driver does not recognize the serial device by default! Argh! This means you have to patch and recompile your device driver.
- the RS-232 version seemed more hackable because Black Cat systems provides details on how to interface directly to the GM-10 and GM-45 signal lines available right through the RS-232 port. Basically, the RS-232 version just conditions the internal amplifier signals to be compatible with RS-232. There is no hand-shaking or wire protocols to deal with. You could basically hook up a battery and an LED to the GM-45 to blink for each ionization event. You can't do that with the USB version.
The weird thing about my GM-45 is that I received it in the mail on Friday March 11th, 2011. That was the day the Japanese Fukushima Nuclear Reactors were damaged by a tsunami and suffered a core meltdown. After that the Black Cat Systems had a rush on all their radiation detectors... For the record, I've detected no significant increase in background radiation in San Francisco, California. (And yes, I know that's not how one would detect fallout from Fukushima anyway, but people keep asking me.)
The Black Cat Systems GM-45 is probably the most sensitive and most cost effective radiation detector you can find for under $400. I strongly recommend it. The quality of the device is good and the sensitivity is amazing. If you tried to buy research laboratory grade equipment with detectors this good then you would be spending much more. The Black Cat Systems devices also have decent documentation and support. The only device that I've found that comes close is the International Medcom Inspector Alert. This device costs almost twice as much as the GM-45; it doesn't include software; it has little technical documentation; and it has zero Linux or Mac support. I have no firsthand experience with their products.
See also the gm4lin-ng project. I didn't use this because it seemed like it didn't give me much that I couldn't do myself just by opening the serial port and counting bytes.
A Geiger Counter in two lines of Bash shell command
This may be the World's simplest Geiger Counter program. You can use this to get your GM-45 Radiation Detector up and running instantly under Linux. The `stty` command is first used to configure the serial port. Then a shell loop is used to log a date-time stamp when a byte is read on the serial port. Each date-time stamp indicates a single ionization event. Note that the date and time is output in the UTC timezone (Greenwich Mean Time). Three different example versions are given.
The following shows a simple Geiger counter using the Bash read builtin command. If you are using a different shell that does not have the read builtin then see the dd example.
stty -F /dev/ttyUSB0 raw ispeed 57600 ospeed 57600 cs8 -ignpar -cstopb -echo while true; do read -n 1 serial_byte < /dev/ttyUSB0; date --utc "+%C%y-%m-%d %H:%M:%S UTC"; done
The dd command can do anything. This shows an alternate way to read from the serial port.
stty -F /dev/ttyUSB0 raw ispeed 57600 ospeed 57600 cs8 -ignpar -cstopb -echo while true; do dd if=/dev/ttyUSB0 count=1 bs=1 >/dev/null 2>/dev/null; date --utc "+%C%y-%m-%d %H:%M:%S UTC"; done
click click... click... This example adds a click sound. Now your Geiger counter will sound like a Geiger counter is supposed to sound like. You need the `beep` and `amixer` commands installed. There are some other options besides `beep`. You can try `play -n synth 0.01 sine 2000 vol 0.9`.
# The '''amixer''' command make sure the "beep" device is not muted. # ALSA does not always have 'beep' device and it is not always called the same name. amixer -q set "Beep" 50% unmute amixer -q set "PC Beep" 50% unmute stty -F /dev/ttyUSB0 raw ispeed 57600 ospeed 57600 cs8 -ignpar -cstopb -echo while true; do read -n 1 serial_byte < /dev/ttyUSB0; date --utc "+%C%y-%m-%d %H:%M:%S UTC"; beep -f 4000 -l 1; done
# Print the speed: stty -F /dev/ttyUSB0 speed (log as irregular time series events):
MacOS Geiger Counter
The /dev device inode from a USB serial dongle shows up differently under MacOS. You will get two devices named something like /dev/tty.usbserial-ftB3Y8I6 and /dev/cu.usbserial-ftB3Y8I6. For our purpose we only care about the cu. device.
The stty command under MacOS behaves a little counterintuitively. When stty finishes it resets the device settings back to their defaults. But coming from Linux we might be accustomed to using stty to set the settings the way we want and have them remain that way while we subsequently use the device. In fact, this still makes more sense to me. I'm not sure what the BSD intent was for stty. The way around this quirk is to have a resource shared between the two processes remain holding a resource open. A simple file descriptor works as a shared resource. This explains the purpose behind the exec 3<>/dev/cu.usbserial-ftB3Y8I6 and exec 3<&- lines in the script. Without this then serial port would immediately be set back to 9600 after stty is finished instead of running at 57600 as intended and expected for the rest of the script.
#!/bin/bash > /tmp/tick.wav printf "\x52\x49\x46\x46\x64\x1F\x00\x00\x57\x41\x56\x45\x66\x6D\x74\x20\x10\x00\x00\x00\x01\x00\x01\x00\x40\x1F\x00\x00\x40\x1F\x00\x00\x01\x00\x08\x00\x64\x61\x74\x61\x40\x1F\x00\x00\x80\x26\x00\x26\x7F\xD9\xFF\xD9" >> /tmp/tick.wav exec 3<>/dev/cu.usbserial-ftB3Y8I6 stty -f /dev/cu.usbserial-ftB3Y8I6 raw ispeed 57600 ospeed 57600 cs8 -ignpar -cstopb -echo while true; do read -n 1 serial_byte < /dev/cu.usbserial-ftB3Y8I6 date -u "+%C%y-%m-%d %H:%M:%S UTC" # Linux would use `aplay /tmp/tick.wav &` afplay /tmp/tick.wav & done exec 3<&- rm -f /tmp/tick.wav