A coincidence detection system based on real-time software

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 Analog to 15 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 been also validated using simultaneous neutron monitor observations. 20 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 (NIM) required by conventional coincidence systems, reducing its cost by a factor of 40 and eliminating pulse delay adjustments. 25 Geosci. Instrum. Method. Data Syst. Discuss., doi:10.5194/gi-2016-15, 2016 Manuscript under review for journal Geosci. Instrum. Method. Data Syst. Published: 6 June 2016 c © Author(s) 2016. CC-BY 3.0 License.

backplane, some modules, like Analog-to-Digital Converters (ADC), provide their own interface to communicate with external devices. Nowadays, suppliers offer updated replacements that can read data from ADCs and transfer it 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 in the market low cost and small size 5 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 a great versatility to satisfy different user requirements. Moreover, they usually include many General Purpose Inputs Outputs (GPIO), which are very useful to implement communication protocols with other electronic devices like one or more ADCs. 10 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 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 15 our prototype is able to replace at least three NIM modules used in conventional setup for coincidence detection.

Experimental setup.
In this section we describe the different elements that have been used in our experiment, mainly two 20 muon detectors and some NIM modules, and how they have been setup to achieve the results presented in this paper.

Muon detectors.
We have used two different muon detection systems based on plastic scintillators. The first device (henceforth MD1, Fig. 1) consist of a pile of two identical detectors, separated by 8.5 cm. The gap 25 between both detection layers is partially occupied by a 30 cm x 30 cm x 5 cm lead block, which rejects low-energy particles (Chilingarian et al, 2009b), ensuring that only cosmic muons are detected when coincidence between both detectors is applied. Each detector is an opaque sealed box, with a 30 cm x 30 cm x 3 cm plastic scintillator on the bottom and a photomultiplier tube (PMT) type 53 AVP (Philips, 1959) on the top, which are 18 cm apart. This distance is required to be sure that the PMT observes the whole scintillator surface. The upper detector and the lead block can be moved horizontally allowing 5 different fields of view for testing the directionality of muon flux.
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 optimal value because it is the point where both PMTs have the same response within the plateau. 10 The second device (henceforth MD2) is made up by a large area plastic scintillator (100 cm x 100 cm x 5 cm, polyvinyletoluene with 65% anthracene), three PMTs gathering the light emerging through three of four lateral sides and a fourth small Bismuth Germanate (BGO) scintillator (hexagonal prism of 3 cm side and a height of 2 cm) working in coincidence with the other three PMTs. This experimental setup operating in quadruple coincidence selects muon trajectories crossing the BGO, which can be 15 moved over the surface in order to calibrate a position-sensitive detection system currently under development (Fig. 3).

NIM amplification chains.
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 20 typical configuration of a single NIM amplification chain with the main modules used in this work can be seen in the 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) 25 reads and processes this value and transfers the data to the PC.

Software-coincidence Acquisition System (SAS).
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 5 (up to 1 m 2 ). We name this acquisition system SAS (Software-coincidence Acquisition System). Its design and implementation are described in Sect. 4.

ADCs.
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. 10 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. 15 When it works in ANTI mode, the SCA is not required; the ADC performs peak detection on the signal and provides on its output this maximum as a digital value. The Lower Level Discriminator (LLD) and the Upper Level Discriminator (ULD) potentiometers set the limits for the input signals 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 20 activated. When an error occurs in the conversion process the Invalid (INV) line is activated, DR stays inactive and the process aborted (this is important for 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). 25 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: (1) Where N is the channel number (quantization) and X is a selected number for 'digital offset ' control. 5 In this work the 'digital offset' control has not been used (X=0) and the channel number has been fixed to N=1024 (10 bits) because higher precision is not needed, so the conversion should always take 11.74 μs.
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 setup shown in Fig. 6. As it 10 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 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 15 input voltage allowed) and the conversion time was measured for each of them. The results are showed in Fig. 7. As we can see, the higher the pulse height is, the larger the conversion time is. In this work, only minimum and maximum conversion times were needed.

Coincidence 20
Particle detection systems are often based in 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  or by means of some shielding block between pilled detectors (Chilingarian et al, 2009a); particle impact point on the detector surface (Hasebe et al, 1988) and particle energy deposition in detectors or incident direction (Karapetyan et al, 25 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 5 nanoseconds.

Hardware coincidence
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. Fig. 8 shows a typical coincidence circuit, where the output of the AND gate triggers the ADCs conversion process. 10 This circuit is appropriate for detecting coincidence because of its high speed of operation, since AND gates switching time is only a few nanoseconds (Texas Instruments, 2010).

Software coincidence.
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 15 has to be shared with the underlying operating system. If this is a general purpose operating system, and therefore it has not real-time capabilities, it is impossible to establish deterministically if 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 20 (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 muons 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 basis working principle of our new software coincidence system. As a matter of 25 fact, the total muon flux crossing unit horizontal area from above, at sea-level, is approximately 1 muon per minute per cm 2 and remains fairly constant over time (Grieder, 2010). Thus, one of our MD1 muon scintillators (30 x 30 cm) would detect about 15 muons s -1 (900 muons min -1 ). Given that our telescope is located at 708 m above sea-level, it will detect less than 18 muons per second (Olive et al, 2014).
That is, in average, one muon every 55.6 ms and, this period is at least three orders of magnitude above 5 the software processing time (25.2 s in the worst case, as will be see further on). This is the basis to demonstrate the feasibility of a software-based coincidence system for low-rate applications.
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 10 process, each ADC activates their 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.
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 μs (16 -7.2 μs). In order to solve the coincidence 15 problem, the software is pooling both DR lines continuously. When a DR goes active, the software waits enough time to be sure that the conversion of the second ADC has finished. Then, it checks the state of the second ADC DR line (DR2). If it has been activated, the software concludes that there is coincidence and the data from both ADC are recorded. After that, the software resets both ADCs sending a DA and the system is again ready for a new event. Otherwise, if DR2 is not active, the 20 software considers that there is no coincidence and sends a DA (reset) to both ADCs without recording the data. The SAS always sends the DA to both ADC simultaneously (they are both connected at the same circuit wire) to ensure that they are always reset and they start the waiting for a new input pulse at the same time, as suggested by Medina (1987).
Obviously, the received pulses may correspond to different muon arrivals up to 8.8 μs apart and the 25 software could declare them coincident ( Fig. 9(a)). Moreover, taking into account the pooling time (4.2 μs between each DR, see Table 1 and Sect. 4.2.2 below), particles up to 21.4 μs apart ( Fig. 9(b)) could be considered coincident. Actually, in order to guarantee that both ADC conversions have finished, our software waits 25.2 μs (see Sect. 4.2.2). However, in our muon telescope (MD1) it is highly unlikely to have two or more muon arrivals in 25.2 μs because of its steady flux with an average rate of one muon every 55.6 ms. As the arrival of these particles has a random and independent behavior, it follows a Poisson distribution and the probability for detecting k consecutive muons in a δt time window is given 5 by: ( 2) Where λ is the mean number of muons per second.
Considering λ = 18 muons s -1 , k = 2 muons and a time window of δt = 25.2 μs, the probability of having two consecutive muons that would be erroneously counted as coincident is P = 1.03 10 -7 . 10 Figure 10 shows the Poisson probability for k = 2 muons and a time window δt = 25 μs according to scintillator area or muon count rate at sea level. As we can see, using scintillators with areas up to 1 m 2 , the probability of taking as coincident two different muons is negligible. Thus, this software coincidence technique can be applied accepting a minimal number of errors. In order to reduce the number of wrong coincidences as much as possible, the acquisition chains must be adjusted 15 (discrimination levels of ADC, LLD and ULD) in such a way as the particle detected is in the muon energy range, avoiding noise and other particles which would increase the total flux.
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 as those of muons ground-based detectors, our prototype can work with most available scintillators (areas up to 3 m 2 with probability of false 20 coincidence = 1.1 10 -4 ).

SAS design and implementation.
The design and implementation of the SAS prototype can be split into two well-differentiated parts: hardware and software.

Hardware.
The hardware implementation involved, firstly, the election of the processing platform, secondly, the design and built of the interface card and, finally, the box assembly.

Hardware platform.
In order to minimize the time employed in design and implementation tasks, we have taken full 5 advantage of the available commercial platforms performances. Nowadays, dozens of card-sized embedded processor systems can be purchased with different input and output possibilities. Beaglebone Black (BBB) was chosen because of the following reasons:  Great number of GPIO and connection possibilities. We need 37 GPIO in this work (Table 2).
 High processing power. 10  Low power consumption.
 Include micro-SD card slot. It is used to store all processed data.

Interface card and box.
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 (G. Cooley and Texas Instruments, 15 2013 and 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 V to 5 V voltage level conversion and buffered signals.

SAS software.
The BBB used in this work (revision B) was delivered with the Angstrom distribution of the Linux 20 operating system. Our software has been developed in C++ and it is compiled in the BBB itself. It performs the following tasks:  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 TM , 2011).
 Enabling the transceivers of the interface after booting the system.
 Communicating with the ADCs using their protocol. 5  Converting ADC binary data to its decimal value.
 Applying software-based coincidence detection.
 Storing the data in a micro-SD card with a time tag (hour, minute, second and millisecond) and number of registered data per minute.

Processing time. 10
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 be also as fast as possible. For this reason, after writing code, the execution time of the different routines were verified, revised and 15 optimized to achieve the best results.
In order to measure the time spent in each routine, the software was adapted to make 10 million of 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 μs) and to set the value of a single GPIO (3.4 μs). 20

Software coincidence detection.
The incident particle causes simultaneous pulses in ADCs inputs and, therefore, both ADCs start the conversion simultaneously. Bearing in mind that software checks DR1 and DR2 sequentially in this order, if DR1 is active and DR2 is inactive in the first checking ( Fig. 12 (a)), the minimum waiting time to guarantee ADC2 end conversion (DR2 active) is 4.2 μs, which means another checking of both DR 25 (8.4 μs). Otherwise, if DR2 is active and DR1 is inactive in the first checking ( Fig. 12 (b)), the minimun waiting time to ADC1 end conversion is 8.8 μs, therefore the software must wait checking twice both DR (16.8 μs).
Consequently, in order to guarantee that both ADC conversions have finished, the software pool the state of both ADC DR lines three times after each reset, which takes it 25.2 μs. The software considers their state only the third time, if one of both are inactive, it sends the DA signal to reset both ADCs and 5 starting the cycle again (there is no coincidence). Otherwise, if both DR lines are active, a coincidence has been detected and the data is then stored before reseting both ADCs. This process is repeated over and over again.

SAS experimental validation. 10
To validate the SAS reliability and proper functioning, several data acquisition experiments with the muon telescope MD1 (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 setup operating in hardware (blue background block) and software coincidence (red background block) simultaneously. In hardware coincidence, the SAS is used 15 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.
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 20 (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 6000 € (only one SCA module costs more than 1600 €) and the SAS implementation components have cost less than 150 €. So, we can say that the SAS, working in software coincidence, reduces the value of the laboratory equipment replaced by a factor of 40. 25 To make comparisons between both types of coincidence detection systems, we acquired data during one day with the experimental setup 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 %). 5 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, DR signal is not generated and INV signal activated, which causes data is not registered. An ad-hoc code was written to register INV signal and several samples was taken and analyzed. As it can be seen in Fig. 15, an error causes the INV activation 10 in hardware coincidence chain. However the software coincidence prototype stores the correct value because its ADCs have not produced conversion errors. In normal operation, this 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.  15 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.

Applications. 20
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 -1 or up to 3 m -2 scintillator area at sea level, using our prototype, with probability of false coincidence = 1.1 10 -4 ). In this section two examples of specific scientific applications are provided. In the first one, using software coincidence counting greatly reduces the chance of a signal to be caused by 25 an event other than the passage of an energetic muon (Ramesh 2011). In the second one, software coincidence is applied to ensure the pulses collected by the PMTs every time correspond to the same passing muon through a small scintillator area.

Monitoring solar activity with ground-based cosmic ray counters.
The muon telescope used in this application (MD1) is installed in the facilities of the Castilla-La Mancha Neutron Monitor (CaLMa) (J. Medina et al, 2013;J.J. Blanco et al, 2014 andO. García-5 Población et al, 2015). 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 10 than 10 GeV for muon production (Duldig, 2000). Transient interplanetary disturbances associated to solar activity may cause decreases in both the neutron and muon count rates observed on Earth surface, in an event known as Forbush decrease (S.E. 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, 2013 and references therein). 15 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 the previous neutron count-rate (72.62 Hz in 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 in average). As can be observed in Fig.  20 16, a sharp decrease is observed in CaLMa after an interplanetary shock passage that marks the arrival of a complex interplanetary ejecta (21/12/2014 18:00). This complex ejecta seems to be composed by two consecutive Interplanetary Coronal Mass Ejections (ICMEs) and comprises 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 25 (http://www.srl.caltech.edu/ACE/ASC/DATA/level3/icmetable2.htm) with limits between 22/12/2014 04:00 and 22/12/2014 17:00, including a smooth magnetic field rotation and low and stable solar wind temperature as can be expected when a well-developed magnetic cloud is observed in the solar wind (first shadowed region in Fig. 16). A second rotation in magnetic field components is observed between 22/12/1014 17:00 and 23/12/2014, (second shadowed region in Fig. 16) suggesting the presence of a second ICME, however solar wind properties show less clear signatures .
The good agreement between the muon and neutron data, presented in Fig. 16, validates the software-5 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-rates 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 10 (neutrons mainly) is about 7 GeV and for the muon telescope is about 10 GeV.

Position-sensitive muon detector.
In this experiment we used our software-based coincidence system to acquire data from a prototype of position-sensitive muon detector (MD2, see Sect. 2.1). The experimental setup uses four PMTs 15 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. 17 (a)). The BGO can be moved horizontally in order to select only muon trajectories crossing certain spot over the surface of the plastic scintillator.
The signal generated by each PMT was amplified and injected to an ADC to carry out its 20 conversion. The four ADCs were connected to our prototype in order to detect coincidence and to record the pulse heights (see block diagram in Fig. 18). The BGO was located in different positions on the big scintillator surface and corresponding data was acquired and registered. Figure 17 (c) 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 5 advantage of the easier adjustment, simpler connection and lower cost of our software coincidence. The final configuration of this application is now under development.

Conclusions.
A software-coincidence acquisition system (SAS) capable of detecting coincidence by using software 10 and based in a low-cost development platform has been implemented and tested. It works autonomously (i.e. without a dedicated computer) recording data in 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 evident that software 15 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 2 ). Furthermore, our software coincidence system has been tested in two different experimental setups 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. 20 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 forty times its value. 25

Acknowledgments
This work has been partially supported by University of Alcalá through the project CCG2014/EXP-013 and by Ministerio de Ciencia y Tecnología through the project ESP2013-48346-C2-1-R.
We would like to thank Mr. José Salvador Pérez Bachiller, who helps us in the SAS box mechanical design, machining and assembly. 5  Table 2. 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.  crossing the BGO will be detected and the amplitude of PMTs pulses will carry position information. 5

Acro. # Lines
The BGO is used to calibrate the system. All system is located inside a closed dark chamber.  . 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 5 starts. If an error occurs in the conversion process, DR signal remains inactive and input signal enabled again. If conversion process is OK, DR is activated, the Data Acquisition System reads the data and actives DA signal, which causes the DA to go to inactive and the signal input to be enabled again.      In the worst case, after detecting the first ADC end of conversion (b), the SAS must wait checking other twice the DR signal (every time takes 8.4 μs) in order to always ensure the second ADC end of conversion. Figure 13. Schematic setup for hardware coincidence and software coincidence results comparison. The same analogue signals detected by PMT1 and PMT2 are introduced into both hardware coincidence and 5 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 colour the unnecessary modules when SAS is working in software coincidence.