Conventional real-time coincidence systems use electronic circuitry to detect coincident pulses (hardware coincidence). In this work, a new concept of coincidence system based on real-time software (software coincidence) is presented. This system is based on the recurrent supervision of the analogue-to-digital converters status, which is described in detail. A prototype has been designed and built using a low-cost development platform. It has been applied to two different experimental sets for cosmic ray muon detection. Experimental muon measurements recorded simultaneously using conventional hardware coincidence and our software coincidence system have been compared, yielding identical results. These measurements have also been validated using simultaneous neutron monitor observations. This new software coincidence system provides remarkable advantages such as higher simplicity of interconnection and adjusting. Thus, our system replaces, at least, three Nuclear Instrument Modules (NIMs) required by conventional coincidence systems, reducing its cost by a factor of 40 and eliminating pulse delay adjustments.
Cosmic rays (CRs) are energetic particles that constantly rain through the
Earth's atmosphere. They are the source of a uniform background ionizing
radiation. Most of the CR energy reaches the Earth's surface in the form of
kinetic energy of relativistic muons, which are secondary products of
interactions between highly energetic CRs and the nuclei of atmospheric
particles (Cecchini and Spurio, 2012). Muons (
Coincidence counting is widely used in experimental particle physics with different purposes such as reducing noise; getting directional information (Karapetyan et al., 2013); reducing the probability of a measurement being triggered by independent, unrelated particles; lessening the probability of independent random background events (Remmen and McCreary, 2012); or identifying energetic particles in multi-element particle telescopes (see e.g. Müller-Mellin et al., 1995).
Traditional particle detection systems using coincidence rely on dedicated electronic modules. When real-time operation is not required, alternative approaches based on the analysis of recorded pulse information can be used (e.g. Havelka et al., 2002; Brancaccio et al., 2009). These systems are based on the registration of pulse properties (e.g. amplitude voltages) and their corresponding accurate timestamps. The recorded data are then processed by software in order to obtain the coincidence counting rates. In this work we present a new software-based coincidence system capable of real-time operation in ground-based cosmic ray detection systems.
Muon telescope. Main parts.
Electronic chains based on the Nuclear Instrumentation Module (NIM) standard (US NIM Committee, 1978) are widely used by many experimental particle physics laboratories around the world. Two of the most important advantages of the NIM concepts are flexibility and interchangeability. Although NIM modules cannot communicate with each other through the crate backplane, some modules, like analogue-to-digital converters (ADCs), provide their own interface to communicate with external devices. Nowadays, suppliers offer updated replacements that can read data from ADCs and transfer them to a personal computer (PC), including analysis and data mining software. Their main disadvantages are high cost and the fact that they are not open-source systems.
In contrast, recent advances in microelectronics have put on the market low-cost and small-size devices with high performance (Arduino, Raspberry Pi, Beaglebone Black, etc.). Some of them are open-source hardware and run open-source operating systems like Linux, which confer them with a great versatility to satisfy different user requirements. Moreover, they usually include many general purpose inputs outputs (GPIOs), which are very useful for implementing communication protocols with other electronic devices like one or more ADCs.
The goals of this work are, firstly, the establishment of the theoretical background and conditions allowing software-based real-time coincidence detection (Sect. 3); secondly, the prototype implementation with a low-cost development platform and minimal and simple hardware and software designs (Sect. 4); thirdly, the validation of an operation extracting data from a muon telescope (Sect. 5); and, finally, the prototype testing in two practical applications (Sect. 6). In addition, we will see how our prototype is able to replace at least three NIM modules used in the conventional set-up for coincidence detection.
In this section we describe the different elements that have been used in our experiment, mainly two muon detectors and some NIM modules, and how they have been set up to achieve the results presented in this paper.
We have used two different muon detection systems based on plastic
scintillators. The first device (henceforth MD1, Fig. 1) consists of a pile
of two identical detectors separated by 8.5 cm. The gap between both
detection layers is partially occupied by a
30 cm
Counting rate vs. voltage for PMT type 53AVP (Philips). Note the plateau below 1500 V and the crossing point of both curves in 1270 V (bias voltage chosen).
We can see in Fig. 2 the variation of the counter response with the bias voltage for both PMTs used in the experiment. Bearing in mind they work in coincidence coupled to identical scintillators, we have chosen 1270 V as the optimal value because it is the point where both PMTs have the same response within the plateau.
Main scintillator (100 cm
The second device (henceforth MD2) is made up of a large-area plastic
scintillator (100 cm
NIM standardization provides users with the ability to interchange modules and the flexibility to reconfigure or expand nuclear counting systems as their counting applications change or grow. A typical configuration of a single NIM amplification chain with the main modules used in this work can be seen in Fig. 4. The detector signal is amplified by the preamplifier and amplifier, which also stretches the pulses, making the ADC conversion easier. When the signal amplitude level is between two preconfigured values, the Single Channel Analyzer (SCA) generates a pulse that triggers the ADC conversion when the ADC is working in “Coincidence mode”. The Data Acquisition System (DAS) reads and processes this value and transfers the data to the PC.
A new device has been designed and built in order to acquire data from
several NIM chains and perform a coincidence policy by means of real-time
software, taking advantage of the characteristics of low-cost card-sized
embedded-processor platforms. It is also able to store the pulse heights for
each separate chain. This device has been validated for our muon detectors
based on scintillators with different areas (up to 1 m
The ADC communication protocol is not described in the NIM standard; however, several manufacturers (CANBERRA, FAST, etc.) follow the same basic protocol in their communication lines. In order to understand our software-coincidence basis, the ADC data acquisition process is briefly described below.
The ADC can work in two modes: coincidence mode (COINC) and anticoincidence mode (ANTI). When it works in COINC mode (Fig. 4), input pulse conversions must be enabled or disabled by using the GATE input signal. If the GATE input is low, conversion will not take place.
Data acquisition block diagram with NIM modules. ADC working in coincidence mode.
ADC conversion process. The ADC detects a peak when the input signal rises above the LLD threshold and below the ULD threshold. The detection process ends when the input pulse falls below 90 % of its peak amplitude. In that moment, the signal input is disabled and the conversion process starts. If an error occurs in the conversion process, the DR signal remains inactive and the input signal enabled again. If the conversion process is OK, the DR is activated, and the Data Acquisition System reads the data and activates the DA signal, which causes the DA to go to inactive and the signal input to be enabled again.
When it works in ANTI mode, the SCA is not required; the ADC performs peak detection on the signal and provides in its output this maximum as a digital value. The Lower Level Discriminator (LLD) and Upper Level Discriminator (ULD) potentiometers set the limits for the input signal amplitude to be accepted by the ADC for conversion. If an input pulse falls within these limits, the ADC starts the conversion process. When the conversion process has finished, the Data Ready (DR) signal is activated. When an error occurs in the conversion process, the Invalid (INV) line is activated, DR stays inactive and the process is aborted (this is important for the Sect. 5 discussion). After reading data, the external system (the SAS in our scenario) activates the Data Accepted (DA) line, which resets the ADC, leaving it ready for a new conversion. Once the ADC has started the conversion and up to the DA signal activation, the signal input remains disabled and therefore ignored (see Fig. 5).
As we will see in Sect. 3.2, the ADC conversion time is needed to perform the
software-based coincidence detection code. In this work, the CANBERRA ADC
model 8075 was used and, according to the ADC operator's manual (CANBERRA
Industries, 1983), the conversion time is given by
Block diagram used to verify the ADC conversion time. PC is only used to launch and stop SAS software.
In this work the “digital offset” control has not been used (
In order to verify the time before writing the first version of the software, the conversion time with 10 bits of resolution (1024 channels) was experimentally measured with the set-up shown in Fig. 6. As can be seen, the pulse generator output is connected to both the oscilloscope and the ADC, with its output in turn connected to the SAS. When the SAS completes a single reading, it asserts the Data Ready signal. The total conversion time was determined by measuring the time difference between the pulse from the pulse generator and the pulse from the Data Ready signal.
The pulse level was adjusted to five different values between 0 and 10 V (minimum and maximum input voltage allowed) and the conversion time was measured for each of them. The results are shown in Fig. 7. As we can see, the higher the pulse height, the larger the conversion time. In this work, only minimum and maximum conversion times were needed.
CANBERRA 8075 ADC conversion time. Values between 7.2 and 16
Particle detection systems are often based on multiple detection layers operating in coincidence. These coincidence-based systems may provide relevant physical information such as particle identification by the use of dE vs. dE or dE vs. E techniques (Del Peral et al., 1995) or by means of some shielding block between pilled detectors (Chilingarian et al., 2009a), the particle impact point on the detector surface (Hasebe et al., 1988) and particle energy deposition in detectors or incident direction (Karapetyan et al., 2013). Moreover, coincidence systems are used in different research areas such as medical applications, quantum physics or optics (Joost and Salomon, 2015).
Relativistic particles, such as high-energy muons, require less than a few nanoseconds to go through two scintillator layers separated by 1 m (Remmen and McCreary, 2012). A coincidence in this case is therefore defined by pulses from both scintillators detected within a time window of a few nanoseconds.
Processing time of some tasks. In bold, the task to know the status of a GPIO.
A hardware coincidence circuit is an electronic device with one output and two (or more) inputs. The output is activated only when all input signals are received within a certain time window. Figure 8 shows a typical coincidence circuit, where the output of the AND gate triggers the ADCs' conversion process. This circuit is appropriate for detecting coincidence because of its high speed of operation, since the AND gate switching time is only a few nanoseconds (Texas Instruments, 2010).
We define software coincidence as the ability to detect coincidence by means
of a program running in a CPU-based system. A priori, software-based
real-time coincidence seems unfeasible because the CPU has to be shared with
the underlying operating system. If this is a general purpose operating
system, and therefore it has no real-time capabilities, it is impossible to
establish deterministically whether the acquisition activities will be
executed on time. Therefore, the average access time to the hardware has to
be taken into account when our software is running. Commercially available
embedded development platforms like that used in this work require a time in
the range of microseconds to read and compare two GPIOs (see Sect. 4.2.1 for
more detail). This time is several orders of magnitude longer than the time
required by a relativistic muon to cross through two stacked detectors.
However, if the particle flux is steady and low enough (like that of muon
flux), the average time elapsed between the detection of two incident
particles will be well above the software processing time, thus allowing for
software coincidence processing. This is the basic working principle of our
new software coincidence system. As a matter of fact, the total muon flux
crossing unit horizontal area from above, at sea level, is approximately
one muon per minute per cm
The process to determine coincidence between two pulses is as follows: the ADC starts the conversion after the leading edge of the input pulse surpasses the LLD setting. If both ADCs receive pulses in coincidence, they will start the conversion at the same time. After finishing the conversion process, each ADC activates its respective DR signals, which are detected by the SAS. This will decide whether or not coincidence has happened, depending on the time elapsed between both DR signals.
Hardware coincidence detector block diagram. The AND gate is the core of the circuit; its output becomes active when both inputs are activated. Here, the SAS only acquires and records data. It does not work as a coincidence system. The PC is only used to launch and stop the SAS software.
Different muons considered like a single particle (coincident)
because of ADC conversion time (blue and green) and software checking time
(4.2
As seen in Fig. 7, conversion time depends on the pulse amplitude, so the
difference between both conversion times (both DR enables) can be up to
8.8
Obviously, the received pulses may correspond to different muon arrivals up
to 8.8
Poisson distribution. Probability of detecting as coincident two
different muons in a period of
Considering
Figure 10 shows the Poisson probability for
As mentioned above, the use of software coincidence is limited by the
probability of false coincidence we are willing to accept. For low count
rates such as those of muon ground-based detectors, our prototype can work
with most available scintillators (areas up to 3 m
The design and implementation of the SAS prototype can be split into two well-differentiated parts: hardware and software.
GPIOs required by the processor card to control the ADC. We need 18 lines to read data and control one ADC. Another line is needed to enable and disable the interface buffers, which has been added to protect the processor card.
The hardware implementation involved, firstly, the selection of the processing platform, secondly, the design and building of the interface card and, finally, the box assembly.
In order to minimize the time employed in design and implementation tasks, we
have taken full advantage of the available commercial platform performances.
Nowadays, dozens of card-sized embedded processor systems can be purchased
with different input and output possibilities. Beaglebone Black (BBB) was
chosen for the following reasons:
a great number of GPIO and connection possibilities. We need 37 GPIOs in this
work (Table 2); high processing power; low power consumption; includes a micro-SD card slot. It is used to store all processed data.
An interface card and a box have been designed and implemented (Fig. 11) taking into account the technical specifications of BBB and its processor manufacturers (Cooley, 2014; Texas Instruments, 2013, 2014). The interface is based on the 74LVC245 tri-state transceiver (IDT, 1999), which provides electrical isolation between the BBB processor and external devices (ADCs), 3.3 to 5 V voltage level conversion and buffered signals.
The BBB used in this work (revision B) was delivered with the Angstrom
distribution of the Linux operating system. Our software has been developed
in C GPIO configuration. To access any external device through GPIO, it must be
configured by means of a device structure system called “Device Tree”. It
has its own language to describe which devices should be made available
(Power.Org Enabling the transceivers of the interface after booting the system. Communicating with the ADCs using their protocol. Converting ADC binary data to their decimal value. Applying software-based coincidence detection. Storing the data on a micro-SD card with a time tag (hour, minute, second
and millisecond) and number of registered data per minute.
Left panel: interface with two DB25 connectors. Right panel: interface mounted on the process platform (Beaglebone Black) headers.
After the software development, it was necessary to know the time required to accomplish several tasks, such as reading or writing a bit in a GPIO. As we have seen in Sect. 3.2, to establish the duration of the coincidence time window (in which we consider two pulses as coincident) is a critical decision. Since it must be as short as possible, the software that verifies DR signals must also be as fast as possible. For this reason, after writing code, the execution times of the different routines were verified, revised and optimized to achieve the best results.
In order to measure the time spent on each routine, the software was adapted
to make 10 million iterations of a single task. Thus, the average time of
every task was estimated from the total time to run all the iterations
(Table 1). In this work, the most relevant task timings are those to get the
current status of a single GPIO (4.2
The incident particle causes simultaneous pulses in the ADC inputs and,
therefore, both ADCs start the conversion simultaneously. Bearing in mind
that the software checks DR1 and DR2 sequentially in this order, if DR1 is
active and DR2 is inactive in the first checking (Fig. 12a), the minimum
waiting time to guarantee ADC2 end conversion (DR2 active) is
4.2
Consequently, in order to guarantee that both ADC conversions have finished,
the software pools the state of both ADC DR lines three times after each
reset, which takes it 25.2
To validate the SAS reliability and proper functioning, several data acquisition experiments with the MD1 muon telescope (see Sect. 2.1) were performed. Both, hardware and software coincidence configurations, were simultaneously tested and their results were compared.
Figure 13 shows the experimental set-up operating in hardware (blue background block) and software coincidence (red background block) simultaneously. In hardware coincidence, the SAS is used to store data, so it does not work as a coincidence detector module, and that is the reason why its software has been slightly simplified; it waits for the activation of both DR signals to read and store data, and then resets the ADCs.
Coincidence evaluation. Maximum and minimum conversion times and
waiting time to ensure ADC conversion.
Schematic set-up for the hardware coincidence and software coincidence results comparison. The same analogue signals detected by PMT1 and PMT2 are introduced into both hardware coincidence and software coincidence chains. Working in hardware coincidence, SAS 1 only stores data from both chains. Working in software coincidence, SAS 2 detects coincidence and stores data. We can see in yellow the unnecessary modules when SAS is working in software coincidence.
Comparative tests between data acquired with hardware (left panel) and software (right panel) coincidence by the muon telescope (MD1). Black and red lines correspond to the histogram of upper and lower detectors, respectively.
The software coincidence block shows how this configuration is significantly simpler than the one based on hardware coincidence, saving three modules: two SCAs and one coincidence detector module (yellow modules in Fig. 13). Moreover, the SAS has the capability of storing and transferring data to a PC, avoiding the use of an interface module. From an economical point of view, the total cost of those four NIM modules is well above EUR 6000 (only one SCA module costs more than EUR 1600), and the SAS implementation components have a cost of less than EUR 150. So, we can say that the SAS, working in software coincidence, reduces the costs of the laboratory equipment replaced by a factor of 40.
To make comparisons between both types of coincidence detection systems, we acquired data during 1 day with the experimental set-up shown in Fig. 13. Obviously, the data registered by both software and hardware coincidence chains should be identical. Figure 14 shows the corresponding histograms produced, which are nearly identical, showing only a minor difference in the total amount of data acquired by both systems (0.05 %).
Although this difference may be considered negligible, further tests were performed in order to find out the origin of this discrepancy. Sometimes, the ADC conversion process produces errors and conversion is aborted (see Sect. 2.4). In these cases, the DR signal is not generated and the INV signal activated, which causes data not to be registered. An ad hoc code was written to register the INV signal and several samples were taken and analysed. As can be seen in Fig. 15, an error causes the INV activation in the hardware coincidence chain. However, the software coincidence prototype stores the correct value because its ADCs have not produced conversion errors. In normal operation, these hardware coincidence data would not be registered and, as a result, the total amount of hardware coincidence data would be lower than the one registered with software coincidence. That is the origin of the small difference between the histograms corresponding to hardware and software coincidence shown in Fig. 14. Therefore, seeing that the rest of the data are similar in time and amplitude values, we conclude that under the experimental conditions used in this work, both kinds of coincidence detection systems (hardware and software) produce equivalent results.
The software-based coincidence system presented in this work is an effective
low-cost replacement for conventional hardware coincidence, valid for
low-rate experimental particle detection systems (up to 500 muons s
Data analysis. We can see the same data acquired in hardware
coincidence and software coincidence columns, with an insignificant
difference between values, which is due to ADC conversion. Sometimes, a
conversion error is produced in an ADC, the invalid line is activated and the
ADC data are out of range. That is what happens in the fourth row. In yellow,
the invalid i2 activated (1) and the ADC2 data value (out of
range
The muon telescope used in this application (MD1) is installed in the facilities of the Castilla-La Mancha Neutron Monitor (CaLMa) (Medina et al., 2013; Blanco et al., 2015; García-Población et al., 2014). The MD1 and the neutron monitor are located in the same room and their measurements can be directly compared. Neutrons and muons observed at ground level are secondary particles produced by collisions between cosmic rays and atmospheric atoms. The cosmic ray (protons) energy threshold to produce neutrons detected by CaLMa is above 7 GeV because of the geomagnetic location of this neutron monitor, while the energy threshold of primary cosmic rays rises up to higher than 10 GeV for muon production (Duldig, 2000). Transient interplanetary disturbances associated with solar activity may cause decreases in both the neutron and muon count rates observed on the Earth's surface, in an event known as Forbush decrease (Forbush, 1938). In order to observe these cosmic ray flux variations, the effect atmospheric pressure variations must be removed from the data using a correction procedure (see e.g. Paschalis et al., 2013, and references therein).
From top to bottom, muon count rate (black line) and smoothed count rate (red line), neutron count rate (black line) and smoothed count rate (red line), solar wind density, solar wind temperature, solar wind speed, interplanetary magnetic field components and magnetic field intensity. “Complex ejecta” refers to a complex solar wind structure composed of different interacting structures like shocks, ICMEs and interaction regions. The vertical purple lines mark the interplanetary shock positions and the ejecta's limits.
Software coincidence with four PMTs (MD2), three of them placed in
the sides of a 100 cm
Figure 16 shows pressure-corrected muon and neutron count rates and plasma
and interplanetary magnetic field measurements during a Forbush decrease
detected by CaLMa on 21 December 2014. The count rate in CaLMa decreased by
6 % with respect to the previous neutron count rate (72.62 Hz on average).
This decrease was also observed by the muon telescope, working in software
coincidence, as a reduction in the steady muon count rate of about 3 %
(7.66 Hz on average). As can be observed in Fig. 16, a sharp decrease is
observed in CaLMa after an interplanetary shock passage that marks the
arrival of complex interplanetary ejecta (21 December 2014,
18:00 UTC). These complex ejecta
seem to be composed of two consecutive interplanetary coronal mass
ejections (ICMEs) and comprise a second interplanetary shock probably related
to a compression region created by a fast solar wind stream following the
ejecta. The first ICME is listed in the Richardson and Cane ICME list
(
The good agreement between the muon and neutron data, presented in Fig. 16, validates the software-based coincidence system used to acquire the muon data. Both of them show a clear response to the passage of interplanetary disturbances. The difference in their count rate decreases observed by both instruments in shape (faster, sharper and deeper decrease in CaLMa) and in magnitude is likely related to the different energy of the primary cosmic ray producing the secondary neutrons and muons observed at ground level, as could be expected when the primary cosmic ray energy threshold for CaLMa (neutrons mainly) is about 7 GeV and, for the muon telescope, about 10 GeV.
In this experiment we used our software-based coincidence system to acquire data from a prototype of a position-sensitive muon detector (MD2; see Sect. 2.1). The experimental set-up uses four PMTs operating in software coincidence. Three of them were placed attached to the sides of a plastic scintillator. The fourth PMT was placed inside an opaque box, gathering the light emitted by a small BGO scintillator (see Fig. 17a). The BGO can be moved horizontally in order to select only muon trajectories crossing a certain spot over the surface of the plastic scintillator.
The signal generated by each PMT was amplified and injected into an ADC to carry out its conversion. The four ADCs were connected to our prototype in order to detect coincidence and to record the pulse heights (see the block diagram in Fig. 18). The BGO was located in different positions on the big scintillator surface and corresponding data were acquired and registered.
Figure 17b shows the pulse-height distribution registered by the three lateral PMTs (labelled 1, 2 and 3 in the figure) when the BGO is located over the centre of the plastic scintillator. In this case, the three PMTs observed identical distributions.
Figure 17c shows the pulse-height distribution corresponding to PMT 1 obtained for three different locations of the BGO. As expected, the distribution is shifted towards larger pulse heights when the BGO is located closer to the PMT. The combined pulse height information from PMTs 1, 2 and 3 can be used to reconstruct the location of the particle track.
Obviously, this practical application could be carried out with hardware coincidence, but we take advantage of the easier adjustment, simpler connection and lower cost of our software coincidence. The final configuration of this application is now under development.
NIM modules and SAS interconnection block diagram working in software coincidence with four detection chains. The signal from each PMT is amplified by a preamplifier and an amplifier in order to get the appropriate ADC input level. SAS detects coincidence and registers data.
A software-coincidence acquisition system (SAS) capable of detecting
coincidence by using software and based on a low-cost development platform
has been implemented and tested. It works autonomously (i.e. without a
dedicated computer), recording data on a micro-SD card and transferring them
to a PC through USB or Ethernet connections. In order to evaluate the SAS
operation in software coincidence in comparison with that of hardware
coincidence, several tests have been carried out, acquiring and recording
data from both coincidence methods simultaneously. The results make it
evident that software coincidence is as effective as hardware coincidence
with a low flux of particles like that of a cosmic ray ground-based muon
telescope (scintillator areas up to 3 m
Furthermore, our software coincidence system has been tested in two different experimental set-ups for cosmic ray muon detection: a two-element muon telescope, requiring single coincidence, and a position-sensitive muon detector requiring quadruple coincidence. The results were entirely satisfactory. The first device clearly observed a cosmic ray Forbush decrease, confirmed using neutron monitor data and well correlated with the passage of an interplanetary disturbance. The second device was able to record different PMT pulse levels, depending on the location of the incident muon tracks.
This system provides a reliable and low-cost replacement for hardware-based coincidence system modules over 40 times its value.
All experimental data used have been deposited in a reliable public
repository (
Public data used in Fig. 16:
This work has been partially supported by the University of Alcalá through project CCG2014/EXP-013 and by the Ministerio de Ciencia y Tecnología through project ESP2013-48346-C2-1-R.
We would like to thank José Salvador Pérez Bachiller, who helped us in the SAS box mechanical design, machining and assembly. Edited by: L. Eppelbaum Reviewed by: two anonymous referees