Cosmic Array

An array of individual cosmic ray detectors distributed across a landscape to display how cosmic rays arrive as showers of muons.

Similar projects worth following
The aim of this detector project is to deploy many detectors across a park or landscape. So that an observer from a distance or walking amongst them will experience how cosmic rays are all around us and arrive in showers of particles. Each detector will seem to randomly twinkle with colours and sounds that are triggered by cosmic rays.

However, as cosmic rays arrive in showers of particles, some of these detectors will trigger in unison and others independently. The experience being similar to what can be witnessed in nature like the sounds of Cicadas or the flashing light of Fireflies, where both sound or light fade in and out from randomness to unison.

Cosmic Rays have been present throughout the entire evolutionary history of life on our planet and so this display reinforces our connection with the universe and the importance of science and understanding of the natural world.

More information about what cosmic rays really are, is available here.

I now receive seed funding from Hackaday for every like, if you want to help fund this project, click the like link above.

I'm working on a number of different design approaches for this project as it will need to be more cost effective if I was to build a larger installation of 100 or more detectors. The detectors in the array may be enclosed in a type of bollard lamp post, sphere, something that hangs on a tree or tripod or is put in the ground like a paving block.

Future prototypes and installations may include a software, pulse summing and solid-state detectors. More details about this project will be added in the project logs below.

Another aim is also to setup a IoT wireless network linking each detector, so for example 100 detectors spread across a hectare might be monitored live to produce a histogram of activity. Further each element of the Cosmic Array is essentially a complete cosmic ray (muon) detector and radiation (gamma) monitor. So it can not only be used in a light and sound display but also be used to measure both cosmic ray flux and local background radiation. So the design will also include a suitable IoT device so information can be accessed or transferred over a network or the internet.

The project has no agenda other than the first of what I hope are thought-provoking art/science installations. Which will provide an interesting window into the universe and the natural world around us, leaving the observer to form their own connections and conclusions.

I have a live installation of 16 Detectors will be on display in Adelaide for the Splash Adelaide winter festival in September 2017.

I will also have a live display along with other detectors I have made at this Maker Faire Adelaide 2017 in November 2017. - Maker Faire Adelaide is the largest Maker Faire in Australia and in the Southern hemisphere.

Note about: Geiger–Müller Tubes
I've had comments regarding the validity of using Geiger–Müller Tubes for a cosmic ray (muon) detector. Pointing out that Photomultipliers and scintillation panels are best, and yes the are far more effective. However, they are also expensive, whereas Geiger–Müller tubes are relatively cheap and easily available to purchase.

Although I'm currently working on a solid-state detector there are a few issues yet to overcome, so this is still a few months away.

History is full of examples of physicists using Geiger–Müller tubes for cosmic ray observations up to the 80s. Geiger Tube Telescopes (GTT) were used by NASA including many Pioneer spacecraft missions and others. One most notable user was Bruno Benedetto Rossi a famous Italian experimental physicist who made major contributions to particle physics and the study of cosmic rays. At the age of 24, he fabricated his own Cosmic Ray detector using Geiger–Müller tubes and then went on to invent the first practical electronic coincident circuit.

Cosmic Array V8.pcb

PCB Design using ExspressPCB V8

pcb - 28.10 kB - 07/11/2017 at 12:02


Cosmic Array.pcb

PCB Design using ExspressPCB V7

pcb - 29.77 kB - 06/10/2017 at 23:05


  • 3 × Resistor 10M Ohm 0.25W, 1/4W SMD 1206 HV
  • 3 × Capacitor 10pF ±5% 1kV Ceramic NP0 SMD 1206
  • 3 × Capacitors 1µF 450V Aluminum 2.5mm Radia
  • 3 × Resistor 47.5k Ohm ±1% 0.25W SMD 0805
  • 3 × Resistor 560k Ohm ±1% 0.125W SMD 0805

View all 30 components

  • SD Cards configured

    Paul Schulz07/30/2017 at 05:41 0 comments

    The software for the detectors has been installed on the SD Cards, and prepared for posting to Robert for installation in the Raspberry Pi Zero's.

    This installation contains new audio files.

    Cosmic Array SD Cards

    Some details

    The OS Image being used is Raspbian Jessie (2017-07-05-raspbian-jessie-lite).

    A Raspberry Pi 3 is used as it provides a wired network interface, as well as a screen and keyboard.

    Once the OS Image has been written to the SD Card (16GB), it is booted with screen and keyboard attached and via the configuration tool (raspi-config), the hostname is set (cosmic-array-*-*), the SSH service is enabled and the Pi is rebooted.

    SSH keys are manually copied to the card using ssh-copy-id.

    An ansible playbook is used to connect to the system via SSH and setup the wireless, additional packages and to checkout the cosmic-array software from GitHub. While this might be slightly overkill for individual cards, these configuration tools will allow all 16 detectors to be modified and updated easily later on. 

    Finally, the 'config/' script is run from the cosmic-array software to setup boot parameters (audio system overlay), programs started on boot and  audio volume settings. This script will probably be included in the ansible setup process in the future.

  • Code now available on GitHub

    Paul Schulz07/28/2017 at 11:04 0 comments

    The code,  data and files required to drive the RaspberryPi Zero has now been made available via GitHub.


    This code is 'feature complete' for the standalone cosmic array sensor. 

    Suggestion, Comments, Branching and Patches welcome. Distributed under GPL v3.

  • Big problem solved with small fix

    Robert Hart07/23/2017 at 11:35 0 comments

    Recently we completed work on Cosmic Array sound and IoT using the new Raspberry Pi Zero W. But the addition of a Raspberry Pi and the audio amplifier caused the detector to trigger more often than it should.   At first, it didn't seem to be an extra load on the 5V regulator. Nor the Geiger-Muller tubes after a check with a radioactive check source and DSO.    

    Then I remembered! I cut back on components to simplified the circuit design and cut costs.  One of the components I removed was a 4V7 Zener diode on the output of the 10pf coupling capacitor connecting the Geiger-Muller tube to the 555 monostable oscillator trigger pin 2.   At the time of the redesign, I forgot the real reason for the Zener just assuming it was there for voltage protection between the high voltage and low voltage sections.   

    The 555 timer acts as both a Schmitt trigger to shape the negative pulse from Geiger-Muller tube to a +5VTTL and increases the pulse width.  Pin 2 of the 555 is the trigger for the monostable oscillator when it detects ground travelling pulse.  So Pin2 is held at the supply rail voltage by a 47k resistor so when the high impedance negative pulse from the Geiger-Muller tube it triggers.  

    The trouble came when both the Raspberry Pi and the audio amplifier where added to the 5V supply rail that supplies the 555 circuits. Although the quiescent state supply rail measured 5V after coincidence is detected, the Pi plays a wave file and then the Audio amplifier causes ripple currents the trigger the other 555 monostable oscillators causing them to trigger randomly resulting in more ripple currents.  

    The solution is to hold pin 2 at 4.7V with a Zener diode and the problem goes away.   The new boards are also designed with a higher current regulator further reducing this effect.

  • Cosmic Array and the Raspberry Pi Zero W

    Robert Hart07/21/2017 at 08:45 0 comments

    To give each element of the Cosmic Array sound and IoT we are using the new Raspberry Pi Zero W

    The Raspberry Pi Zero W doesn't have sound but with the addition of a low pass filter thanks to information on Adafruit Learn Blog this was quite straight forward.

    Amplified by a  5V 3W Class D amplifier based in the PAM8403 which is cheaper to source as a fully assembled PCB than a chip on its own.

    I needed 16  4 x 4 Raspberry Pi Zero W for an Art installation at Splash Adelaide and although there has been a one order per customer limit imposed by the Raspberry Pi Foundation on suppliers. 

    Thanks to wonderful local Hackerspace Adelaide community we have been able to source 16  x Raspberry Pi Zero W for the task. 

  • Final shape of the detectors coming togeter

    Robert Hart07/15/2017 at 00:05 0 comments

    The last few weeks while Paul has been developing the code for the Pi Zero W we'll be using in this build for IoT networking and sound effects. I've been working on the hardware and ordering parts for 16 detectors. As the detectors will be out in the weather they will need to be waterproof and have the ability add other features at a latter stage.

    The unit will be slightly different to this as I've found a supplier of Outdoor UV resistant Acrylic Spheres.

    The spheres I will be using are on order and should arrive in a few days along with the waterproof enclosures both I've been able to source at wholesale.

    Post Top Light Exterior Opal Acrylic Sphere E27 in 20cm Galactic Oriel Lighting. Exterior IP44 spherical opal acrylic post top. Complete with black polycarbonate base to suit 60mm outside diameter post.

    Gasket seals, stainless steel hardware and IP66 rated , Opaque cover: 200(L) x 200(W) x 130(D)mm, ncludes a 1.8mm galvanised chassis for mounting electronics.

  • Raspberry Pi Pinouts

    Paul Schulz07/13/2017 at 00:36 0 comments

    The following are the proposed pinout allocations for the Raspberry Pi (Pi 3 or Pi Zero W) in the project.

     | Description  |    Name |    Mode | Physical | Mode    | Name    | Description  |
     | (Connected)  |         |         |          |         |         | (Connected)  |            
     |              |    3.3v |    3.3v |  1 || 2  | 5v      | 5v      | +5v Supply   |
     |              |   SDA.1 |       - |  3 || 4  | 5v      | 5v      | +5v Supply   |
     |              |   SCL.1 |       - |  5 || 6  | GND     | 0v      | Gnd Supply   |
     |              | GPIO. 7 |       - |  7 || 8  | -       | TxD     |              |
     | Logic Gnd    |      0v |     GND |  9 || 10 | -       | RxD     |              |
     | Chan. Red    | GPIO. 0 |  IN/TRI | 11 || 12 | IN/TRI  | GPIO. 1 | Chan. Green  |
     | Chan. Blue   | GPIO. 2 |  IN/TRI | 13 || 14 | GND     | 0v      |              |
     |              | GPIO. 3 |       - | 15 || 16 | -       | GPIO. 4 |              |
     |              |    3.3v |    3.3v | 17 || 18 | -       | GPIO. 5 |              |
     |              |    MOSI |       - | 19 || 20 | GND     | 0v      |              |
     |              |    MISO |       - | 21 || 22 | -       | GPIO. 6 |              |
     |              |    SCLK |       - | 23 || 24 | -       | CE0     |              |
     |              |      0v |     GND | 25 || 26 | -       | CE1     |              |
     |              |   SDA.0 |       - | 27 || 28 | -       | SCL.0   |              |
     |              | GPIO.21 |       - | 29 || 30 | GND     | 0v      |              |
     |              | GPIO.22 |       - | 31 || 32 | OUT/PWM | GPIO.26 | Audio Out(L) |
     | Audio Out(R) | GPIO.23 | OUT/PWM | 33 || 34 | GND     | 0v      | Audio Gnd?   |
     |              | GPIO.24 |       - | 35 || 36 | -       | GPIO.27 |              |
     |              | GPIO.25 |       - | 37 || 38 | -       | GPIO.28 |              |
     |              |      0v |     GND | 39 || 40 | -       | GPIO.29 |              |
     | Description  |   Name  |    Mode | Physical | Mode    | Name    | Description  |

  • Event Capture and Recording with Raspberry Pi (Part 2b)

    Paul Schulz07/06/2017 at 08:48 0 comments

    This log entry follows on from Part 1, and Part 2a.

    Transmitting Cosmic Array Detection Events

    The RaspberryPi 3 (or RaspberryPi Zero W) receives events from the detector via the toggling of the General Purpose IO (GPIO) lines. These lines are monitored by software on the Pi, which registers interrupt functions for each line, which is called when an event is detected.

    This means that the processor doesn't need to continually poll the GPIO lines for their state, saving processing time, and can also react immediately (interrupting whatever it was doing), improving reaction time.

    The previous program written to send UDP event packets across the network (udpsend) has been changed to use interrupt functions. While doing this, it was discovered that the WiringPi library also allows multiple programs to be triggered by the same interrupts. This has proven useful for also getting the detector to produce sound effects (eg. play wav files) and the code for this is below:

     * cosmicray-play.c - Play an audio file on a cosmicray event.
     * usage: cosmicray-play
    #include <stdio.h>
    #include <stdlib.h>
    #include <wiringpi.h>
    /*  error - wrapper for perror */
    void error(char *msg) {
    /* interrupt functions */
    void my_interrupt(int i) {
      system("aplay audio/beep.wav > /dev/null 2>&1 &");
    void my_interrupt_0 (void) { my_interrupt(0); }
    void my_interrupt_1 (void) { my_interrupt(1); }
    void my_interrupt_2 (void) { my_interrupt(2); }
    void my_interrupt_3 (void) { my_interrupt(3); }
    void my_interrupt_4 (void) { my_interrupt(4); }
    void my_interrupt_5 (void) { my_interrupt(5); }
    void my_interrupt_6 (void) { my_interrupt(6); }
    void my_interrupt_7 (void) { my_interrupt(7); }
    int main(int argc, char **argv) {
      /* check command line arguments */
      if (argc != 1) {
        fprintf(stderr,"usage: %s\n", argv[0]);
      /* setup interrupt handlers */
      wiringPiISR (0, INT_EDGE_FALLING, &my_interrupt_0) ;
      wiringPiISR (1, INT_EDGE_FALLING, &my_interrupt_1) ;
      wiringPiISR (2, INT_EDGE_FALLING, &my_interrupt_2) ;
      wiringPiISR (3, INT_EDGE_FALLING, &my_interrupt_3) ;
      wiringPiISR (4, INT_EDGE_FALLING, &my_interrupt_4) ;
      wiringPiISR (5, INT_EDGE_FALLING, &my_interrupt_5) ;
      wiringPiISR (6, INT_EDGE_FALLING, &my_interrupt_6) ;
      wiringPiISR (7, INT_EDGE_FALLING, &my_interrupt_7) ;
      return 0;

    Can be compiled with:

    gcc -o cosmicray-play cosmicray-play.c -lwiringPi

    Then run it from a directory where a suitable 'wav' file is available.

    Next time: Collecting and storing event data in a database (Part 3).

  • Event Capture and Recording with Raspberry Pi (Part 2a)

    Paul Schulz07/02/2017 at 14:33 0 comments

    Transmitting Events over the Network

    I thought that I would split this next series off log entries into short pieces that I can write up as they are completed.

    Programs and code seen here will be made available via a Github repository in due course.

    The following image shows the program on the Raspberry Pi3 (udpsend) transmitting data across the network to a server (called 'block') which is listening for the packets (on UDP port 333, via the netcat/nc program) and printing the data as it is received.

    The udpsend program is currently sending one packet per second of test data. The next version will be triggered by a pulse on a GPIO line (see previous log entry) which will then transmit a packet with the details to a listening server.

    The choice to use UDP packets instead of TCP means that there is no additional overhead in the reception of data across the network, and also allows incoming data to be received form multiple sources.

    Wifi and Ethernet collision detection, avoidance and re-transmission should handle the case of small cosmic ray detection cascades, The affect of congestion on packet loss when large numbers of detectors (100's) and events are present will need to be investigated in due course. In the first instance, It may be necessary to reduce the data sent in an event packet.

    The next log entry in this series will discuss the capture and transmission of actual events from a single detector.

  • Actual Unit in the field

    Robert Hart07/01/2017 at 04:48 0 comments

    Been working on the lighting and enclosure for each detector in the field. Each element in the array needs to be seen from all angles so a sphere seems to be the ideal shape. It also need to be weather proof and so the electronics will need to be enclosed in a waterproof box.

  • Event Capture and Recording with Raspberry Pi (Part 1)

    Paul Schulz06/30/2017 at 12:27 0 comments

    So how can the Cosmic Ray particle detection events from the Geiger-Muller Tubes be recorded?

    The following describes how this can be done. Part 1 will discuss the code to collect the data. Part 2 will describe the method for sending this data to a central server.


    There is a software library for Raspberry Pi computers called wiringPi, mentioned in a previous post, which comes installed with Raspbian. It can be used to monitor the general purpose IO (gpio) lines and trigger a program to run via an interrupt routine.

    From the detectors, the attached Raspberry Pi will pass the event over a wireless network to a central server for recording. (See diagram below.) The server will log the events received, process them, and make the available on the internet.

    The events can be pulses from either single tube activations, or output from the coincidence circuits.

                 Tubes        LEDS     DT  LEDS         DT  LEDS 
                  |             |       |    |           |    |
      Detector  o-----------------o   o--------o       o--------o
      Board     |                 |   |        | . . . |        |
                o-----------------o   o--------o       o--------o
      GPIO        ||            |       ||   |           ||   |
      Interface   ||            |       ||   |           ||   |
                o-----------------o   o--------o       o--------o
      RPiZW     |                 |   |        | . . . |        |
                o-----------------o   o--------o       o--------o
                  :                     :                :
    +----------+  :                     :                :
    | Wifi     |..:.....................:.... . . . . ...:
    | Router   |  :
    +----------+  :
                | Collector (Server) |
                | Display (HTTP)     |

    Capturing the Events

    For an example of how to monitor the GPIO ports there is a useful C program example: isr.c

    Download this example to a RPi and compile with:

    $ gcc -Wall -o isr isr.c -lwiringPi

    This will create a program called isr (interrupt service routine) which when run will detect events on the gpio pins of the RPi. To test the setup, a push-button was attached between the 3.3v supply (connector pin 1) and Pin 0 (connector pin 11).

    $ ./isr
    Waiting ...  Int on pin 0: Counter:  2987
    Waiting ...  Int on pin 0: Counter:  2988
    Waiting ...  Int on pin 0: Counter:  2989

    Some comments...

    A 10cm unconnected lead was enough of an antenna in my environment to cause the interrupt routine to be continuously triggered. Once the lead was connected by the button the triggering stopped.

    (I might also have to submit a patch to make the output from isr more descriptive of the gpio or pin that is being triggered. (eg. gpio 0/pin 11))

    The processor package in the Raspberry Pi also has internal programmable Pull-Up and Pull-Down resistors. An advantage of this is that the state of the inputs can be changes from the Pi itself, which is really useful for testing. Making another terminal connection, running the following will trigger an interrupt which will be seen in 'isr'.

    $ gpio mode 0 up
    $ gmio mode 0 down

    I'm thinking that this is going to be really useful for testing the system later. If a series of events are recorded or generated from an algorithm, they could be replayed from the Raspberry Pi of the detector itself.

    Next article

    Event Capture and Recording with Raspberry Pi (Part 2a) - Recording Events over the Network

View all 26 project logs

Enjoy this project?



Robert Hart wrote 06/10/2017 at 01:56 point

Hi followers, I now receive seed funding for this project for every click of the like button.

  Are you sure? yes | no

Andrew Bolin wrote 05/08/2017 at 23:22 point

Congratulations on being one of the winners of the concept round. 

Good to see another Aussie on here! If the project goes well, maybe you could consider bringing it up to Sydney for Vivid.

  Are you sure? yes | no

Robert Hart wrote 05/09/2017 at 07:28 point

Hi Andrew, Thank you, I'm currently building a small array of 20 detectors for the Splash Adelaide Winter festival. Btw I'm originally from Sydney, moved to Adelaide 20 years ago.

  Are you sure? yes | no

DontStalkME wrote 04/05/2017 at 08:43 point

Could you make it cheaper by using tin-can ion detectors? Or make your own GM tubes? You could get funding by pre-selling the boxes on kickstarter. Then after you get some images you can ship them out. This assumes you are not wanting a permanent installation.

  Are you sure? yes | no

Robert Hart wrote 04/08/2017 at 22:15 point

Hi DontStalkME, An Ion detector can indeed detect Muons, in fact the very early discoverers of cosmic rays used such detectors. However, they are slow, unstable and are effected by other environmental factors like humidity.  Nevertheless I have developed a solid state detector using a matrix of low cost SiPIN photodiodes. Just haven't published this yet as it is a rat nest gamma detector and not yet in a coincidence detector configeration. 

  Are you sure? yes | no

biemster wrote 10/23/2016 at 19:03 point

Very nice idea! I've worked for cosmic shower detectors in Holland (HiSparc) and Argentina (Auger). The shower front on earth' surface is usually multiple kilometers wide, what inter-detector spacing are you planning to use?

For HV generation you could consider PWM and a boost converter, something like I did here #ESP8266 Geiger counter. The circuit could easily be adapted to count events on the three tubes on different GPIO's of the uC. That would simplify the schematic quite a bit, and if you choose for the ESP as well you can easily network them together too.

In addition to my inter-detector spacing question, how many stations are you planning?

  Are you sure? yes | no

Robert Hart wrote 10/24/2016 at 06:31 point

Hi Biemster,  Thank you! This in the very early stages of development, mostly a proof of concept. I've built many cosmic ray detectors, Geiger counters and PMT counters, just for lolz.  I have developed a good power supply but I fear it's a little over the top for this project and if I want to build a 100 lets say it would be difficult to fund as a hobby project.  So yes I've been thinking about a boost switch-mode approach.   I'm also considering a solid-state detector as well, which I've also been working on.  For this project I might just build a few using GM tubes as demonstration pieces and then maybe go for some crowd funding.  3 ideas I have for an installation would be 1) bollard lamp post in a city parkland 2) block paving bricks 3) across a remote desert landscape below a hill.  these detectors would be placed a few metres apart and most likely 100 or more.  

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates