Background

The intention was always to network the individual detectors together to allow for real-time (or near real-time) collection of event data. Several technologies and solutions were investigated. This log entry describes these investigations.

Configurations considered ranged from using a networking module attached to a microprocessor to a higher powered System on a Chip (SoC).

The main detector boards send raw output as voltage pulses (width?) on three wires which can be read directly by a connected controller. The initial design had these pulses being the output from the coincident circuits and so represented the red, green, blue (and white) channels. These pulses with a suitable electronic drivers could be used to power solenoids for operating mechanical noisemakers, corresponding to the detected events.

The networking technologies discussed:

• LoRaWAN networking - Adelaide has a growing IoT network encouraging the growth of Open Data. Still growing. https://www.thethingsnetwork.org/community/adelaide/
• Zigbee - This might have been useful. Ultra low power modes are available, but modules are more expensive and need to be placed
• Bluetooth - Range might have been an issue across the area required.
• WiFi - Well established and understood technology, cheap and available.

Wifi modules considered:

• ESP8266 Module - 3.3V module which, in default configuration, uses AT text commands over a serial connection.

Microprocessors (and microprocessor boards) considered:

• Arduino UNO R3, by keyestudio. This uses the ATMEL Mega16u2 for handling the USB-to-Serial interface. It is possible to reprogram this chip so that the Arduino board can be made to look like another device on the USB interface, like a keyboard or mouse. We probably won’t use this for this project, but together with the ESP8266 Module this might provide a very easy mechanism to log data from the network.

"System on a Chip"s that were considered:

• Raspberry Pi 3 with Wifi - Very useful as a development environment.
• Raspberry Pi Zero W (with Wireless) - Cheaper than the Pi3 and still very capable of doing what we need.
• Adafruit Feather HUZZAH with ESP8266 WiFi - Looks very useful and cheap. It's programmable via Arduino IDE and comes with battery management for a final (polished) detector system.

The price of units was also a consideration as it is hoped that over 100 detectors could be build for a future system spread over the area. Other constraints considered:

• Constrained build time - the solution is build from well known technology to minimise any required development work (+Wifi, -Other networking options)
• Deployment should be as simple as possible.
• What is on hand and/or easy to acquire?

The initial solution will definitely be a hack. A second iteration would be expected to see system changes.

Proposal

For each detector:

• Raspberry Pi Zero with Raspbian Operating System.
• Connected via GPIO pins to detector for events.
• Connected to Wifi access point, pre-configured with network Id (say ‘cosmic-ray’) and password.
• Sends event data to central server.

For the Access point router and network server:

• Powered by 12V battery
• Allocates IP addresses via DHCP (may be fixed to assist with identifying deployed units)
• Deployed with longer range, higher gain omni-directional antenna (flat antenna pattern).

For the network server

• During development, the server could be a laptop.
• For deployment, a laptop could be used, together with a tethered phone for transmitting data to other consumers on the internet.

Networking and Data Protocol

• Detector client software triggers on a detection event and sends a UDP packet to the server, which records the data.

Other useful ideas and thoughts:

• Add a back channel to allow the controller to control/set the outputs on the detector. Useful for testing and deployment. The system could then also be used as a distributed display, suitable for placing in building windows etc.
• Raspberry Pis can be booted from a single image and then individually configured via the network and MAC address.
• Remote administration can be done via SSH and ansible (for example) for managing the detector array.